https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 07:27:13 +0000 https://vulnerability.circl.lu/vuln/cve-2026-74359 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>configfs_lookup(): don&#39;t leave -&gt;s_dentry dangling on failure</p> <p>Normally -&gt;s_dentry is cleared when dentry it&#39;s pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so -&gt;d_iput() is not called at all.</p> <p>We do part of what normally would&#39;ve been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear -&gt;s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it.</p> <p>However, for configfs_lookup() it *does* survive, with a dangling pointer to soon to be freed dentry sitting it its -&gt;s_dentry.</p> <p>Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free...</p> <p>This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>configfs_lookup(): don&#39;t leave -&gt;s_dentry dangling on failure</p> <p>Normally -&gt;s_dentry is cleared when dentry it&#39;s pointing to becomes negative (on eviction, realistically). However, that only happens if dentry gets to be positive in the first place; in case of inode allocation failure dentry never becomes positive, so -&gt;d_iput() is not called at all.</p> <p>We do part of what normally would&#39;ve been done by configfs_d_iput() (dropping the reference to configfs_dirent) manually, but we do not clear -&gt;s_dentry there. Sloppy as it is, it does not matter in case of configfs_create_{dir,link}() - there configfs_dirent does not survive dropping the sole reference to it.</p> <p>However, for configfs_lookup() it *does* survive, with a dangling pointer to soon to be freed dentry sitting it its -&gt;s_dentry.</p> <p>Subsequent getdents(2) in that directory will end up dereferencing that pointer in order to pick the inode number. Use after free...</p> <p>This is the minimal fix; the right approach is to set the linkage between dentry and configfs_dirent only after we know that we have an inode, but that takes more surgery and the bug had been there since 2006, so...</p> https://vulnerability.circl.lu/vuln/cve-2026-74359