In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state() iptfs_destroy_state()… (CVE-2026-53197)
In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state() iptfs_destroy_state() calls hrtimer_cancel() while holding a spinlock that the timer callback also acquires, leading to an ABBA deadlock on SMP systems. For the output timer (iptfs_timer): - iptfs_destroy_state() holds x->lock, calls hrtimer_cancel() - iptfs_delay_timer() callback takes x->lock For the drop timer (drop_timer): - iptfs_destroy_state() holds drop_lock, calls hrtimer_cancel() - iptfs_drop_timer() callback takes drop_lock Both timers use HRTIMER_MODE_REL_SOFT, so their callbacks run in softirq context. When hrtimer_cancel() is called for a soft timer that is currently executing on another CPU, hrtimer_cancel_wait_running() spins on softirq_expiry_lock -- the same lock held by the softirq running the callback. If the callback is blocked waiting for the spinlock held by the caller of hrtimer_cancel(), a circular dependency forms: CPU 0: holds lock_A -> waits for softirq_expiry_lock CPU 1: holds softirq_expiry_lock -> waits for lock_A Fix by calling hrtimer_cancel() before acquiring the respective locks. hrtimer_cancel() is safe to call without holding any lock and will wait for any in-progress callback to complete. For the output timer, the lock is still acquired afterwards to drain the packet queue. For the drop timer, the lock/unlock pair is removed entirely since it only existed to serialize with the timer callback, which hrtimer_cancel() already guarantees. Found by source code audit.
AI Analysis
Technical Summary
CVE-2026-53197 describes an ABBA deadlock in the Linux kernel's iptfs subsystem. The function iptfs_destroy_state() calls hrtimer_cancel() while holding spinlocks (x->lock or drop_lock) that the timer callbacks (iptfs_delay_timer and iptfs_drop_timer) also acquire. Both timers run in softirq context using HRTIMER_MODE_REL_SOFT. When hrtimer_cancel() is called on a soft timer currently executing on another CPU, it spins on softirq_expiry_lock, which the callback holds. If the callback waits on the spinlock held by iptfs_destroy_state(), a circular wait forms between CPUs, causing a deadlock. The resolution is to call hrtimer_cancel() before acquiring the respective locks, as hrtimer_cancel() safely waits for any in-progress callback without requiring locks. This eliminates the circular dependency and deadlock.
Potential Impact
The vulnerability can cause a deadlock on symmetric multiprocessing (SMP) systems when iptfs_destroy_state() is called, leading to a denial of service due to kernel hang or stall. There is no impact on confidentiality or integrity, only availability is affected.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The fix involves modifying the Linux kernel iptfs code to call hrtimer_cancel() before acquiring the relevant spinlocks. Until an official patch is available and applied, avoid triggering iptfs_destroy_state() operations concurrently on SMP systems if possible.
In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state() iptfs_destroy_state()… (CVE-2026-53197)
Description
In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state() iptfs_destroy_state() calls hrtimer_cancel() while holding a spinlock that the timer callback also acquires, leading to an ABBA deadlock on SMP systems. For the output timer (iptfs_timer): - iptfs_destroy_state() holds x->lock, calls hrtimer_cancel() - iptfs_delay_timer() callback takes x->lock For the drop timer (drop_timer): - iptfs_destroy_state() holds drop_lock, calls hrtimer_cancel() - iptfs_drop_timer() callback takes drop_lock Both timers use HRTIMER_MODE_REL_SOFT, so their callbacks run in softirq context. When hrtimer_cancel() is called for a soft timer that is currently executing on another CPU, hrtimer_cancel_wait_running() spins on softirq_expiry_lock -- the same lock held by the softirq running the callback. If the callback is blocked waiting for the spinlock held by the caller of hrtimer_cancel(), a circular dependency forms: CPU 0: holds lock_A -> waits for softirq_expiry_lock CPU 1: holds softirq_expiry_lock -> waits for lock_A Fix by calling hrtimer_cancel() before acquiring the respective locks. hrtimer_cancel() is safe to call without holding any lock and will wait for any in-progress callback to complete. For the output timer, the lock is still acquired afterwards to drain the packet queue. For the drop timer, the lock/unlock pair is removed entirely since it only existed to serialize with the timer callback, which hrtimer_cancel() already guarantees. Found by source code audit.
CVSS v3.1
Score 5.5medium
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
CVE-2026-53197 describes an ABBA deadlock in the Linux kernel's iptfs subsystem. The function iptfs_destroy_state() calls hrtimer_cancel() while holding spinlocks (x->lock or drop_lock) that the timer callbacks (iptfs_delay_timer and iptfs_drop_timer) also acquire. Both timers run in softirq context using HRTIMER_MODE_REL_SOFT. When hrtimer_cancel() is called on a soft timer currently executing on another CPU, it spins on softirq_expiry_lock, which the callback holds. If the callback waits on the spinlock held by iptfs_destroy_state(), a circular wait forms between CPUs, causing a deadlock. The resolution is to call hrtimer_cancel() before acquiring the respective locks, as hrtimer_cancel() safely waits for any in-progress callback without requiring locks. This eliminates the circular dependency and deadlock.
Potential Impact
The vulnerability can cause a deadlock on symmetric multiprocessing (SMP) systems when iptfs_destroy_state() is called, leading to a denial of service due to kernel hang or stall. There is no impact on confidentiality or integrity, only availability is affected.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The fix involves modifying the Linux kernel iptfs code to call hrtimer_cancel() before acquiring the relevant spinlocks. Until an official patch is available and applied, avoid triggering iptfs_destroy_state() operations concurrently on SMP systems if possible.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-cwx4-f9x9-pqhh
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-53197"]
- Ecosystems
- []
- Database Specific Severity
- MODERATE
- Cvss Version
- 3.1
Threat ID: 6a4c345b27e9c797195fec78
Added to database: 07/06/2026, 23:03:55 UTC
Last enriched: 07/06/2026, 23:37:35 UTC
Last updated: 07/31/2026, 19:24:48 UTC
Views: 4
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.