{"id":"CVE-2026-68147","aliases":[],"url":"https://o3.security/vulnerability/CVE-2026-68147","summary":"fscrypt: Avoid dynamic allocation in fscrypt_get_devices()","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nfscrypt: Avoid dynamic allocation in fscrypt_get_devices()\n\nWhen a blk_crypto_key starts being used or is evicted, fs/crypto/ calls\nfscrypt_get_devices() to get the filesystem's list of block devices,\nthen iterates over them and calls blk_crypto_config_supported(),\nblk_crypto_start_using_key(), or blk_crypto_evict_key() on each one.\n\nCurrently, the block device pointers are placed in a dynamically\nallocated array.  This dynamic allocation is problematic because:\n\n- It can fail, especially at the fscrypt_destroy_inline_crypt_key() call\n  site when it's invoked for inode eviction under direct reclaim.\n\n- fscrypt_destroy_inline_crypt_key() doesn't handle the failure.  It\n  just zeroizes and frees the blk_crypto_key without calling\n  blk_crypto_evict_key().  That causes a use-after-free.\n\nFor now, let's fix this in the straightforward and easily-backportable\nway by switching to an on-stack array.  Currently the fscrypt\nmulti-device functionality is used only by f2fs, which has a hardcoded\nlimit of 8 block devices.  An on-stack array works fine for that.\n\n(Of course, this solution won't scale up to large number of block\ndevices.  For that we'd need a different solution, like moving the block\ndevice iteration into the filesystem.  Or in the case of btrfs, which\nwill only support blk-crypto-fallback, we should make it just call\nblk-crypto-fallback directly, so the block devices won't be needed.)","published":"2026-08-10T11:59:12.308Z","modified":"2026-08-14T04:03:27.083895667Z","cvss":{"score":7.8,"severity":"HIGH","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"},"epss":null,"cisaKev":null,"exploitsKnown":null,"affectedPackages":[{"ecosystem":"Linux","name":"Kernel","fixedVersion":"6.6.148"}],"fix":null,"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/4462ac3d90e897dda52ce4b6af2d526ddae835a8"},{"type":"WEB","url":"https://git.kernel.org/stable/c/6fe4e4b8259e1330945b5f3c9476e08473b8e0e8"},{"type":"WEB","url":"https://git.kernel.org/stable/c/81ea8e8221853950c47dac7164f27c63a96f8f86"},{"type":"WEB","url":"https://git.kernel.org/stable/c/97a688563be71ec6fefc071aff69a66c69dbe244"},{"type":"WEB","url":"https://git.kernel.org/stable/c/bc2d630296e0e049210ec05ff08459a6893ae749"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/68xxx/CVE-2026-68147.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68147"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-08-14T04:03:27.083895667Z"}}