CVE-2026-43088

What it actually does

The flaw is an uninitialized memory disclosure in the Linux kernel PF_KEY/AF_KEY networking code used for IPsec key management. Certain PF_KEY export messages reserve 32 bytes for an IPv6 sockaddr payload but initialize only the first 28 bytes, leaving the final 4 aligned bytes containing stale kernel memory. A local user-space process that can receive the affected PF_KEY messages may be able to read small fragments of kernel memory from SADB_ACQUIRE, SADB_X_NAT_T_NEW_MAPPING, or SADB_X_MIGRATE messages. The issue is local and low-complexity, with no known public exploit and very low EPSS, but it affects a kernel subsystem that may be present across many Linux distributions and embedded/networking appliances.

Why it matters to the business

Successful exploitation could allow a local attacker or compromised low-privilege process to obtain small pieces of sensitive kernel memory, which may help defeat hardening, expose implementation details, or assist in chained attacks. Systems using IPsec, IKE/key management daemons, VPN gateways, container hosts, and network appliances are more relevant because PF_KEY activity is more likely. There is no current CISA KEV listing, no ransomware association, no named threat actor activity, and the EPSS score is low and flat, so remediation should be handled through normal kernel patch cycles unless the system is multi-user, internet-facing as a VPN/IPsec device, or runs untrusted workloads.

How an attack unfolds

An attacker first needs local code execution with at least a low-privileged account on a vulnerable Linux system. The attacker then interacts with the PF_KEY/AF_KEY interface or monitors PF_KEY messages generated by IPsec state changes. When the kernel emits one of the affected message types involving IPv6 sockaddr data, it allocates aligned payload space but fails to clear the final 4 bytes. The attacker reads the returned PF_KEY message from user space and extracts those trailing bytes. By repeatedly triggering or waiting for SADB_ACQUIRE, NAT-T mapping, or migration events, the attacker may collect small fragments of stale kernel memory. This is most useful as part of a larger local attack chain rather than as a standalone compromise path.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the AF_KEY/PF_KEY sockaddr tail clearing issue, specifically the change that zeroes the aligned sockaddr tail after pfkey_sockaddr_fill() in the affected PF_KEY export paths. Because exact fixed package versions vary by distribution and no fixed versions were provided, use vendor advisories for the deployed distribution or appliance firmware and update to the latest supported kernel/security update. If immediate patching is not possible, reduce exposure by disabling unused IPsec/PF_KEY functionality, disabling or not loading the relevant kernel support where feasible, limiting local shell access, restricting untrusted workloads, and hardening container/tenant isolation. Systems that actively use IPsec/VPN services should prioritize vendor kernel updates over functional mitigations that could disrupt service.

How to confirm the fix worked

Confirm the running kernel version and vendor package release include the fix for this issue or the upstream patch that clears the aligned sockaddr tail in PF_KEY exports. Validate that systems have rebooted into the patched kernel, not merely installed the package. On source-based or custom kernels, inspect the AF_KEY implementation to ensure the affected SADB_ACQUIRE, SADB_X_NAT_T_NEW_MAPPING, and SADB_X_MIGRATE paths clear the padded bytes after filling IPv6 sockaddr data. For exposure assessment, identify systems with AF_KEY/PF_KEY or IPsec functionality enabled, systems running IKE/IPsec key management daemons, and multi-user or untrusted workload hosts where local exploitation is plausible.

Typical attack path

1. Gain local execution on a vulnerable Linux system, such as through a shell, compromised service account, container escape prerequisite, or malicious local workload.
2. Open or access the PF_KEY/AF_KEY interface used for IPsec key management.
3. Trigger or wait for IPv6-related PF_KEY export events that generate SADB_ACQUIRE, SADB_X_NAT_T_NEW_MAPPING, or SADB_X_MIGRATE messages.
4. Read the returned PF_KEY message payloads from user space.
5. Inspect the final aligned bytes of affected sockaddr payloads for leaked stale kernel memory.
6. Repeat the process to collect additional fragments that may support information gathering or a follow-on local exploit chain.

How to detect it

There are no reliable, specific indicators that prove exploitation because the vulnerability leaks small amounts of memory through legitimate kernel PF_KEY messages and may not produce errors or security logs. To investigate possible activity, review auditd, eBPF/EDR telemetry, process execution logs, and system call traces for unusual local processes opening AF_KEY/PF_KEY sockets, especially processes outside expected IPsec components such as strongSwan, libreswan, racoon, or other key management daemons. On IPsec-capable systems, correlate suspicious local process activity with bursts of PF_KEY events, IPv6 IPsec acquisition events, NAT-T mapping changes, or migration-related activity. For forensic review, look for custom binaries or scripts that create PF_KEY sockets, parse SADB messages, or repeatedly trigger IPsec policy acquisition. Absence of these artifacts does not rule out exploitation.

What your security team should do

• Inventory Linux systems and appliances that use IPsec, VPN, IKE/key management, or custom kernels with AF_KEY/PF_KEY enabled.
• Prioritize patching for multi-user systems, container hosts, VPN/IPsec gateways, and systems where untrusted local code can run.
• Apply the latest vendor kernel security update and reboot to activate the fixed kernel.
• Where PF_KEY/IPsec is not required, consider disabling the functionality or preventing the module/configuration from being used, after testing operational impact.
• Review local access controls and reduce opportunities for low-privileged users or untrusted workloads to interact with kernel networking interfaces.
• Monitor for unusual local PF_KEY/AF_KEY socket usage, especially on systems that do not normally perform IPsec key management.
• Track distribution advisories because fixed package versions are vendor-specific and may be backported without changing the upstream kernel version.