Cloudanix VulnDB

CVE-2026-98541

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A configuration mistake in the Linux kernel's UDP tunneling code can let an attacker slowly drain memory until the system becomes unusable.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Improper netlink attribute validation for FOU_ENCAP_DIRECT sockets allows creation with protocol=0, causing fou_udp_recv to return 0 on every UDP packet and leak the sk_buff without freeing it.

Why it matters to the business

Attackers who can issue netlink commands can trigger unbounded kernel memory consumption on any system exposing the FOU netlink interface, leading to denial of service or system instability.

How an attack unfolds

An attacker with CAP_NET_ADMIN sends a FOU_CMD_ADD Generic Netlink message specifying FOU_ENCAP_DIRECT but omitting FOU_ATTR_IPPROTO; the kernel accepts the request and creates a socket with protocol=0; subsequent UDP packets to the configured port cause fou_udp_recv to leak each sk_buff, exhausting SUnreclaim memory.

How to fix it

Upgrade to a kernel containing the fix that rejects FOU_ENCAP_DIRECT creation when no protocol is supplied; apply the change in fou_create to return -EINVAL for the missing attribute case.

How to confirm the fix worked

Reproduce the original reproducer: send FOU_CMD_ADD with FOU_ATTR_PORT and FOU_ENCAP_DIRECT but no IPPROTO; confirm the command now fails with -EINVAL and that FOU_CMD_GET never reports protocol=0 for direct encap sockets.

Typical attack path

  1. Obtain CAP_NET_ADMIN or equivalent privileges on the target host
  2. Craft and send FOU_CMD_ADD netlink request with FOU_ATTR_TYPE=FOU_ENCAP_DIRECT and FOU_ATTR_PORT but without FOU_ATTR_IPPROTO
  3. Observe successful creation via FOU_CMD_GET showing protocol=0
  4. Send repeated UDP datagrams to the newly created port to trigger sk_buff leaks

How to detect it

Monitor netlink audit logs or system call traces for FOU_CMD_ADD messages lacking FOU_ATTR_IPPROTO; watch /proc/meminfo SUnreclaim growth correlated with UDP traffic on FOU ports; inspect existing FOU sockets via FOU_CMD_GET for any reporting protocol=0.

  • FOU_CMD_ADD.*FOU_ENCAP_DIRECT without FOU_ATTR_IPPROTO
  • fou->protocol == 0 reported by FOU_CMD_GET
  • SUnreclaim growth in /proc/meminfo after UDP traffic to FOU port

What your security team should do

  • Prioritize kernel upgrade on any system that exposes the fou netlink family or uses FOU direct encapsulation
  • Audit running kernels for existing FOU sockets with protocol=0 via /proc or netlink queries
  • Restrict CAP_NET_ADMIN to trusted processes only until patches are applied

The record

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).

Affected packages

Ecosystem Package Introduced Fixed