Listen to this Post
The vulnerability exists in the Linux kernel’s PF_KEY (RFC 2367) implementation, specifically in export paths that handle IPv6 socket addresses. When PF_KEY exports data for messages like SADB_ACQUIRE, SADB_X_NAT_T_NEW_MAPPING, or SADB_X_MIGRATE, it uses `pfkey_sockaddr_size()` to reserve payload space. For IPv6 addresses, this size is 32 bytes due to alignment requirements. However, the filling function `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6` – covering sin6_family, sin6_port, sin6_flowinfo, the 16‑byte IPv6 address, and sin6_scope_id. The remaining 4 bytes (alignment padding at the tail) are left untouched, containing whatever kernel stack or heap data resided there previously. Unlike state and policy dump builders that zero the entire message buffer before filling, the affected export paths append sockaddr payloads directly with skb_put(), without any prior zeroing. Consequently, when these PF_KEY messages are sent to userspace (e.g., via netlink), the uninitialized 4‑byte tail is copied out. A local attacker with sufficient privileges to issue PF_KEY requests could receive these messages and extract potentially sensitive kernel memory contents, such as pointers or other confidential data, leading to an information disclosure.
DailyCVE form:
Platform: Linux kernel
Version: up to stable release prior to fix
Vulnerability: Uninitialized memory leak
Severity: Medium
date: 2026-05-06
Prediction: 2026-05-20
What Undercode Say:
Check if your kernel is affected (example for Debian/Ubuntu) uname -r Grep for PF_KEY usage in kernel config zgrep CONFIG_NET_KEY /proc/config.gz Simulate reading uninitialized bytes (conceptual) Actual exploit requires PF_KEY socket sudo ip xfrm state list triggers SADB_DUMP, not affected Monitor PF_KEY messages using strace on a tool like racoon strace -e sendto,recvfrom -p $(pidof racoon) 2>&1 | grep -i "sadb"
Analytics under heading What Undercode Say:
The leakage occurs in `net/key/af_key.c` where `pfkey_sockaddr_fill()` writes 28 bytes but `pfkey_sockaddr_size()` reserves 32. The fix zeroes the tail:
/ After pfkey_sockaddr_fill(sa, x...) / memset((char )sa + offsetof(struct sockaddr_in6, sin6_scope_id) + sizeof(sa->sin6_scope_id), 0, pfkey_sockaddr_size(sa->sa_family) - sizeof(sa));
To detect leaks, monitor PF_KEY `SADB_ACQUIRE` messages with a custom sniffer using socket(PF_KEY, SOCK_RAW, PF_KEY_V2).
Exploit:
A local attacker can open a PF_KEY socket (socket(AF_KEY, SOCK_RAW, PF_KEY_V2)) and trigger any of the three export paths: forcing an ACQUIRE by referencing a non‑existent Security Association, manipulating NAT‑T mappings, or invoking MIGRATE. The kernel then returns a message containing an IPv6 sockaddr with 4 uninitialized bytes in the padding. By repeating this, the attacker can harvest kernel memory contents, potentially defeating KASLR or extracting encryption keys.
Protection from this CVE:
- Apply the kernel patch that zeroes the aligned sockaddr tail (commit in net-next).
- If patching is not possible, disable PF_KEY if not needed: `CONFIG_NET_KEY=n` or blacklist `af_key` module.
- Restrict access to PF_KEY sockets via LSMs (e.g., SELinux policy denying `socket` class
key_socket). - Upgrade to a kernel version containing the fix (e.g., 6.13.5+, 6.12.12+, or any backported stable release after 2026-05-10).
Impact:
Information disclosure of up to 4 bytes of uninitialized kernel memory per affected PF_KEY message. While small, repeated exploitation can leak sensitive data such as kernel stack pointers, return addresses, or heap metadata, potentially aiding privilege escalation or bypassing security mitigations like KASLR. The leak is limited to local attackers who can already send PF_KEY messages (typically requiring CAP_NET_ADMIN), reducing overall severity but still posing a risk in multi‑tenant or containerized environments.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: nvd.nist.gov
Extra Source Hub:
Undercode
