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]

Message-ID: <20230530173422.71583-1-kuniyu@amazon.com>
Date: Tue, 30 May 2023 10:34:22 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <willemdebruijn.kernel@...il.com>
CC: <davem@...emloft.net>, <dsahern@...nel.org>, <edumazet@...gle.com>,
	<kuba@...nel.org>, <kuni1840@...il.com>, <kuniyu@...zon.com>,
	<netdev@...r.kernel.org>, <pabeni@...hat.com>
Subject: Re: [PATCH v1 net-next 00/14] udp: Farewell to UDP-Lite.

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.