{"api_version":"1","generated_at":"2026-08-12T22:06:55+00:00","cve":"CVE-2026-68147","urls":{"html":"https://cve.report/CVE-2026-68147","api":"https://cve.report/api/cve/CVE-2026-68147.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-68147","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-68147"},"summary":{"title":"fscrypt: Avoid dynamic allocation in fscrypt_get_devices()","description":"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.)","state":"PUBLISHED","assigner":"Linux","published_at":"2026-08-10 13:20:00","updated_at":"2026-08-10 13:20:00"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/4462ac3d90e897dda52ce4b6af2d526ddae835a8","name":"https://git.kernel.org/stable/c/4462ac3d90e897dda52ce4b6af2d526ddae835a8","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/81ea8e8221853950c47dac7164f27c63a96f8f86","name":"https://git.kernel.org/stable/c/81ea8e8221853950c47dac7164f27c63a96f8f86","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/6fe4e4b8259e1330945b5f3c9476e08473b8e0e8","name":"https://git.kernel.org/stable/c/6fe4e4b8259e1330945b5f3c9476e08473b8e0e8","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/97a688563be71ec6fefc071aff69a66c69dbe244","name":"https://git.kernel.org/stable/c/97a688563be71ec6fefc071aff69a66c69dbe244","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/bc2d630296e0e049210ec05ff08459a6893ae749","name":"https://git.kernel.org/stable/c/bc2d630296e0e049210ec05ff08459a6893ae749","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-68147","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-68147","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 22e9947a4b2ba255888541bd0111cf00b9b16586 4462ac3d90e897dda52ce4b6af2d526ddae835a8 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 22e9947a4b2ba255888541bd0111cf00b9b16586 97a688563be71ec6fefc071aff69a66c69dbe244 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 22e9947a4b2ba255888541bd0111cf00b9b16586 81ea8e8221853950c47dac7164f27c63a96f8f86 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 22e9947a4b2ba255888541bd0111cf00b9b16586 bc2d630296e0e049210ec05ff08459a6893ae749 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 22e9947a4b2ba255888541bd0111cf00b9b16586 6fe4e4b8259e1330945b5f3c9476e08473b8e0e8 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.1","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.1 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6.148 6.6.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.101 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.42 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.1.6 7.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2-rc5 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["fs/crypto/inline_crypt.c","fs/f2fs/super.c","include/linux/fscrypt.h"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"4462ac3d90e897dda52ce4b6af2d526ddae835a8","status":"affected","version":"22e9947a4b2ba255888541bd0111cf00b9b16586","versionType":"git"},{"lessThan":"97a688563be71ec6fefc071aff69a66c69dbe244","status":"affected","version":"22e9947a4b2ba255888541bd0111cf00b9b16586","versionType":"git"},{"lessThan":"81ea8e8221853950c47dac7164f27c63a96f8f86","status":"affected","version":"22e9947a4b2ba255888541bd0111cf00b9b16586","versionType":"git"},{"lessThan":"bc2d630296e0e049210ec05ff08459a6893ae749","status":"affected","version":"22e9947a4b2ba255888541bd0111cf00b9b16586","versionType":"git"},{"lessThan":"6fe4e4b8259e1330945b5f3c9476e08473b8e0e8","status":"affected","version":"22e9947a4b2ba255888541bd0111cf00b9b16586","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["fs/crypto/inline_crypt.c","fs/f2fs/super.c","include/linux/fscrypt.h"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.1"},{"lessThan":"6.1","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.6.*","status":"unaffected","version":"6.6.148","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.101","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.42","versionType":"semver"},{"lessThanOrEqual":"7.1.*","status":"unaffected","version":"7.1.6","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.2-rc5","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.6.148","versionStartIncluding":"6.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.101","versionStartIncluding":"6.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.42","versionStartIncluding":"6.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.1.6","versionStartIncluding":"6.1","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2-rc5","versionStartIncluding":"6.1","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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.)"}],"providerMetadata":{"dateUpdated":"2026-08-10T11:59:12.308Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/4462ac3d90e897dda52ce4b6af2d526ddae835a8"},{"url":"https://git.kernel.org/stable/c/97a688563be71ec6fefc071aff69a66c69dbe244"},{"url":"https://git.kernel.org/stable/c/81ea8e8221853950c47dac7164f27c63a96f8f86"},{"url":"https://git.kernel.org/stable/c/bc2d630296e0e049210ec05ff08459a6893ae749"},{"url":"https://git.kernel.org/stable/c/6fe4e4b8259e1330945b5f3c9476e08473b8e0e8"}],"title":"fscrypt: Avoid dynamic allocation in fscrypt_get_devices()","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-68147","datePublished":"2026-08-10T11:59:12.308Z","dateReserved":"2026-07-30T09:28:09.371Z","dateUpdated":"2026-08-10T11:59:12.308Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-08-10 13:20:00","lastModifiedDate":"2026-08-10 13:20:00","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"68147","Ordinal":"1","Title":"fscrypt: Avoid dynamic allocation in fscrypt_get_devices()","CVE":"CVE-2026-68147","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"68147","Ordinal":"1","NoteData":"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.)","Type":"Description","Title":"fscrypt: Avoid dynamic allocation in fscrypt_get_devices()"}]}}}