Skip to content
VulniPulse
High7.0Red Hat Linux

High [CVE-2026-68147] Avoid dynamic allocation in fscrypt_get_devices

This high-severity Red Hat Linux advisory covers CVE-2026-68147.

CVE-2026-68147 Published Aug 10, 2026Updated by vendor Aug 10, 2026
Affected products & platforms
Red Hat LinuxUnclassified
Open vendor advisory

Android app · Google Play

Monitor future Red Hat Linux CVEs from your phone.

Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.

Matching phone alertsOptional email delivery

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.

Affected versions

No affected-version range was extracted from the source record. The vendor advisory is authoritative — check it before change work.

Official advisory · medium-confidence parse· fetched 1 hour ago·verify at source

Fixed versions

No fixed release is recorded yet. That does not prove no patch exists — confirm against the vendor advisory.

Official advisory · medium-confidence parse· fetched 1 hour ago·verify at source

Mitigation

The source record does not include mitigation steps. That is not a statement that no fix exists — read the vendor advisory below for the authoritative guidance.

Official advisory · medium-confidence parse· fetched 1 hour ago·verify at source

Discussion(0)

No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.

Sign in to join the discussion.