[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF=yD-L88D+vxGcd1u9y07VKW242_macrQ+Q10ZCo_br9z2+ow@mail.gmail.com>
Date: Mon, 29 May 2023 22:15:06 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, David Ahern <dsahern@...nel.org>,
Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v1 net-next 00/14] udp: Farewell to UDP-Lite.
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.
Powered by blists - more mailing lists