Hi, On 04/12/17 09:00, Jan Beulich wrote: >>>> On 01.12.17 at 16:31, <andre.przyw...@linaro.org> wrote: >> On 30/11/17 14:31, Jan Beulich wrote: >>> Jann validly points out that with a caller bogusly requesting a zero- >>> element batch with non-zero high command bits (the ones used for >>> continuation encoding), the assertion right before the call to >>> hypercall_create_continuation() would trigger. A similar situation would >>> arise afaict for non-empty batches with op and/or length zero in every >>> element. >>> >>> While we want the former to succeed (as we do elsewhere for similar >>> no-op requests), the latter can clearly be converted to an error, as >>> this is a state that can't be the result of a prior operation. >>> >>> Take the opportunity and also correct the order of argument checks: >>> We shouldn't accept zero-length elements with unknown bits set in "op". >>> Also constify cache_flush()'s first parameter. >>> >>> Reported-by: Jann Horn <ja...@google.com> >>> Signed-off-by: Jan Beulich <jbeul...@suse.com> >> >> Took me a while to wrap my head around it, because the actual fix is >> just the "*cur_ref = 0;" line, I think. >> But this looks correct to me. >> >> Signed-off-by: Andre Przywara <andre.przyw...@linaro.org> > > I guess this was meant to be Reviewed-by?
Sure, seems my mind was still smoking from chasing all possible call chains ;-) Cheers, Andre. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
