CVE-2026-43107

What it actually does

This is a local Linux kernel denial-of-service flaw in the XFRM/IPsec netlink path. When an XFRM state has an interface identifier set, the kernel underestimates the size needed for an asynchronous event response. A crafted local netlink interaction can cause message construction to fail with EMSGSIZE and trigger a BUG_ON in xfrm_get_ae(), resulting in a kernel panic. The impact is availability loss of the affected host; the flaw does not directly provide code execution, data disclosure, or privilege escalation.

Why it matters to the business

Successful exploitation can abruptly crash Linux systems, interrupting workloads, VPN/IPsec functions, containers, network appliances, or services hosted on the affected kernel. Because exploitation requires local access and appropriate netlink/XFRM capability, broad internet-scale exploitation is unlikely, and current EPSS is very low with no known KEV listing or public exploit maturity. Risk is higher on shared Linux hosts, container platforms that grant CAP_NET_ADMIN, systems using IPsec/XFRM, and environments where untrusted users can run local code.

How an attack unfolds

An attacker first obtains local execution on a vulnerable Linux host, or inside a sufficiently privileged container or network namespace. They then use XFRM netlink operations to create or interact with an XFRM state that has an if_id value. Next, they issue a request that causes the kernel to build an XFRM asynchronous event response for that state. Because the kernel allocated the reply buffer without accounting for the XFRMA_IF_ID attribute, the response builder fails with a size error. Vulnerable kernels then hit a BUG_ON condition instead of unwinding the error path, causing a kernel panic and taking the host or affected node offline.

How to fix it

Update the Linux kernel to a vendor-supported build that includes the upstream fix for the XFRM change described as accounting for XFRMA_IF_ID in xfrm_aevent_msgsize() and replacing the BUG_ON error path with normal error handling. No universal fixed package version was provided, so use the affected distribution or appliance vendor advisory as the source of truth. Where immediate patching is not possible, reduce exposure by removing unnecessary CAP_NET_ADMIN from containers and services, limiting local shell access, disabling unneeded IPsec/XFRM functionality where operationally safe, restricting unprivileged user namespaces if they allow access to relevant capabilities, and monitoring for unusual XFRM netlink activity. A reboot into the fixed kernel is required after package installation for the remediation to take effect.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking the active kernel version after reboot and mapping it to the vendor advisory that includes the XFRM fix. Review distribution changelogs or kernel build metadata for references to XFRMA_IF_ID, xfrm_aevent_msgsize, xfrm_get_ae, or the relevant CVE. Validate that privileged containers and services do not retain CAP_NET_ADMIN unless required. On non-production systems only, controlled XFRM regression testing can be used to verify that asynchronous event handling returns an error or succeeds safely rather than panicking. Also confirm there are no recent kernel panic logs with call traces through xfrm_get_ae() or build_aevent().

Typical attack path

1. Obtain local shell access, scheduled task execution, or container execution on a Linux system running a vulnerable kernel.
2. Gain the ability to perform XFRM netlink operations, commonly through CAP_NET_ADMIN or equivalent privileges in the relevant namespace.
3. Create or use an XFRM state with an interface identifier set.
4. Trigger an XFRM asynchronous event query or related netlink operation that causes xfrm_get_ae() to build a response containing XFRMA_IF_ID.
5. Cause the undersized response allocation to fail during attribute append.
6. Trigger the vulnerable BUG_ON path, resulting in a kernel panic and denial of service.

How to detect it

Look for evidence of sudden kernel panics or reboots preceded by XFRM/IPsec netlink activity. Primary sources include kernel logs from journalctl or /var/log/kern.log, crash dumps from kdump, system reboot records, auditd logs, sudo/session logs, container runtime audit records, and EDR telemetry for local execution of XFRM tooling. Relevant artifacts include call traces referencing xfrm_get_ae(), build_aevent(), xfrm_aevent_msgsize(), XFRMA_IF_ID, NETLINK_XFRM, or BUG_ON. Also review activity from processes such as ip xfrm or custom netlink utilities, especially when executed by unexpected users or containers with CAP_NET_ADMIN. Because exploitation causes a crash rather than persistent compromise, indicators may be limited to pre-crash logs, audit records, and memory crash dumps.

• xfrm_get_ae
• build_aevent
• xfrm_aevent_msgsize
• XFRMA_IF_ID
• NETLINK_XFRM
• ip xfrm
• kernel BUG
• BUG_ON
• EMSGSIZE
• net/xfrm/xfrm_user.c
• CAP_NET_ADMIN
• audit:.*capability=.*CAP_NET_ADMIN
• journalctl -k
• /var/log/kern.log
• /var/crash
• /var/lib/systemd/coredump

What your security team should do

• Prioritize patching Linux systems that allow local multi-user access, run untrusted workloads, host containers with CAP_NET_ADMIN, or rely on IPsec/XFRM networking.
• Inventory container, Kubernetes, and service configurations for CAP_NET_ADMIN and remove it wherever it is not strictly required.
• Review VPN, IPsec, network appliance, and edge Linux systems for vulnerable kernels because XFRM functionality is more likely to be present or used there.
• Search historical kernel logs and crash dumps for XFRM-related panic traces to determine whether denial-of-service attempts may have occurred.
• Add monitoring for unexpected use of ip xfrm tooling, NETLINK_XFRM activity, and local processes with CAP_NET_ADMIN on sensitive hosts.
• If patching must be delayed, restrict local access, harden sudo rules, limit namespace creation, and isolate workloads that require network administration capabilities.
• Track vendor advisories because fixed versions are distribution-specific and may be backported without changing to an obviously newer upstream kernel version.