CVE-2026-74359

Vulnérabilité élevée dans Linux (Linux)

CVSS 7.8 · Élevée
EPSS 0.1%
Linux•Linux•Versions : <=6.1.*, 7.1.5, 6.18.40, <=6.12.*, 0, <eee07d769da5ac4e4f7bd0bc17828646a318d499, <=7.1.*, <b6e9c82522ddaa3ac0706b295ff4a71975d4f883, <57088b06109f3222963c639d8d743f42c2899b13, 6.1.178, 6.12.97, 3d0f89bb169482d26d5aa4e82e763077e7e9bc4d, <=6.6.*, <9c747dcee164ead300de90550ad9e4122f0d1bbb, 2.6.16, <=6.18.*, 5.15.212, <c3b073a209a9baa691b744318ac929fecdd8847c, <10da12d352b7b2bb330a8609fdda9a58bf0e9856, 6.6.145, <=*, <=5.15.*, <3e83b2203aa59bd279e4f677ec793d49dc9d019e, <2.6.16, 7.2

Description

In the Linux kernel, the following vulnerability has been resolved: configfs_lookup(): don't leave ->s_dentry dangling on failure Normally ->s_dentry is cleared when dentry it's pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so ->d_iput() is not called at all. We do part of what normally would've been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear ->s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it. However, for configfs_lookup() it *does* survive, with a dangling pointer to soon to be freed dentry sitting it its ->s_dentry. Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free... This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...

Gravité et risque d'exploitation

CVE-2026-74359 obtient un score CVSS de 7.8/10, soit une gravité élevée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.13 %, ce qui la place devant 2.0 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions <=6.1.*, 7.1.5, 6.18.40, <=6.12.*, 0, <eee07d769da5ac4e4f7bd0bc17828646a318d499, <=7.1.*, <b6e9c82522ddaa3ac0706b295ff4a71975d4f883, <57088b06109f3222963c639d8d743f42c2899b13, 6.1.178, 6.12.97, 3d0f89bb169482d26d5aa4e82e763077e7e9bc4d, <=6.6.*, <9c747dcee164ead300de90550ad9e4122f0d1bbb, 2.6.16, <=6.18.*, 5.15.212, <c3b073a209a9baa691b744318ac929fecdd8847c, <10da12d352b7b2bb330a8609fdda9a58bf0e9856, 6.6.145, <=*, <=5.15.*, <3e83b2203aa59bd279e4f677ec793d49dc9d019e, <2.6.16, 7.2) 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