CVE-2026-53197

What it actually does

This is a Linux kernel race/deadlock flaw in the XFRM IP-TFS code path. During IP-TFS state destruction, the kernel can call hrtimer_cancel() while holding a spinlock that the corresponding high-resolution timer callback also tries to acquire. On SMP systems, this can create an ABBA lock inversion between the state-destruction path and a softirq timer callback, causing one or more CPUs or the affected networking path to spin indefinitely. The practical technical impact is denial of service through kernel deadlock or severe network-stack instability, especially when IP-TFS/XFRM states are being torn down while output or drop timers are active.

Why it matters to the business

Systems using Linux IPsec/XFRM with IP-TFS may experience hangs, stalled networking, or service outages if the vulnerable race is triggered. The current public exploitation signal is low: it is not listed in CISA KEV, is not associated with ransomware use, has no known public exploit maturity, and has a low EPSS score. However, kernel deadlocks can have high operational impact when they affect VPN gateways, routers, container hosts, or other infrastructure that depends on stable IPsec/XFRM networking.

How an attack unfolds

An attacker or fault condition must cause an IP-TFS-enabled XFRM state to be destroyed while one of its related high-resolution timers is active or executing on another CPU. A likely exploitation scenario requires local administrative network privileges, such as CAP_NET_ADMIN, or control over automation that creates and deletes XFRM/IPsec state. The attacker configures or influences IP-TFS traffic so that the output or drop timer is active, then repeatedly tears down the associated XFRM state. If timing aligns, one CPU holds the IP-TFS state lock and waits for hrtimer cancellation while another CPU is running the timer callback and waiting for the same state lock, resulting in a circular wait. Remote traffic alone is unlikely to be sufficient unless the target already uses IP-TFS and the attacker can reliably influence both traffic timing and tunnel/state teardown behavior.

How to fix it

Apply a kernel update from the operating system or appliance vendor that includes the IP-TFS/XFRM fix moving hrtimer_cancel() outside the affected spinlock regions in iptfs_destroy_state(). No specific fixed package versions were provided in the input, so use vendor advisories and kernel changelogs to identify the corrected build for each distribution or appliance. Where immediate patching is not possible, reduce exposure by disabling or avoiding IP-TFS where it is not required, minimizing dynamic creation/deletion of XFRM/IPsec states, restricting CAP_NET_ADMIN and privileged network-management access, and monitoring or rate-limiting automation that repeatedly tears down IPsec/XFRM tunnels. Standard host firewalls do not directly mitigate a local kernel deadlock condition if privileged XFRM management remains available.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the upstream fix for the XFRM IP-TFS iptfs_destroy_state() hrtimer deadlock. Validate through the distribution package changelog, vendor security advisory, kernel commit history, or source inspection showing hrtimer_cancel() is called before acquiring the relevant IP-TFS locks. Confirm the running kernel is the updated version after reboot, not only that the package is installed. For exposure validation, check whether IP-TFS/XFRM is in use on the system, whether privileged users or services can create/delete XFRM state, and whether IPsec/XFRM tunnels are frequently recycled. In a controlled non-production test, repeated creation and deletion of IP-TFS XFRM state under traffic should no longer produce soft lockups, hung tasks, or timer-related kernel stalls.

Typical attack path

1. Identify a Linux system using XFRM/IPsec with IP-TFS functionality enabled or configured.
2. Obtain local privileged network-control capability, compromise a component that manages IPsec/XFRM state, or influence an environment where XFRM states are frequently created and destroyed.
3. Generate or trigger IP-TFS traffic patterns that cause the output or drop timers to become active.
4. Trigger deletion or teardown of the associated XFRM/IP-TFS state while timer callbacks may be running on another CPU.
5. Repeat the timing-sensitive sequence until the vulnerable lock ordering occurs.
6. Cause a kernel deadlock, CPU soft lockup, network disruption, or full service outage requiring recovery or reboot.

How to detect it

Look for evidence of prior exploitation or triggering in kernel and system logs rather than traditional file or network indicators. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore data, watchdog logs, hypervisor reset records, and network appliance health logs. Search for soft lockups, hard lockups, hung tasks, RCU stalls, watchdog resets, or kernel call traces referencing IP-TFS, XFRM, hrtimer cancellation, or the affected timer callbacks. Correlate these events with IPsec tunnel teardown, XFRM state deletion, VPN rekey/restart events, privileged container activity, or automation that runs ip xfrm commands. Because this is a deadlock bug, successful triggering may leave only availability symptoms, abrupt reboots, or incomplete logs rather than a conventional IOC. There are no known threat actors or campaigns tied to this issue in the provided data.

• iptfs_destroy_state
• iptfs_delay_timer
• iptfs_drop_timer
• hrtimer_cancel
• hrtimer_cancel_wait_running
• softirq_expiry_lock
• xfrm
• IP-TFS
• iptfs
• BUG: soft lockup
• BUG: hard lockup
• watchdog: BUG: soft lockup
• INFO: task
• blocked for more than
• rcu: INFO: rcu_preempt detected stalls
• NMI watchdog: Watchdog detected hard LOCKUP
• kernel: Call Trace
• ip xfrm state delete
• ip xfrm state flush

What your security team should do

• Prioritize patching Linux systems that act as IPsec gateways, VPN concentrators, routers, network appliances, Kubernetes/container hosts, or other infrastructure using XFRM/IP-TFS.
• Inventory systems with XFRM/IPsec enabled and determine whether IP-TFS is configured or supported in the deployed kernel.
• Restrict CAP_NET_ADMIN and access to tooling that can create or delete XFRM state, including privileged containers and network-management automation.
• Review recent kernel logs for soft lockups, hung tasks, or call traces involving iptfs_destroy_state(), iptfs_delay_timer(), iptfs_drop_timer(), hrtimer_cancel(), or XFRM teardown.
• If patching is delayed, disable IP-TFS where feasible and avoid operational workflows that rapidly create and destroy IPsec/XFRM states under load.
• Track vendor advisories because exact fixed versions vary by Linux distribution and kernel branch.
• Treat unexplained hangs on IPsec/XFRM systems as potential vulnerability triggers even though there is currently no known KEV listing, ransomware association, or public exploit maturity.