CVE-2026-98541

In the Linux kernel, the following vulnerability has been resolved:

fou: reject omitted FOU ATTR IPPROTO on FOU ENCAP DIRECT

Commit 7a9bc9e3f423 ("fou: Don't allow 0 for FOU ATTR IPPROTO.") added NLA POLICY MIN(NLA U8, 1) to fou nl policy[FOU ATTR IPPROTO], which rejects an explicitly supplied FOU ATTR IPPROTO == 0 attribute with -ERANGE.

However, FOU ATTR IPPROTO is an optional netlink attribute. When a user sends FOU CMD ADD with FOU ATTR TYPE set to FOU ENCAP DIRECT and omits FOU ATTR IPPROTO entirely, nla policy validation succeeds and parse nl config() leaves cfg->protocol as 0 (from memset(cfg, 0, sizeof(*cfg))). fou create() then creates a FOU ENCAP DIRECT socket with fou->protocol == 0.

In fou udp recv(), returning -fou->protocol to udp queue rcv one skb() triggers IP protocol resubmission when fou->protocol > 0, whereas returning 0 tells the UDP tunnel layer that the skb was consumed without freeing it. When fou->protocol == 0, every packet received on the socket returns 0 from fou udp recv() and leaks the sk buff.

Reject FOU ENCAP DIRECT when !cfg->protocol in fou create() so that creating a direct encapsulation port without FOU ATTR IPPROTO fails with -EINVAL while leaving FOU CMD DEL and FOU CMD GET (which share parse nl config()) unaffected.

Tested in QEMU against Linux 7.3.0-rc3 by sending a FOU CMD ADD Generic Netlink request with FOU ATTR PORT = 5555 and FOU ATTR TYPE = FOU ENCAP DIRECT while omitting FOU ATTR IPPROTO. On the unfixed kernel, FOU CMD ADD succeeds (err = 0), FOU CMD GET reports fou->type = 1 and fou->protocol = 0, and sending 4000 UDP packets to 127.0.0.1:5555 leaks all 4000 sk buffs (SUnreclaim in /proc/meminfo grows from 41456 kB to 59008 kB, +17552 kB); with this patch applied, FOU CMD ADD is rejected with -EINVAL (-22).