[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v9r1ew76.fsf@dja-thinkpad.axtens.net>
Date: Sat, 30 Nov 2019 17:04:45 +1100
From: Daniel Axtens <dja@...ens.net>
To: linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk
Cc: akash.goel@...el.com, ajd@...ux.ibm.com,
syzbot+1e925b4b836afe85a1c6@...kaller-ppc64.appspotmail.com,
syzbot+587b2421926808309d21@...kaller-ppc64.appspotmail.com,
syzbot+58320b7171734bf79d26@...kaller.appspotmail.com,
syzbot+d6074fb08bdb2e010520@...kaller.appspotmail.com
Subject: Re: [PATCH] relay: handle alloc_percpu returning NULL in relay_open
Daniel Axtens <dja@...ens.net> writes:
> --
>
> There's a syz reproducer on the powerpc syzbot that eventually hits
> the bug, but it can take up to an hour or so before it keels over on a
> kernel with all the syzkaller debugging on, and even longer on a
> production kernel. I have been able to reproduce it once on a stock
> Ubuntu 5.0 ppc64le kernel.
>
> I will ask MITRE for a CVE - while only the process doing the syscall
> gets killed, it gets killed while holding the relay_channels_mutex,
> so it blocks all future relay activity.
CVE-2019-19462 has been assigned.
Regards,
Daniel
> ---
> kernel/relay.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/relay.c b/kernel/relay.c
> index ade14fb7ce2e..a376cc6b54ec 100644
> --- a/kernel/relay.c
> +++ b/kernel/relay.c
> @@ -580,7 +580,13 @@ struct rchan *relay_open(const char *base_filename,
> if (!chan)
> return NULL;
>
> - chan->buf = alloc_percpu(struct rchan_buf *);
> + chan->buf = alloc_percpu_gfp(struct rchan_buf *,
> + GFP_KERNEL | __GFP_NOWARN);
> + if (!chan->buf) {
> + kfree(chan);
> + return NULL;
> + }
> +
> chan->version = RELAYFS_CHANNEL_VERSION;
> chan->n_subbufs = n_subbufs;
> chan->subbuf_size = subbuf_size;
> --
> 2.20.1
Powered by blists - more mailing lists