CVE-2026-89485

Vulnérabilité critique dans Linux (Linux)

CVSS 9.8 · Critique
EPSS 0.7%
Linux•Linux•Versions : <=6.1.*, <41f0a6d31615fcae261bf28a0aa50050dc93a401, <=6.12.*, 5.15.221, <e3c413f789eaf0170275c7eba523ead73d963f30, <e999a88133654c6dfc68487fb49da5f20dfa2d4f, 2.6.18, 5.10.270, 0, 7.2.4, 6.1.188, <550c19222c7132c888e23c9d89079ba1c9bc4cca, <2.6.18, <c24bdb7df2f34bdc38ca8a73796f5acb40f1830c, <=5.10.*, <=6.6.*, 6.6.157, <08a455f87b14c7ff22ae3fdadda62a796a3a5572, 01df9c5e918ae5559f2d96da0143f8bfbb9e6171, <350087f231c11efcd288c310707c40eab63ca583, <=6.18.*, <=7.2.*, <=*, <=5.15.*, <526c49cff3f72c3ec74752016380c7567040581b, 6.18.50, 6.12.109, 7.3

Description

In the Linux kernel, the following vulnerability has been resolved: lockd: pin next file across nlm_inspect_file lock-drop nlm_traverse_files() pins the current file with f_count++ across a mutex_unlock for nlm_inspect_file(), but nothing pins the saved next pointer. A concurrent nlm_release_file() can kfree the next file during the unlock window, and the iterator dereferences freed memory on the next loop step. Pin both current and next before the lock-drop. Advance by swapping the pinned cursors at the end of each iteration so next is always held alive across the unlock. Always call nlm_file_release() after dropping the iteration pin, regardless of whether the file matched the predicate. Use nlm_file_inuse(), which does a live walk of the inode lock list, rather than the cached f_locks field, so skipped files that never ran nlm_inspect_file() are evaluated correctly. Because every file in a hash bucket is now pinned and released, files skipped by the is_failover_file predicate that have no locks, blocks, shares, or external references are deleted during traversal. The old code never evaluated skipped files for cleanup. The new behavior is intentional: such files are stale and should not persist in the table.

Gravité et risque d'exploitation

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

Que faire ?

  • Vérifiez si Linux (versions <=6.1.*, <41f0a6d31615fcae261bf28a0aa50050dc93a401, <=6.12.*, 5.15.221, <e3c413f789eaf0170275c7eba523ead73d963f30, <e999a88133654c6dfc68487fb49da5f20dfa2d4f, 2.6.18, 5.10.270, 0, 7.2.4, 6.1.188, <550c19222c7132c888e23c9d89079ba1c9bc4cca, <2.6.18, <c24bdb7df2f34bdc38ca8a73796f5acb40f1830c, <=5.10.*, <=6.6.*, 6.6.157, <08a455f87b14c7ff22ae3fdadda62a796a3a5572, 01df9c5e918ae5559f2d96da0143f8bfbb9e6171, <350087f231c11efcd288c310707c40eab63ca583, <=6.18.*, <=7.2.*, <=*, <=5.15.*, <526c49cff3f72c3ec74752016380c7567040581b, 6.18.50, 6.12.109, 7.3) 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