CVE-2026-43089

What it actually does

This is a local Linux kernel information-disclosure flaw in the XFRM userspace interface. A kernel structure returned to userspace contains a one-byte padding hole that is not initialized before being copied out, allowing a local, low-privileged user to read a small amount of uninitialized kernel stack or heap data through XFRM/netlink interactions. The practical confidentiality impact is limited by the one-byte leak, but such leaks can sometimes help bypass kernel exploit mitigations when chained with other vulnerabilities. The provided CVSS vector also indicates potential availability impact; however, the described root cause is an uninitialized memory disclosure in build_mapping().

Why it matters to the business

An attacker who already has local access to a Linux system may be able to extract small fragments of kernel memory. By itself, this is unlikely to cause immediate business disruption, and EPSS is very low with no known public exploitation or CISA KEV listing. The main business risk is that this flaw could be used as part of a larger local privilege-escalation chain against shared Linux servers, container hosts, VPN/IPsec gateways, or systems where untrusted users can execute code.

How an attack unfolds

An attacker first obtains the ability to run code as a low-privileged local user on an affected Linux system. They interact with the kernel XFRM userspace API, typically through netlink messages associated with IPsec/XFRM state handling. When the vulnerable build_mapping() path constructs an xfrm_usersa_id structure, the kernel fills defined fields but leaves a one-byte padding hole uninitialized. The structure is then copied back to userspace, exposing that stale byte. An attacker can repeatedly trigger the operation to collect leaked bytes and attempt to infer useful kernel memory state. The leak is small, so exploitation is most valuable when combined with another kernel bug that requires bypassing hardening such as address randomization or memory layout uncertainty.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the xfrm_user build_mapping() fix, which zero-initializes the affected structure before copying it to userspace. No exact fixed package versions were provided, so remediation should be tracked through vendor advisories for the affected kernel branches in use. Where immediate patching is not possible, reduce local attack surface by limiting shell access, restricting untrusted workloads, isolating multi-user systems, and applying standard kernel hardening. If XFRM/IPsec functionality is not required, consider disabling or limiting related capabilities where feasible, but do not rely on this as a complete substitute for patching.

How to confirm the fix worked

Confirm that installed kernel packages are at or above the vendor-fixed release containing the xfrm_user build_mapping() zero-initialization patch. Validate by checking the running kernel version after reboot, not only the installed package version. For source-based or custom kernels, confirm that the relevant xfrm_user.c change initializes the full xfrm_usersa_id structure before setting individual fields. Exposure can also be assessed by verifying whether affected kernel versions are running on systems that allow untrusted local users, containers, build jobs, or workloads to access netlink/XFRM interfaces.

Typical attack path

1. Gain local code execution on an affected Linux host as an unprivileged or low-privileged user.
2. Open and use the Linux XFRM/netlink interface from userspace.
3. Trigger the vulnerable XFRM mapping response path handled by build_mapping().
4. Receive a kernel-populated xfrm_usersa_id structure containing one uninitialized padding byte.
5. Repeat the request to collect leaked memory bytes and analyze whether they reveal useful kernel state.
6. Optionally combine the information leak with a separate kernel vulnerability to improve reliability of privilege escalation or sandbox/container escape attempts.

How to detect it

There are no reliable, unique indicators that prove this specific flaw was exploited because it leaks only a small amount of memory through legitimate kernel/userspace interfaces and may not produce errors or persistent artifacts. Detection should focus on suspicious local use of XFRM/netlink interfaces by unexpected users or processes. Relevant sources include auditd syscall logs for netlink socket creation and sendmsg/recvmsg activity, eBPF telemetry, endpoint process telemetry, kernel tracing, and command histories on systems where XFRM/IPsec administration is rare. Investigate low-privileged processes making repeated NETLINK_XFRM requests, custom binaries interacting with XFRM, or activity temporally associated with local privilege-escalation attempts, crashes, kernel warnings, or unexplained changes in privileges. Because no public exploit maturity or known KEV exploitation is reported, absence of these signals does not conclusively prove non-exploitation.

What your security team should do

• Inventory Linux systems, appliances, and container hosts running affected kernel versions.
• Prioritize patching shared systems, multi-tenant hosts, bastion hosts, developer workstations, CI runners, VPN/IPsec infrastructure, and container platforms where untrusted local code may run.
• Apply vendor kernel updates and reboot systems to ensure the fixed kernel is active.
• For custom kernels, backport the xfrm_user build_mapping() initialization patch and rebuild.
• Until patched, reduce local access for untrusted users and review controls around container escape and privileged workload boundaries.
• Monitor for unusual local XFRM/netlink activity from non-administrative processes, especially on systems where such activity is not expected.
• Treat this primarily as a potential exploit-chain component rather than a standalone remote compromise risk.