[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200605140252.766450436@linuxfoundation.org>
Date: Fri, 5 Jun 2020 16:15:09 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
stable@...r.kernel.org,
syzbot+1e925b4b836afe85a1c6@...kaller-ppc64.appspotmail.com,
syzbot+587b2421926808309d21@...kaller-ppc64.appspotmail.com,
syzbot+58320b7171734bf79d26@...kaller.appspotmail.com,
syzbot+d6074fb08bdb2e010520@...kaller.appspotmail.com,
Daniel Axtens <dja@...ens.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Michael Ellerman <mpe@...erman.id.au>,
Andrew Donnellan <ajd@...ux.ibm.com>,
David Rientjes <rientjes@...gle.com>,
Akash Goel <akash.goel@...el.com>,
Guenter Roeck <linux@...ck-us.net>,
Salvatore Bonaccorso <carnil@...ian.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: [PATCH 4.19 07/28] kernel/relay.c: handle alloc_percpu returning NULL in relay_open
From: Daniel Axtens <dja@...ens.net>
commit 54e200ab40fc14c863bcc80a51e20b7906608fce upstream.
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 0x7dae0000
Faulting instruction address: 0xc0000000003f3fec
...
NIP relay_open+0x29c/0x600
LR relay_open+0x270/0x600
Call Trace:
relay_open+0x264/0x600 (unreliable)
__blk_trace_setup+0x254/0x600
blk_trace_setup+0x68/0xa0
sg_ioctl+0x7bc/0x2e80
do_vfs_ioctl+0x13c/0x1300
ksys_ioctl+0x94/0x130
sys_ioctl+0x48/0xb0
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+1e925b4b836afe85a1c6@...kaller-ppc64.appspotmail.com
Reported-by: syzbot+587b2421926808309d21@...kaller-ppc64.appspotmail.com
Reported-by: syzbot+58320b7171734bf79d26@...kaller.appspotmail.com
Reported-by: syzbot+d6074fb08bdb2e010520@...kaller.appspotmail.com
Signed-off-by: Daniel Axtens <dja@...ens.net>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
Reviewed-by: Michael Ellerman <mpe@...erman.id.au>
Reviewed-by: Andrew Donnellan <ajd@...ux.ibm.com>
Acked-by: David Rientjes <rientjes@...gle.com>
Cc: Akash Goel <akash.goel@...el.com>
Cc: Andrew Donnellan <ajd@...ux.ibm.com>
Cc: Guenter Roeck <linux@...ck-us.net>
Cc: Salvatore Bonaccorso <carnil@...ian.org>
Cc: <stable@...r.kernel.org> [4.10+]
Link: http://lkml.kernel.org/r/20191219121256.26480-1-dja@axtens.net
Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
kernel/relay.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -581,6 +581,11 @@ struct rchan *relay_open(const char *bas
return NULL;
chan->buf = alloc_percpu(struct rchan_buf *);
+ if (!chan->buf) {
+ kfree(chan);
+ return NULL;
+ }
+
chan->version = RELAYFS_CHANNEL_VERSION;
chan->n_subbufs = n_subbufs;
chan->subbuf_size = subbuf_size;
Powered by blists - more mailing lists