CVE-2026-68147

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

CVSS 7.8 · Élevée
EPSS 0.1%
Linux•Linux•Versions : <=6.1.*, <=6.12.*, <81ea8e8221853950c47dac7164f27c63a96f8f86, 6.12.101, <97a688563be71ec6fefc071aff69a66c69dbe244, 0, <=7.1.*, <bc2d630296e0e049210ec05ff08459a6893ae749, <6fe4e4b8259e1330945b5f3c9476e08473b8e0e8, <=6.6.*, 6.18.42, <4462ac3d90e897dda52ce4b6af2d526ddae835a8, 7.1.6, 6.1.183, <=6.18.*, <bab016bb80d74a9d1f7d4121a7fc1cb529b470e0, 6.1, 22e9947a4b2ba255888541bd0111cf00b9b16586, <=*, 6.6.148, 7.2, <6.1

Description

In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)

Gravité et risque d'exploitation

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

Que faire ?

  • Vérifiez si Linux (versions <=6.1.*, <=6.12.*, <81ea8e8221853950c47dac7164f27c63a96f8f86, 6.12.101, <97a688563be71ec6fefc071aff69a66c69dbe244, 0, <=7.1.*, <bc2d630296e0e049210ec05ff08459a6893ae749, <6fe4e4b8259e1330945b5f3c9476e08473b8e0e8, <=6.6.*, 6.18.42, <4462ac3d90e897dda52ce4b6af2d526ddae835a8, 7.1.6, 6.1.183, <=6.18.*, <bab016bb80d74a9d1f7d4121a7fc1cb529b470e0, 6.1, 22e9947a4b2ba255888541bd0111cf00b9b16586, <=*, 6.6.148, 7.2, <6.1) 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