CVE-2026-31516

What it actually does

This is a Linux kernel race condition in the XFRM/IPsec policy subsystem. A privileged local caller can send an XFRM_MSG_NEWSPDINFO request that queues policy_hthresh.work on the system workqueue; if the associated network namespace is torn down before that queued work runs, xfrm_hash_rebuild() can recover a stale struct net pointer and dereference freed kernel memory. The likely outcomes are kernel memory corruption, kernel panic, or local privilege escalation, depending on allocator state and exploitability on a given kernel build. The CVSS vector indicates local access, low attack complexity, low privileges, no user interaction, and potential full confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation can allow a local user, compromised workload, or containerized process with sufficient namespace/network capabilities to crash a Linux host or potentially gain kernel-level privileges. This is most relevant for multi-user Linux systems, container platforms, CI/build runners, VPN/IPsec-enabled systems, and environments where unprivileged user or network namespace creation is enabled. It is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a very low, flat EPSS score, so broad internet-scale exploitation is unlikely; however, the business risk remains meaningful where local privilege boundaries are important.

How an attack unfolds

An attacker first obtains local code execution as a low-privileged user or inside a workload that can interact with Linux network namespaces and the XFRM netlink interface. The attacker creates or uses a network namespace, sends XFRM_MSG_NEWSPDINFO messages to trigger queuing of policy_hthresh.work, and then rapidly tears down the namespace before the queued work item executes. If the timing is won, the workqueue callback xfrm_hash_rebuild() operates on a freed struct net object. A simple exploit may cause a kernel oops or panic for denial of service; a more advanced exploit would attempt heap grooming so the freed memory is replaced with attacker-influenced data, potentially converting the use-after-free into kernel code execution or privilege escalation.

How to fix it

Apply a Linux kernel update from the operating system or appliance vendor that includes the upstream fix synchronizing policy_hthresh.work during xfrm_policy_fini() network namespace teardown. No exact fixed package versions were provided, so track the advisory for each distribution kernel stream in use and update to the first vendor kernel that explicitly includes the CVE-2026-31516 fix or the corresponding xfrm policy_hthresh.work synchronization patch. If immediate patching is not possible, reduce exposure by disabling or restricting unprivileged user namespaces where operationally feasible, limiting CAP_NET_ADMIN grants to containers and services, preventing unnecessary network namespace creation, applying seccomp/AppArmor/SELinux policies that restrict unshare/clone namespace creation for untrusted workloads, and tightly controlling access to IPsec/XFRM administration tools. Reboot into the updated kernel after patching; merely installing the package is insufficient if the running kernel is still vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated by checking uname -a and the distribution package manager after reboot. Validate vendor advisory notes or changelogs for references to CVE-2026-31516, xfrm_hash_rebuild(), policy_hthresh.work, xfrm_policy_fini(), or network namespace teardown synchronization. On container hosts, verify that untrusted workloads do not retain CAP_NET_ADMIN unless required and that unprivileged user namespace settings match the intended hardening baseline. Exposure testing should be limited to non-production systems because race-condition probes may crash the kernel. Confirm no recent kernel logs show xfrm-related use-after-free, workqueue, or net namespace teardown crashes.

Typical attack path

1. Gain local execution on a Linux system as an unprivileged or low-privileged user, or within a container/workload.
2. Obtain the ability to create or manipulate network namespaces and use XFRM netlink operations, commonly through CAP_NET_ADMIN in a namespace or permissive unprivileged namespace settings.
3. Create a network namespace and issue XFRM_MSG_NEWSPDINFO requests to queue policy_hthresh.work.
4. Rapidly destroy the network namespace so teardown frees the associated struct net before the queued work runs.
5. Race the workqueue so xfrm_hash_rebuild() dereferences stale kernel memory.
6. Use the resulting use-after-free to crash the kernel or, on exploitable builds, attempt local privilege escalation.

How to detect it

Post-exploitation detection is difficult because a successful kernel race may leave only crash artifacts, kernel oops logs, or no durable evidence beyond system instability. Review kernel logs from journald, /var/log/kern.log, /var/log/messages, dmesg buffers, crash dumps, kdump/vmcore data, and EDR telemetry for xfrm_hash_rebuild(), xfrm_policy_fini(), workqueue faults, use-after-free reports, or panics temporally correlated with network namespace creation and teardown. Look for unusual bursts of unshare, clone, ip netns, nsenter, or custom binaries invoking NETLINK_XFRM operations, especially by non-administrative users or containers. In container environments, correlate kernel crashes with workloads that have CAP_NET_ADMIN, privileged mode, or user namespace creation rights. If auditd or eBPF telemetry is available, search for repeated namespace syscalls followed by netlink socket activity using NETLINK_XFRM. Absence of these artifacts does not prove non-exploitation because kernel memory corruption may not produce stable logs.

• xfrm_hash_rebuild
• xfrm_policy_fini
• policy_hthresh.work
• XFRM_MSG_NEWSPDINFO
• NETLINK_XFRM
• BUG: unable to handle kernel paging request
• general protection fault
• kernel BUG at net/xfrm
• KASAN: use-after-free
• workqueue: xfrm_hash_rebuild
• Oops:
• Kernel panic - not syncing
• unshare --net
• ip netns add
• ip netns delete
• nsenter --net
• CAP_NET_ADMIN

What your security team should do

• Prioritize patching Linux container hosts, multi-user servers, VPN/IPsec systems, CI runners, and any systems that grant CAP_NET_ADMIN to workloads.
• Inventory running kernel versions across Linux fleets and map them to vendor advisories that include the xfrm policy_hthresh.work synchronization fix.
• Reboot systems after kernel updates and verify the active kernel is the remediated version.
• Temporarily restrict unprivileged user namespaces and network namespace creation for untrusted users where business operations allow.
• Review container and orchestration policies for unnecessary CAP_NET_ADMIN, privileged containers, host network mode, and broad namespace permissions.
• Monitor kernel logs for xfrm_hash_rebuild, xfrm_policy_fini, workqueue, use-after-free, general protection fault, and kernel panic events following namespace activity.
• Treat unexplained kernel crashes on shared Linux hosts as potentially security-relevant until xfrm-related indicators are ruled out.
• Because EPSS is low, not trending upward, and there is no known exploit maturity or KEV listing in the provided data, schedule broad fleet remediation through normal kernel patch cycles while accelerating remediation for high-risk multi-tenant systems.