CVE-2026-68148

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscrypt: Add missing superblock check in find_or_insert_direct_key()<br /> <br /> The legacy &amp;#39;fscrypt_direct_keys&amp;#39; table caches master keys that are used<br /> by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY.<br /> It&amp;#39;s just a global table for all filesystems (since the keys can be<br /> provided by the legacy process-subscribed keyrings mechanism, which<br /> makes it difficult to reuse super_block::s_master_keys).<br /> <br /> The entries in it (&amp;#39;struct fscrypt_direct_key&amp;#39;) do contain a super_block<br /> pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when<br /> the last inode that references the key is evicted.<br /> <br /> However, when finding the fscrypt_direct_key for an inode, we weren&amp;#39;t<br /> actually comparing the super_block pointer. As a result, inodes with<br /> different super_blocks could point to the same fscrypt_direct_key. That<br /> could extend the lifetime of a fscrypt_direct_key beyond the<br /> super_block it points to, causing a use-after-free later.<br /> <br /> Fix this by creating distinct fscrypt_direct_key structs for distinct<br /> super_block structs.<br /> <br /> Note that this problem doesn&amp;#39;t exist in the v2 policy equivalent<br /> ("per-mode keys"), since the data structures there are per super_block.