{"id":"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.)","modified":"2026-08-21T03:30:44.208297838Z","published":"2026-08-10T11:59:12.308Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/68xxx/CVE-2026-68147.json"},"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/bab016bb80d74a9d1f7d4121a7fc1cb529b470e0"},{"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"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"22e9947a4b2ba255888541bd0111cf00b9b16586"},{"fixed":"bab016bb80d74a9d1f7d4121a7fc1cb529b470e0"},{"fixed":"4462ac3d90e897dda52ce4b6af2d526ddae835a8"},{"fixed":"97a688563be71ec6fefc071aff69a66c69dbe244"},{"fixed":"81ea8e8221853950c47dac7164f27c63a96f8f86"},{"fixed":"bc2d630296e0e049210ec05ff08459a6893ae749"},{"fixed":"6fe4e4b8259e1330945b5f3c9476e08473b8e0e8"}]}],"database_specific":{"source":"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-68147.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"6.1.0"},{"fixed":"6.1.183"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.2.0"},{"fixed":"6.6.148"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.7.0"},{"fixed":"6.12.101"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.42"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.1.6"}]}],"database_specific":{"source":"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-68147.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"}]}