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: <CAF=yD-Je+-t+tabGi6YOXAHjG7Osr+p3X=Utw=-24oMpE+08Jw@mail.gmail.com> Date: Tue, 30 May 2023 16:16:20 -0400 From: Willem de Bruijn <willemdebruijn.kernel@...il.com> To: Kuniyuki Iwashima <kuniyu@...zon.com> Cc: davem@...emloft.net, dsahern@...nel.org, edumazet@...gle.com, kuba@...nel.org, kuni1840@...il.com, netdev@...r.kernel.org, pabeni@...hat.com Subject: Re: [PATCH v1 net-next 00/14] udp: Farewell to UDP-Lite. On Tue, May 30, 2023 at 1:34 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote: > > From: Willem de Bruijn <willemdebruijn.kernel@...il.com> > Date: Mon, 29 May 2023 22:15:06 -0400 > > On Mon, May 29, 2023 at 9:04 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote: > > > > > > Recently syzkaller reported a 7-year-old null-ptr-deref [0] that occurs > > > when a UDP-Lite socket tries to allocate a buffer under memory pressure. > > > > > > Someone should have stumbled on the bug much earlier if UDP-Lite had been > > > used in a real app. Additionally, we do not always need a large UDP-Lite > > > workload to hit the bug since UDP and UDP-Lite share the same memory > > > accounting limit. > > > > > > Given no one uses UDP-Lite, we can drop it and simplify UDP code by > > > removing a bunch of conditionals. > > > > > > This series removes UDP-Lite support from the core networking stack first > > > and incrementally removes the dead code. > > > > > > [0]: https://lore.kernel.org/netdev/20230523163305.66466-1-kuniyu@amazon.com/ > > > > Even if there is high confidence that this protocol is unused, for > > which I'm not sure the above is sufficient proof, it should be > > disabled first and left in place, and removed only when there is no > > chance that it has to be re-enabled. > > > > We already have code churn here from the split between UDP and > > UDPLite, which was reverted in commit db8dac20d519 ("[UDP]: Revert > > udplite and code split."). This series would be an enormous change to > > revert. And if sufficient time passes in between, there might be ample > > patch conflicts, the fixups of which are sources for subtle bugs. > > Thanks Willem, I didn't know someone attempted to disable UDP-Lite. > > You may prefer this way. > https://lore.kernel.org/netdev/20230525151011.84390-1-kuniyu@amazon.com/ > > I'm fine whichever, but the next question will be like how long should we > wait ? We happen to know that we have already waited for 7 years. Is it a significant burden to keep the protocol, in case anyone is willing to maintain it? If consensus is that it is time to remove, a warning may not be sufficient for people to notice. Perhaps break it, but in a way that can be undone trivially, preferably even without recompiling the kernel. Say, returning EOPNOTSUPP on socket creation, unless a sysctl has some magic non-deprecated value. But maybe I'm overthinking it. There must be prior art for this?
Powered by blists - more mailing lists