[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20180607.200752.284768085796877308.davem@davemloft.net>
Date: Thu, 07 Jun 2018 20:07:52 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: ast@...nel.org
Cc: daniel@...earbox.net, netdev@...r.kernel.org, dvyukov@...gle.com,
willy@...radead.org, kernel-team@...com
Subject: Re: [PATCH net] bpfilter: fix race in pipe access
From: Alexei Starovoitov <ast@...nel.org>
Date: Thu, 7 Jun 2018 15:31:14 -0700
> syzbot reported the following crash
> [ 338.293946] bpfilter: read fail -512
> [ 338.304515] kasan: GPF could be caused by NULL-ptr deref or user memory access
> [ 338.311863] general protection fault: 0000 [#1] SMP KASAN
> [ 338.344360] RIP: 0010:__vfs_write+0x4a6/0x960
> [ 338.426363] Call Trace:
> [ 338.456967] __kernel_write+0x10c/0x380
> [ 338.460928] __bpfilter_process_sockopt+0x1d8/0x35b
> [ 338.487103] bpfilter_mbox_request+0x4d/0xb0
> [ 338.491492] bpfilter_ip_get_sockopt+0x6b/0x90
>
> This can happen when multiple cpus trying to talk to user mode process
> via bpfilter_mbox_request(). One cpu grabs the mutex while another goes to
> sleep on the same mutex. Then former cpu sees that umh pipe is down and
> shuts down the pipes. Later cpu finally acquires the mutex and crashes
> on freed pipe.
> Fix the race by using info.pid as an indicator that umh and pipes are healthy
> and check it after acquiring the mutex.
>
> Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
> Reported-by: syzbot+7ade6c94abb2774c0fee@...kaller.appspotmail.com
> Signed-off-by: Alexei Starovoitov <ast@...nel.org>
Applied, thanks Alexei.
Powered by blists - more mailing lists