CVE-2026-31664

What it actually does

This is a local Linux kernel information disclosure flaw in the XFRM/IPsec policy expiration notification path. When the kernel builds an xfrm_user_polexpire netlink multicast message for XFRMNLGRP_EXPIRE listeners, padding bytes after the hard field are not cleared before the structure is copied to userspace. A local user able to receive the relevant XFRM netlink notifications can obtain small amounts of uninitialized kernel heap data. The flaw does not directly provide code execution or privilege escalation, but kernel memory disclosure can sometimes aid other exploitation by exposing sensitive values or weakening kernel memory-randomization defenses.

Why it matters to the business

Systems that allow untrusted local users, shared shell access, containerized workloads with elevated networking capabilities, or multi-tenant Linux workloads are most exposed. Successful exploitation could leak small fragments of kernel memory to a local attacker, potentially helping them develop or chain a more serious exploit. The vulnerability is not currently listed in CISA KEV, has no known ransomware association, and has a very low EPSS score with no observed 30-day increase, so broad internet-scale exploitation is unlikely; however, kernel flaws should still be patched through normal operating system maintenance because they affect foundational infrastructure.

How an attack unfolds

An attacker first obtains local code execution on an affected Linux system, typically as an unprivileged or low-privileged user with sufficient ability to interact with XFRM netlink facilities. They create a NETLINK_XFRM socket and subscribe to the XFRM policy expiration multicast group. The attacker then waits for, or attempts to trigger, XFRM policy expiration events. When the vulnerable kernel sends an XFRM policy expiration notification, the xfrm_user_polexpire structure includes uncleared padding bytes copied from a kernel heap allocation. The attacker reads the netlink message from userspace and extracts the leaked bytes. Repeating the process may expose additional heap fragments, which could be used for reconnaissance or as part of a larger exploit chain.

How to fix it

Update the Linux kernel to a vendor-supported build that includes the upstream fix adding the missing padding clear in build_polexpire(). Because no exact fixed package versions were provided, use the fixed kernel advisories from the relevant Linux distribution or appliance vendor and reboot into the patched kernel after installation. Where immediate patching is not possible, reduce exposure by limiting untrusted local user access, removing unnecessary elevated container capabilities such as CAP_NET_ADMIN, restricting creation of privileged network namespaces where feasible, and avoiding unnecessary IPsec/XFRM policy use on shared systems. Live patching may be acceptable if the vendor explicitly covers this fix, but a full kernel update and reboot remains the preferred remediation.

How to confirm the fix worked

Confirm the running kernel version is at or above the distribution/vendor version that contains the CVE-2026-31664 fix, not merely that the package is installed on disk. Validate with uname -r, package manager metadata, and vendor security advisory references. For source-based validation, confirm the XFRM build_polexpire() implementation clears trailing padding in struct xfrm_user_polexpire after setting the hard field, matching the behavior of build_expire(). Vulnerability scanners should report the kernel as fixed after the patched kernel is installed and the host is rebooted. On systems using live patching, verify the live patch is active and specifically covers the XFRM policy expiration padding-clear fix.

Typical attack path

1. Gain local execution on an affected Linux host.
2. Open a NETLINK_XFRM socket from userspace.
3. Subscribe to XFRM policy expiration notifications, such as XFRMNLGRP_EXPIRE.
4. Wait for or trigger XFRM policy expiration events.
5. Receive vulnerable XFRM policy expiration netlink messages.
6. Parse the xfrm_user_polexpire payload and recover uncleared padding bytes leaked from kernel heap memory.
7. Optionally repeat the process to collect more leaked memory fragments for use in further exploitation.

How to detect it

There are no reliable network indicators for this vulnerability because exploitation is local and uses kernel netlink messaging. Standard Linux logs are unlikely to record successful exploitation unless audit, eBPF, or endpoint telemetry is already capturing netlink socket activity and XFRM policy operations. Security teams should review auditd, eBPF/EDR, sysdig, osquery, process execution, shell history, and file integrity telemetry for unusual local programs interacting with NETLINK_XFRM, subscribing to XFRMNLGRP_EXPIRE, or repeatedly creating/modifying/deleting XFRM policies. Look for recently compiled proof-of-concept tools, source files referencing build_polexpire, xfrm_user_polexpire, XFRMNLGRP_EXPIRE, or NETLINK_XFRM, and unexplained bursts of IPsec/XFRM policy expiration activity. Because the leaked data is returned to the local process and may not create a kernel error, absence of logs does not prove absence of exploitation.

What your security team should do

• Prioritize patching shared Linux systems, container hosts, VPN/IPsec gateways, developer jump hosts, and any systems where untrusted users can execute local code.
• Track the relevant Linux distribution advisories and deploy the first vendor-supported kernel build that includes the build_polexpire() padding initialization fix.
• Reboot systems after the kernel update, or verify an applicable vendor live patch is active if reboot deferral is required.
• Restrict CAP_NET_ADMIN and other elevated networking capabilities from containers and local users unless explicitly required.
• Review systems that use IPsec/XFRM policies more closely, because they are more likely to generate the affected notification path.
• Do not treat the low EPSS score and lack of KEV listing as a reason to ignore the issue; use them to schedule the fix within routine kernel patch cycles unless local multi-tenant risk is high.
• Add temporary monitoring for unusual NETLINK_XFRM usage and XFRM policy manipulation on high-risk Linux hosts until patching is complete.