This CVE exposes a resource management failure in the Linux kernel's fscrypt subsystem that is more subtle than a typical use-after-free. When fscrypt_destroy_inline_crypt_key() is called during direct reclaim and the key eviction path attempts memory allocation, the code silently abandons the blk_crypto_evict_key() call rather than handling the failure. This leaves a dangling reference in the crypto subsystem — the subsequent use-after-free is not a separate bug but the direct consequence of incomplete error handling at the precise moment the system can least afford it.
The on-stack array fix (capping fscrypt_get_devices() at 8 devices) eliminates the allocatable condition entirely. This is the correct short-term fix but creates a harder problem: it makes the error path unreachable by construction. Future developers extending multi-device support beyond 8 devices will convert back to dynamic allocation and encounter an error handling code path that has never been written, tested, or audited. The proper architectural fix — moving iteration into filesystems or calling blk-crypto-fallback directly — was explicitly deferred for backportability.
For defenders: prioritize this patch in your kernel update cycle. Audit your fscrypt and blk-crypto configurations for non-standard device counts approaching the 8-device boundary. More importantly, treat this as a pattern detector: scan your codebase for similar on-stack conversions that eliminated failure conditions rather than handling them, particularly in code paths reachable from direct reclaim or memory-pressure contexts. The systemic risk is not this one CVE — it's the growing inventory of unreachable error paths that will surface when architectural constraints inevitably change.