CVE-2026-31671

What it actually does

This Linux kernel flaw is an information disclosure issue in the XFRM user interface. A kernel structure returned to user space contains a one-byte protocol field followed by padding before an xfrm_selector structure; because the structure was not fully zero-initialized before being copied to user space, three bytes of uninitialized kernel memory could be exposed to a local user. The practical leak is small, but kernel memory disclosure bugs can sometimes help bypass hardening mechanisms or support follow-on exploitation. The vulnerability requires local access with low privileges and no user interaction. No public exploit maturity is currently reported, EPSS is very low and flat, and it is not listed in CISA KEV.

Why it matters to the business

The primary business risk is local users or already-compromised workloads gaining small fragments of kernel memory that may aid further attacks. On shared Linux systems, multi-user servers, container hosts, VPN/IPsec gateways, and systems using XFRM/IPsec functionality, this increases the value of a foothold because a low-privileged actor may be able to collect kernel memory residue. The current likelihood of broad exploitation appears low based on EPSS, lack of known exploitation, and absence from KEV, but organizations with high-assurance, multi-tenant, or regulated Linux environments should still prioritize kernel updates through normal security patch cycles.

How an attack unfolds

An attacker first obtains local code execution on a vulnerable Linux system, typically as an unprivileged user or within a context that can interact with the kernel XFRM netlink interface. The attacker then issues crafted or repeated NETLINK_XFRM requests that cause the kernel to build an xfrm_user_report response. Because the report structure was not zeroed before selected fields were populated, padding bytes adjacent to the protocol field may contain stale kernel stack or heap data. When the response is copied back to user space, the attacker reads those padding bytes. The leak is limited in size, so exploitation would generally involve repeated triggering and correlation with other bugs or techniques rather than direct standalone compromise.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for xfrm_user build_report() zero-initialization. The fix initializes the full xfrm_user_report structure before setting individual fields, preventing padding bytes from exposing stale kernel memory. Because no specific fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory for this CVE. After installing the updated kernel, reboot into the patched kernel and remove or de-prioritize vulnerable kernel versions from boot configurations where feasible. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, applying least privilege, hardening container boundaries, and monitoring suspicious NETLINK_XFRM usage. Disabling IPsec/XFRM-related functionality may reduce reachable attack surface in some environments, but this is system- and workload-dependent and should be tested carefully.

How to confirm the fix worked

Confirm that systems are running a kernel build containing the xfrm_user build_report() zero-initialization fix, using the distribution vendor's package changelog, security advisory, or kernel source patch status. Validate that the running kernel, not only the installed package, is patched by checking the active kernel version after reboot. For source-based or custom kernels, verify that the build_report() implementation in net/xfrm/xfrm_user.c clears the xfrm_user_report structure before copying it to user space. Vulnerability scanners should be configured to assess the active Linux kernel version against vendor-fixed versions once published. If regression testing is available, exercise XFRM/IPsec netlink reporting functionality to ensure normal behavior remains intact after patching.

Typical attack path

1. Gain local access to a vulnerable Linux system as a low-privileged user or process.
2. Open or interact with the XFRM netlink interface used for IPsec/XFRM state and policy reporting.
3. Trigger code paths that invoke xfrm_user build_report() and return an xfrm_user_report structure to user space.
4. Read the returned structure and extract the uninitialized padding bytes.
5. Repeat collection attempts to gather useful memory residue.
6. Use any leaked kernel memory as supporting information for follow-on local privilege escalation, hardening bypass, or exploit development.

How to detect it

There are no widely reported public exploitation indicators for this vulnerability, and successful exploitation may leave little or no default log evidence because it involves local kernel netlink interaction. Detection should focus on evidence of suspicious local processes repeatedly interacting with the XFRM netlink interface, especially on systems where ordinary workloads do not manage IPsec/XFRM state. Useful telemetry sources include Linux audit logs for process execution, command-line logging, eBPF or kernel tracing of netlink activity, endpoint detection telemetry, shell history, and package/kernel version inventory. Look for unusual execution of custom binaries, proof-of-concept tooling, or scripts that reference XFRM, NETLINK_XFRM, xfrm_user, xfrm_user_report, or build_report. Also investigate signs of broader local post-exploitation, such as attempts to enumerate kernel symbols, disable ASLR/KASLR protections, load kernel modules, or run local privilege escalation tooling shortly after XFRM-related activity.

• NETLINK_XFRM
• XFRM_MSG_REPORT
• xfrm_user_report
• xfrm_user
• build_report
• net/xfrm/xfrm_user.c
• struct xfrm_user_report
• ip xfrm
• audit: NETLINK_XFRM
• socket(AF_NETLINK
• socket(AF_NETLINK, SOCK_RAW, NETLINK_XFRM)

What your security team should do

• Inventory Linux systems, especially multi-user servers, container hosts, VPN/IPsec gateways, and systems using XFRM/IPsec.
• Track vendor advisories for the exact fixed kernel package versions applicable to each distribution.
• Patch through the standard kernel security update process and reboot systems into the fixed kernel.
• Prioritize shared, internet-facing, or high-sensitivity Linux hosts ahead of single-user or isolated systems.
• Restrict local access and untrusted workload execution on systems that cannot be patched promptly.
• Monitor for unusual local interaction with NETLINK_XFRM or repeated XFRM report generation where audit or eBPF telemetry is available.
• Review local privilege escalation detections and kernel exploit telemetry, since this issue is more likely to be useful as part of a chain than as a standalone business-impacting exploit.