A fuzzer based on AFL and TriforceAFL discovered an assertion
violation in Xen 4.9.1.
The issue is that, when `opaque_out` is non-zero,
do_grant_table_op() assumes that the hypercall was preempted and a
continuation is generated. However, `opaque_out` also ends up being
non-zero if the guest calle
gnttab_setup_table() has the following code:
=
static long
gnttab_setup_table(
XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count)
{
struct gnttab_setup_table op;
struct domain *d;
struct grant_table *gt;
int
On Wed, Nov 29, 2017 at 3:32 PM, Andrew Cooper
wrote:
> On 29/11/17 14:23, Jann Horn wrote:
>> gnttab_setup_table() has the following code:
>>
>> =
>> static long
>> gnttab_setup_table(
>> XEN_GUEST_HANDLE_PA
On Wed, Jan 23, 2019 at 1:04 PM Greg KH wrote:
> On Wed, Jan 23, 2019 at 03:03:47AM -0800, Kees Cook wrote:
> > Variables declared in a switch statement before any case statements
> > cannot be initialized, so move all instances out of the switches.
> > After this, future always-initialized stack
On Mon, Feb 10, 2025 at 7:36 PM Valentin Schneider wrote:
> What if isolated CPUs unconditionally did a TLBi as late as possible in
> the stack right before returning to userspace? This would mean that upon
> re-entering the kernel, an isolated CPU's TLB wouldn't contain any kernel
> range transla
On Tue, Jan 14, 2025 at 6:51 PM Valentin Schneider wrote:
> vunmap()'s issued from housekeeping CPUs are a relatively common source of
> interference for isolated NOHZ_FULL CPUs, as they are hit by the
> flush_tlb_kernel_range() IPIs.
>
> Given that CPUs executing in userspace do not access data i
On Fri, Jan 17, 2025 at 4:25 PM Valentin Schneider wrote:
> On 14/01/25 19:16, Jann Horn wrote:
> > On Tue, Jan 14, 2025 at 6:51 PM Valentin Schneider
> > wrote:
> >> vunmap()'s issued from housekeeping CPUs are a relatively common source of
> >> interf
