CVE-2026-43090

What it actually does

This is a local denial-of-service flaw in the Linux kernel XFRM/IPsec policy migration code. The vulnerable path in xfrm_migrate_policy_find() incorrectly increments the reference count of an XFRM policy object a second time even though the lookup routine already returns the object with a held reference. Repeated triggering leaks xfrm_policy allocations in kernel memory. Over time, the leak can exhaust kernel memory or pressure slab caches, leading to degraded system performance, failed network/IPsec operations, process termination by the OOM killer, or a system crash/reboot. The vulnerability does not provide confidentiality or integrity impact by itself and does not directly enable code execution or privilege escalation.

Why it matters to the business

An attacker with local access and sufficient privilege to exercise XFRM/IPsec policy migration paths could degrade or take down Linux systems by consuming kernel memory. Systems that rely on IPsec/XFRM functionality, containerized networking, VPN gateways, network appliances, or multi-user Linux hosts may face service instability or outages if exposed to untrusted local users or workloads. The CVSS score is moderate, EPSS is very low and stable, it is not in CISA KEV, and there is no known mature public exploitation, so remediation should be prioritized through normal kernel patch cycles unless the system allows untrusted local code execution or heavily uses IPsec/XFRM features.

How an attack unfolds

An attacker first obtains local execution on a vulnerable Linux system, such as through a shell, compromised application account, container escape-adjacent access with relevant networking capabilities, or another low-privileged foothold that can interact with the affected XFRM/IPsec policy migration functionality. The attacker then repeatedly invokes the kernel path that performs XFRM policy migration lookups. Each successful trigger causes xfrm_migrate_policy_find() to leak a reference to an allocated xfrm_policy object because the policy reference count is incremented redundantly and not released. By automating this operation in a loop, the attacker gradually consumes unswappable kernel memory. As memory pressure increases, the host may log allocation failures, kill unrelated processes, disrupt IPsec/network services, or become unresponsive. The attack outcome is denial of service rather than data theft or direct privilege gain.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the XFRM refcount leak in xfrm_migrate_policy_find(), specifically the change that removes the redundant xfrm_pol_hold_rcu() call. Because no exact fixed package versions were provided, use the latest security-supported kernel from the operating system or appliance vendor and verify the vendor advisory references this CVE or the XFRM policy migration refcount leak fix. Reboot into the patched kernel after installation; applying packages without booting the new kernel does not remediate the running system. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, removing unnecessary CAP_NET_ADMIN or equivalent network-administration capabilities from containers and services, disabling or minimizing IPsec/XFRM functionality where operationally feasible, and monitoring for memory pressure or abnormal XFRM activity. A reboot can temporarily clear leaked kernel objects but is not a permanent fix.

How to confirm the fix worked

Confirm remediation by verifying the running kernel, not only the installed package, is a vendor-fixed build. Check the active version with uname -a or equivalent fleet inventory and compare it against the vendor security advisory or changelog for the XFRM refcount leak fix in xfrm_migrate_policy_find(). If source or debug symbols are available, confirm the patched code path no longer performs the redundant xfrm_pol_hold_rcu() call after the lookup returns a held policy reference. Validate exposure by identifying systems with IPsec/XFRM usage, systems granting CAP_NET_ADMIN to containers or services, and systems allowing untrusted local users. After patching and rebooting, monitor kernel logs and memory/slab metrics under normal XFRM workloads to confirm there is no continuing growth in xfrm_policy-related allocations or repeated OOM activity.

Typical attack path

1. Gain local execution on a Linux system running a vulnerable kernel.
2. Obtain or use privileges/capabilities needed to manipulate XFRM/IPsec policy migration paths, such as relevant networking administration capability where required.
3. Create or reference XFRM/IPsec policies that exercise xfrm_migrate_policy_find().
4. Repeatedly trigger the vulnerable policy migration lookup path to leak xfrm_policy references.
5. Continue the loop until kernel memory pressure causes service degradation, OOM killer activity, failed allocations, network/IPsec instability, or host crash.
6. Optionally stop activity after disruption to reduce obvious process-level evidence while leaked kernel objects remain until reboot or cleanup through fixed code paths.

How to detect it

Look for evidence of prior exploitation by correlating local user or workload activity with unexplained kernel memory growth, OOM killer events, allocation failures, and XFRM/IPsec policy-management operations. Useful log sources include kernel logs from dmesg, journald, /var/log/kern.log, /var/log/messages, auditd logs for privileged networking operations, sudo/session logs, container runtime logs, and EDR telemetry for processes invoking IPsec/XFRM tooling or using NETLINK_XFRM. Indicators are strongest when repeated XFRM/IPsec policy changes or migrations precede steadily increasing slab/kernel memory usage and OOM events without a corresponding user-space memory consumer. On debug or test kernels with leak detection enabled, search for kmemleak or BUG reports referencing xfrm_policy_alloc or xfrm_migrate_policy_find. On production systems, search for OOM killer entries, page allocation failures, network stack allocation failures, and abnormal repeated use of tools such as ip xfrm, setkey, strongSwan/charon helpers, or custom binaries with CAP_NET_ADMIN. Absence of these artifacts does not rule out exploitation because the primary effect is a kernel reference leak, which may leave limited application-level traces.

• xfrm_policy_alloc
• xfrm_migrate_policy_find
• xfrm_pol_hold_rcu
• BUG: memory leak
• unreferenced object
• comm "syz.
• Out of memory: Killed process
• oom-killer
• invoked oom-killer
• page allocation failure
• kmemleak
• NETLINK_XFRM
• ip xfrm
• /proc/net/xfrm_stat
• /var/log/kern.log
• /var/log/messages
• charon
• setkey

What your security team should do

• Inventory Linux systems and appliances that use IPsec/XFRM, VPN functionality, advanced routing, container networking, or grant network-administration capabilities to local workloads.
• Patch affected systems with the latest vendor-supported kernel containing the XFRM refcount leak fix, then reboot to ensure the fixed kernel is running.
• Prioritize shared multi-user hosts, container platforms, VPN/IPsec gateways, and internet-facing appliances where a local foothold could be converted into service disruption.
• Temporarily restrict CAP_NET_ADMIN and other network-management privileges from nonessential containers, services, and user sessions until patched.
• Monitor kernel logs, OOM killer events, slab memory growth, and XFRM/IPsec administrative activity for signs of attempted memory-exhaustion abuse.
• If suspicious memory exhaustion is observed, preserve kernel logs, audit logs, process accounting, and container runtime events before rebooting, then patch before returning the host to service.
• Track vendor advisories because fixed package versions vary by distribution and no product-specific fixed versions were supplied in the input.