Heimdall Security Logo

CVE-2026-64294

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

CVSS 0.0 · Non évaluée
EPSS 0.2%
Linux•Linux•Versions : <=6.1.*, <=6.12.*, 6.18.39, 5.15.217, 0, <7368bec565bac3e536cd43579dbde1e715e6ba61, <=7.1.*, 7.1.4, <b2f3d94ea310bea9d36d53e9d9b3f45e86c1d893, 9caccd41541a6f7d6279928d9f971f6642c361af, <5c942ad7df75925ee166e7f0fb36892d8dde376b, <744b23aa430d52f5c8e4dbff7d71496d6643bed2, 5.12, <=6.6.*, <=6.18.*, 6.1.184, 6.6.145, <04ba248d02d9eaa3d9077b00a6134caa75fa3e90, <5.12, <8344bdf0629457e532797b42d9d2bbf2a2900bbf, <=*, <=5.15.*, 6.12.96, 7.2, <e187bc02f8fa4226d62814592cf064ee4557c470

Description

In the Linux kernel, the following vulnerability has been resolved: mm: do file ownership checks with the proper mount idmap Ever since idmapped mounts were introduced, inode ownership checks (for side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done against the nop_mnt_idmap, which completely ignores the file's mount's idmap. This results in odd edgecases like: 1) mount/bind-mount with an idmap userA:userB:1 2) userB runs an owner_or_capable() check on file that is owned by userA on-disk/in-memory, but owned by userB after idmap translation 3) owner_or_capable() mysteriously fails as the correct idmap wasn't supplied In the case of mincore/madvise MADV_PAGEOUT, this is usually benign, because file_permission(file, MAY_WRITE) will probably succeed, as it uses the proper idmap internally, but it does not need to be the case on e.g a 0444 file where even the owner itself doesn't have permissions to write to it. Since this is clearly not trivial to get right, introduce a file_owner_or_capable() that can carry the correct semantics, and switch the various users in mm to it. The issue was found by manual code inspection & an off-list discussion with Jan Kara.

Gravité et risque d'exploitation

CVE-2026-64294 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.16 %, ce qui la place devant 4.7 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions <=6.1.*, <=6.12.*, 6.18.39, 5.15.217, 0, <7368bec565bac3e536cd43579dbde1e715e6ba61, <=7.1.*, 7.1.4, <b2f3d94ea310bea9d36d53e9d9b3f45e86c1d893, 9caccd41541a6f7d6279928d9f971f6642c361af, <5c942ad7df75925ee166e7f0fb36892d8dde376b, <744b23aa430d52f5c8e4dbff7d71496d6643bed2, 5.12, <=6.6.*, <=6.18.*, 6.1.184, 6.6.145, <04ba248d02d9eaa3d9077b00a6134caa75fa3e90, <5.12, <8344bdf0629457e532797b42d9d2bbf2a2900bbf, <=*, <=5.15.*, 6.12.96, 7.2, <e187bc02f8fa4226d62814592cf064ee4557c470) 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

Rechercher une autre CVE