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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 30 Nov 2019 12:42:30 -0800 From: Cong Wang <xiyou.wangcong@...il.com> To: David Miller <davem@...emloft.net> Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>, syzbot+9fe8e3f6c64aa5e5d82c@...kaller.appspotmail.com Subject: Re: [Patch net] netrom: fix a potential NULL pointer dereference On Sat, Nov 30, 2019 at 12:31 PM David Miller <davem@...emloft.net> wrote: > > From: Cong Wang <xiyou.wangcong@...il.com> > Date: Sat, 30 Nov 2019 12:05:40 -0800 > > > It is possible that the skb gets removed between skb_peek() and > > skb_dequeue(). So we should just check the return value of > > skb_dequeue(). Otherwise, skb_clone() may get a NULL pointer. > > > > Technically, this should be protected by sock lock, but netrom > > doesn't use it correctly. It is harder to fix sock lock than just > > fixing this. > > > > Reported-by: syzbot+9fe8e3f6c64aa5e5d82c@...kaller.appspotmail.com > > Signed-off-by: Cong Wang <xiyou.wangcong@...il.com> > > This is really bogus because it also means that all of the other > state such as the ack_queue, nr->va, nr->vs, nr->window can also > change meanwhile. > > And these determine whether a dequeue should be done at all, and > I'm sure some range violations are possible as a result as well. > > This code is really terminally broken and just adding this check > will leave many other other obvious bugs here that syzbot will > trigger eventually. Yes, this is what I meant by mentioning sock lock above, it is more broken than this NULL-deref as I said. It is not worth time to audit sock lock for netrom, so I decided to just fix this single crash. Thanks.
Powered by blists - more mailing lists