@@ -22,6 +22,8 @@ static int udplite_sk_init(struct sock *sk)
{
udp_init_sock(sk);
udp_sk(sk)->pcflag = UDPLITE_BIT;
+ pr_warn_once("UDP-Lite is deprecated and scheduled to be removed in 2025, "
+ "please contact the netdev mailing list\n");
return 0;
}
@@ -8,6 +8,8 @@
* Changes:
* Fixes:
*/
+#define pr_fmt(fmt) "UDPLite6: " fmt
+
#include <linux/export.h>
#include <linux/proc_fs.h>
#include "udp_impl.h"
@@ -16,6 +18,8 @@ static int udplitev6_sk_init(struct sock *sk)
{
udpv6_init_sock(sk);
udp_sk(sk)->pcflag = UDPLITE_BIT;
+ pr_warn_once("UDP-Lite is deprecated and scheduled to be removed in 2025, "
+ "please contact the netdev mailing list\n");
return 0;
}
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. Also, 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. Removing UDP-Lite would simplify UDP code removing a bunch of conditionals in fast path. Let's add a deprecation notice when UDP-Lite socket is created and schedule its removal to 2025. Link: https://lore.kernel.org/netdev/20230523163305.66466-1-kuniyu@amazon.com/ [0] Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> --- net/ipv4/udplite.c | 2 ++ net/ipv6/udplite.c | 4 ++++ 2 files changed, 6 insertions(+)