CVE-2026-43091

What it actually does

This is a Linux kernel use-after-free condition in the XFRM/IPsec policy subsystem during network namespace teardown. The kernel frees XFRM policy destination hash tables after removing policies, but it does not first wait for all concurrent RCU readers to finish. Because those tables are published and accessed through RCU primitives, a racing reader can dereference memory that has already been freed. With local code execution and low privileges, an attacker may be able to trigger the race through namespace and XFRM policy activity, causing kernel memory corruption. Successful exploitation could lead to local privilege escalation, information disclosure, system crash, or arbitrary kernel-mode code execution, depending on kernel configuration, heap state, and exploit reliability.

Why it matters to the business

An attacker who already has a low-privileged local foothold on a Linux system may be able to escalate to full control of the host or disrupt service by crashing the kernel. This is most relevant for multi-user Linux servers, container hosts, CI/CD workers, shared compute platforms, and systems where untrusted users or workloads can create network namespaces or interact with IPsec/XFRM functionality. The current EPSS is very low, there is no known CISA KEV listing, no known ransomware association, and no public exploit maturity reported, so urgency is lower than for actively exploited internet-facing issues; however, kernel privilege-escalation bugs should still be prioritized on shared or containerized infrastructure.

How an attack unfolds

An attacker first obtains the ability to run local code as a low-privileged user. They then attempt to create or manipulate network namespaces and XFRM/IPsec policy state while causing namespace teardown to occur concurrently with XFRM policy lookups. The vulnerable path frees the policy_bydst hash tables before an RCU grace period guarantees that all readers are done. If the attacker wins the race, a kernel thread may dereference freed memory. A simple exploit may only cause a denial of service through a kernel oops or panic, while a more advanced exploit would attempt to reclaim the freed memory with attacker-controlled kernel heap objects and steer the stale pointer access toward privilege escalation or kernel code execution. No mature public exploit is currently reported, and exploitation is expected to be local and race-dependent.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the XFRM fix adding an RCU grace-period wait, specifically synchronize_rcu(), before freeing XFRM policy hash tables during network namespace teardown. No exact fixed upstream or per-distribution package versions were provided in the input, so use the fixed kernel versions published by the relevant Linux distribution or appliance vendor. Reboot into the patched kernel after installation; installing the package alone is not sufficient if the system continues running the old kernel. Where immediate patching is not possible, reduce exposure by restricting local shell access, limiting untrusted workloads, disabling unprivileged user namespace creation where operationally feasible, limiting container privileges, avoiding CAP_NET_ADMIN for untrusted containers, and monitoring for kernel crashes or suspicious namespace/XFRM activity. Mitigations should be treated as risk reduction only, not a complete fix.

How to confirm the fix worked

Confirm the system is running a kernel build that contains the XFRM RCU synchronization fix, not merely that a patched package is installed. Validate with the distribution advisory, package changelog, kernel release notes, or source patch history for the addition of synchronize_rcu() in the XFRM policy namespace teardown path before freeing policy hash tables. Check the active kernel with commands such as uname -r and compare it to the vendor-fixed version. On source-based or custom kernels, verify the patched xfrm_policy_fini() logic includes an RCU grace-period wait before policy hash table memory is released. Confirm untrusted users or containers cannot create network namespaces or obtain CAP_NET_ADMIN unless required. Review recent kernel logs for oops, panic, KASAN, use-after-free, or XFRM-related faults that may indicate exposure or attempted exploitation.

Typical attack path

1. Gain local low-privileged code execution on a Linux host.
2. Determine whether the running kernel includes the vulnerable XFRM network namespace teardown behavior.
3. Create or manipulate network namespaces, if permitted by the system configuration.
4. Trigger XFRM/IPsec policy creation, lookup, deletion, and namespace teardown activity in a tight race.
5. Cause an RCU reader to access the freed policy_bydst hash table memory.
6. Attempt to convert the resulting use-after-free into a kernel crash, information leak, or privilege escalation.
7. If privilege escalation succeeds, establish root-level control of the host and potentially access or tamper with other workloads.

How to detect it

Look for evidence of local exploitation attempts or instability rather than network indicators, because this is a local kernel memory-corruption issue. Relevant sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dump infrastructure, KASAN reports, kernel oops records, auditd logs, EDR telemetry, container runtime logs, and Kubernetes node/container audit logs. Search for kernel faults involving XFRM policy cleanup, RCU, network namespace teardown, use-after-free, general protection faults, page faults, or crashes shortly after namespace-heavy activity. Correlate suspicious events with local users or containers creating and deleting network namespaces, using ip xfrm commands, requesting CAP_NET_ADMIN, running privileged containers, or rapidly spawning namespace operations. Forensic review should include recent privilege changes, unexpected root-owned processes originating from low-privileged users, anomalous container escapes, unexplained node reboots, and kernel crash dumps showing xfrm_policy_fini, policy_bydst, or RCU-related stack frames. There are no reliable remote network IOCs for this vulnerability.

• BUG: KASAN: use-after-free
• use-after-free in xfrm_policy_fini
• xfrm_policy_fini
• policy_bydst
• xfrm: Wait for RCU readers during policy netns exit
• general protection fault
• kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• RCU detected stall
• synchronize_rcu
• ip xfrm policy
• ip netns add
• ip netns delete
• CAP_NET_ADMIN

What your security team should do

• Inventory Linux systems, prioritizing multi-user servers, container hosts, Kubernetes nodes, CI runners, shared development systems, and hosts that allow untrusted local code execution.
• Patch affected Linux kernels using vendor-provided updates and reboot to ensure the fixed kernel is active.
• Prioritize faster remediation on systems where unprivileged users can create user or network namespaces, or where containers run with CAP_NET_ADMIN or elevated privileges.
• Temporarily restrict unprivileged user namespaces, network namespace creation, and CAP_NET_ADMIN assignment for untrusted workloads where compatible with operations.
• Review kernel logs and crash telemetry for use-after-free, KASAN, XFRM, RCU, or namespace teardown faults since publication.
• Ensure EDR, auditd, and container runtime logging capture local privilege-escalation behaviors, including suspicious namespace creation and unexpected root shells.
• Monitor vendor advisories for exact fixed kernel package versions and any change in exploit maturity, EPSS trajectory, KEV status, or public proof-of-concept availability.
• Treat kernel crashes on shared infrastructure as potentially security-relevant until ruled out, preserving logs and crash dumps for analysis.