PT-2026-52293 · Linux · Linux
Published
2026-06-25
·
Updated
2026-06-25
·
CVE-2026-53197
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux