FICHE CVE

CVE-2026-53197

Publiée le 2026-06-25 · Dernière modification le 2026-07-06

🇫🇷 EN BREF

Les systèmes Linux utilisant le framework xfrm (IPsec) sont sensibles à un interblocage (deadlock) pouvant geler le noyau et provoquer le plantage du système. Un attaquant disposant d'un accès utilisateur local avec des privilèges restreints peut déclencher cet état pour provoquer un déni de service sur le reste de la machine. L'exploitation est relativement facile à exécuter et ne nécessite l'interaction d'aucun tiers, bien qu'elle suppose que l'attaquant possède déjà un compte sur le système.

CVSS 3.15.5 MOYENNE
Publiée2026-06-25
Dernière modification2026-07-06

DÉTAIL DU VECTEUR CVSS

Vecteur d'attaqueLocal
Complexité d'attaqueFaible
Privilèges requisFaibles
Interaction utilisateurAucune
PortéeInchangée
Impact sur la confidentialitéAucun
Impact sur l'intégritéAucun
Impact sur la disponibilitéÉlevé

RÉFÉRENCES

Description officielle du NVD (en anglais)

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.