CVE-2025-68768

Vulnérabilité non évaluée dans Linux (Linux)

CVSS 0.0 · Non évaluée
EPSS 0.2%
Linux•Linux•Versions : <=*, 5.3, <=6.12.*, 6.19, d5dd88794a13c2f24cce31abad7a0a6c5e0ed2db, 6.12.93, <=6.18.*, <5.3, <c70df25214ac9b32b53e18e6ae3b8f073ffa6903, <22ee4010866da81aeee08e1ea3fddbe418feb212, 6.6.143, <=6.6.*, 0, 6.18.3, <543555954b1ee8d1903a7020324efb41b0c97428, <006a5035b495dec008805df249f92c22c89c3d2e

Description

In the Linux kernel, the following vulnerability has been resolved: inet: frags: flush pending skbs in fqdir_pre_exit() We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports. On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references. The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook. Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush. The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.

Gravité et risque d'exploitation

CVE-2025-68768 obtient un score CVSS de 0.0/10, soit une gravité non évaluée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.20 %, ce qui la place devant 9.3 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions <=*, 5.3, <=6.12.*, 6.19, d5dd88794a13c2f24cce31abad7a0a6c5e0ed2db, 6.12.93, <=6.18.*, <5.3, <c70df25214ac9b32b53e18e6ae3b8f073ffa6903, <22ee4010866da81aeee08e1ea3fddbe418feb212, 6.6.143, <=6.6.*, 0, 6.18.3, <543555954b1ee8d1903a7020324efb41b0c97428, <006a5035b495dec008805df249f92c22c89c3d2e) est présent sur votre parc.
  • Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
  • À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
  • Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références