Linux Kernel up to 6.18.35/7.0.12 xfrm iptfs_destroy_state lock deserialization

Summaryinfo

A vulnerability categorized as critical has been discovered in Linux Kernel up to 6.18.35/7.0.12. Affected is the function iptfs_destroy_state of the component xfrm. Such manipulation of the argument lock leads to deserialization. This vulnerability is traded as CVE-2026-53197. There is no exploit available. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 6.18.35/7.0.12. It has been rated as critical. Affected by this issue is the function iptfs_destroy_state of the component xfrm. The manipulation of the argument lock with an unknown input leads to a deserialization vulnerability. Using CWE to declare the problem leads to CWE-502. The product deserializes untrusted data without sufficiently verifying that the resulting data will be valid. The impact remains unknown. CVE summarizes:

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.

The advisory is shared for download at git.kernel.org. This vulnerability is handled as CVE-2026-53197 since 06/09/2026. The exploitation is known to be difficult. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $0-$5k (estimation calculated on 06/25/2026).

Upgrading to version 6.18.36 or 7.0.13 eliminates this vulnerability. Applying the patch a13ca53e47e500854a3b9ec18b5dc83acfec863e/822b98d354e63e8249e85473c5f3c519f3c9cecc/c8a8a75b733467b00c08b91a38dbaf207a08ed6e is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.18.7
• 6.18.8
• 6.18.9
• 6.18.10
• 6.18.11
• 6.18.12
• 6.18.13
• 6.18.14
• 6.18.15
• 6.18.16
• 6.18.17
• 6.18.18
• 6.18.19
• 6.18.20
• 6.18.21
• 6.18.22
• 6.18.23
• 6.18.24
• 6.18.25
• 6.18.26
• 6.18.27
• 6.18.28
• 6.18.29
• 6.18.30
• 6.18.31
• 6.18.32
• 6.18.33
• 6.18.34
• 6.18.35
• 7.0.0
• 7.0.1
• 7.0.2
• 7.0.3
• 7.0.4
• 7.0.5
• 7.0.6
• 7.0.7
• 7.0.8
• 7.0.9
• 7.0.10
• 7.0.11
• 7.0.12

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion