netdev - Re: [PATCH v1 net-next 00/14] udp: Farewell to UDP-Lite.

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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?