https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 19:53:19 +0000 https://vulnerability.circl.lu/vuln/cve-2026-68148 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>fscrypt: Add missing superblock check in find_or_insert_direct_key()</p> <p>The legacy &#39;fscrypt_direct_keys&#39; table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It&#39;s just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys).</p> <p>The entries in it (&#39;struct fscrypt_direct_key&#39;) do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted.</p> <p>However, when finding the fscrypt_direct_key for an inode, we weren&#39;t actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later.</p> <p>Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs.</p> <p>Note that this problem doesn&#39;t exist in the v2 policy equivalent (&#34;per-mode keys&#34;), since the data structures there are per super_block.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>fscrypt: Add missing superblock check in find_or_insert_direct_key()</p> <p>The legacy &#39;fscrypt_direct_keys&#39; table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It&#39;s just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys).</p> <p>The entries in it (&#39;struct fscrypt_direct_key&#39;) do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted.</p> <p>However, when finding the fscrypt_direct_key for an inode, we weren&#39;t actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later.</p> <p>Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs.</p> <p>Note that this problem doesn&#39;t exist in the v2 policy equivalent (&#34;per-mode keys&#34;), since the data structures there are per super_block.</p> https://vulnerability.circl.lu/vuln/cve-2026-68148