FKIE_CVE-2026-68147
Vulnerability from fkie_nvd - Published: 2026-08-10 13:20 - Updated: 2026-08-19 17:20
Severity
Summary
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.)
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"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": "bab016bb80d74a9d1f7d4121a7fc1cb529b470e0",
"status": "affected",
"version": "22e9947a4b2ba255888541bd0111cf00b9b16586",
"versionType": "git"
},
{
"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.1.*",
"status": "unaffected",
"version": "6.1.183",
"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",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"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\u0027s 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\u0027s invoked for inode eviction under direct reclaim.\n\n- fscrypt_destroy_inline_crypt_key() doesn\u0027t 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\u0027s 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\u0027t scale up to large number of block\ndevices. For that we\u0027d 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\u0027t be needed.)"
}
],
"id": "CVE-2026-68147",
"lastModified": "2026-08-19T17:20:31.923",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
}
]
},
"published": "2026-08-10T13:20:00.597",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4462ac3d90e897dda52ce4b6af2d526ddae835a8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6fe4e4b8259e1330945b5f3c9476e08473b8e0e8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/81ea8e8221853950c47dac7164f27c63a96f8f86"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/97a688563be71ec6fefc071aff69a66c69dbe244"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/bab016bb80d74a9d1f7d4121a7fc1cb529b470e0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/bc2d630296e0e049210ec05ff08459a6893ae749"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…