Re: [PATCH v2] relay: handle alloc_percpu returning NULL in relay_open
[ + akpm ]
Daniel Axtens writes:
>>> > Check if alloc_percpu returns NULL.
>>> >
>>> > This was found by syzkaller both on x86 and powerpc, and the reproducer
>>> > it found on powerpc is capable of hitting the issue as an unprivileged
>>> > user.
>>> >
>>> > Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel
>>> > buffer pointers")
>>> > Reported-by: syzbot+1e925b4b836afe85a...@syzkaller-ppc64.appspotmail.com
>>> > Reported-by: syzbot+587b2421926808309...@syzkaller-ppc64.appspotmail.com
>>> > Reported-by: syzbot+58320b7171734bf79...@syzkaller.appspotmail.com
>>> > Reported-by: syzbot+d6074fb08bdb2e010...@syzkaller.appspotmail.com
>>> > Cc: Akash Goel
>>> > Cc: Andrew Donnellan # syzkaller-ppc64
>>> > Reviewed-by: Michael Ellerman
>>> > Reviewed-by: Andrew Donnellan
>>> > Cc: sta...@vger.kernel.org # v4.10+
>>> > Signed-off-by: Daniel Axtens
>>>
>>> Acked-by: David Rientjes
>>
>> It looks this one was never applied (which relates to CVE-2019-19462,
>> as pointed by Guenter in 20191223163610.ga32...@roeck-us.net).
>>
>> Whas this lost or are there any issues pending?
>
> I'm not aware of any pending issues.
>
> (But, if anyone does have any objections I'm happy to revise the patch.)
It looks like kernel/relay.c is lacking a maintainer?
Andrew are you able to pick this up for v5.8? It's pretty obviously
correct, and has David's ack.
Original is here if that helps:
https://lore.kernel.org/lkml/20191219121256.26480-1-...@axtens.net/
cheers
Re: [PATCH v2] relay: handle alloc_percpu returning NULL in relay_open
>> > Check if alloc_percpu returns NULL.
>> >
>> > This was found by syzkaller both on x86 and powerpc, and the reproducer
>> > it found on powerpc is capable of hitting the issue as an unprivileged
>> > user.
>> >
>> > Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel
>> > buffer pointers")
>> > Reported-by: syzbot+1e925b4b836afe85a...@syzkaller-ppc64.appspotmail.com
>> > Reported-by: syzbot+587b2421926808309...@syzkaller-ppc64.appspotmail.com
>> > Reported-by: syzbot+58320b7171734bf79...@syzkaller.appspotmail.com
>> > Reported-by: syzbot+d6074fb08bdb2e010...@syzkaller.appspotmail.com
>> > Cc: Akash Goel
>> > Cc: Andrew Donnellan # syzkaller-ppc64
>> > Reviewed-by: Michael Ellerman
>> > Reviewed-by: Andrew Donnellan
>> > Cc: sta...@vger.kernel.org # v4.10+
>> > Signed-off-by: Daniel Axtens
>>
>> Acked-by: David Rientjes
>
> It looks this one was never applied (which relates to CVE-2019-19462,
> as pointed by Guenter in 20191223163610.ga32...@roeck-us.net).
>
> Whas this lost or are there any issues pending?
I'm not aware of any pending issues.
(But, if anyone does have any objections I'm happy to revise the patch.)
Regards,
Daniel
Re: [PATCH v2] relay: handle alloc_percpu returning NULL in relay_open
Hi,
On Fri, Dec 20, 2019 at 11:00:56AM -0800, David Rientjes wrote:
> On Thu, 19 Dec 2019, Daniel Axtens wrote:
>
> > alloc_percpu() may return NULL, which means chan->buf may be set to
> > NULL. In that case, when we do *per_cpu_ptr(chan->buf, ...), we
> > dereference an invalid pointer:
> >
> > BUG: Unable to handle kernel data access at 0x7dae
> > Faulting instruction address: 0xc03f3fec
> > ...
> > NIP [c03f3fec] relay_open+0x29c/0x600
> > LR [c03f3fc0] relay_open+0x270/0x600
> > Call Trace:
> > [c00054353a70] [c03f3fb4] relay_open+0x264/0x600 (unreliable)
> > [c00054353b00] [c0451764] __blk_trace_setup+0x254/0x600
> > [c00054353bb0] [c0451b78] blk_trace_setup+0x68/0xa0
> > [c00054353c10] [c10da77c] sg_ioctl+0x7bc/0x2e80
> > [c00054353cd0] [c0758cbc] do_vfs_ioctl+0x13c/0x1300
> > [c00054353d90] [c0759f14] ksys_ioctl+0x94/0x130
> > [c00054353de0] [c0759ff8] sys_ioctl+0x48/0xb0
> > [c00054353e20] [c000bcd0] system_call+0x5c/0x68
> >
> > Check if alloc_percpu returns NULL.
> >
> > This was found by syzkaller both on x86 and powerpc, and the reproducer
> > it found on powerpc is capable of hitting the issue as an unprivileged
> > user.
> >
> > Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel
> > buffer pointers")
> > Reported-by: syzbot+1e925b4b836afe85a...@syzkaller-ppc64.appspotmail.com
> > Reported-by: syzbot+587b2421926808309...@syzkaller-ppc64.appspotmail.com
> > Reported-by: syzbot+58320b7171734bf79...@syzkaller.appspotmail.com
> > Reported-by: syzbot+d6074fb08bdb2e010...@syzkaller.appspotmail.com
> > Cc: Akash Goel
> > Cc: Andrew Donnellan # syzkaller-ppc64
> > Reviewed-by: Michael Ellerman
> > Reviewed-by: Andrew Donnellan
> > Cc: sta...@vger.kernel.org # v4.10+
> > Signed-off-by: Daniel Axtens
>
> Acked-by: David Rientjes
It looks this one was never applied (which relates to CVE-2019-19462,
as pointed by Guenter in 20191223163610.ga32...@roeck-us.net).
Whas this lost or are there any issues pending?
Regards,
Salvatore
