lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <6568b03cbceb7_1b8920827@john.notmuch> Date: Thu, 30 Nov 2023 07:54:36 -0800 From: John Fastabend <john.fastabend@...il.com> To: Daniel Borkmann <daniel@...earbox.net>, Eric Dumazet <edumazet@...gle.com> Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, ast@...nel.org, andrii@...nel.org, martin.lau@...ux.dev, netdev@...r.kernel.org, bpf@...r.kernel.org, john.fastabend@...il.com, jakub@...udflare.com Subject: Re: pull-request: bpf 2023-11-30 Daniel Borkmann wrote: > On 11/30/23 3:53 PM, Eric Dumazet wrote: > > On Thu, Nov 30, 2023 at 12:49 AM Daniel Borkmann <daniel@...earbox.net> wrote: > >> > >> Hi David, hi Jakub, hi Paolo, hi Eric, > >> > >> The following pull-request contains BPF updates for your *net* tree. > >> > >> We've added 5 non-merge commits during the last 7 day(s) which contain > >> a total of 10 files changed, 66 insertions(+), 15 deletions(-). > >> > >> The main changes are: > >> > >> 1) Fix AF_UNIX splat from use after free in BPF sockmap, from John Fastabend. > > > > syzbot is not happy with this patch. > > > > Would the following fix make sense? > > > > diff --git a/net/unix/unix_bpf.c b/net/unix/unix_bpf.c > > index 7ea7c3a0d0d06224f49ad5f073bf772b9528a30a..58e89361059fbf9d5942c6dd268dd80ac4b57098 > > 100644 > > --- a/net/unix/unix_bpf.c > > +++ b/net/unix/unix_bpf.c > > @@ -168,7 +168,8 @@ int unix_stream_bpf_update_proto(struct sock *sk, > > struct sk_psock *psock, bool r > > } > > > > sk_pair = unix_peer(sk); > > - sock_hold(sk_pair); > > + if (sk_pair) > > + sock_hold(sk_pair); > > psock->sk_pair = sk_pair; > > unix_stream_bpf_check_needs_rebuild(psock->sk_proto); > > sock_replace_proto(sk, &unix_stream_bpf_prot); > > > > Oh well :/ Above looks reasonable to me, thanks, but I'll defer to John & Jakub (both Cc'ed) > for a final look. > > Thanks, > Daniel Is that sk in LISTEN state by any chance? I can't think why we even allow such a thing for af_unix sockets. Another possible fix would be to block adding these to sockmap at all. But, above should be fine as well so I would just go with that. Eric or Daniel would you like to submit a patch or I can if needed. Thanks, John
Powered by blists - more mailing lists