https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 12:39:45 +0000 https://vulnerability.circl.lu/vuln/cve-2025-22072 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>spufs: fix gang directory lifetimes</p> <p>prior to &#34;[POWERPC] spufs: Fix gang destroy leaks&#34; we used to have a problem with gang lifetimes - creation of a gang returns opened gang directory, which normally gets removed when that gets closed, but if somebody has created a context belonging to that gang and kept it alive until the gang got closed, removal failed and we ended up with a leak.</p> <p>Unfortunately, it had been fixed the wrong way. Dentry of gang directory was no longer pinned, and rmdir on close was gone. One problem was that failure of open kept calling simple_rmdir() as cleanup, which meant an unbalanced dput(). Another bug was in the success case - gang creation incremented link count on root directory, but that was no longer undone when gang got destroyed.</p> <p>Fix consists of * reverting the commit in question * adding a counter to gang, protected by -&gt;i_rwsem of gang directory inode. * having it set to 1 at creation time, dropped in both spufs_dir_close() and spufs_gang_close() and bumped in spufs_create_context(), provided that it&#39;s not 0. * using simple_recursive_removal() to take the gang directory out when counter reaches zero.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>spufs: fix gang directory lifetimes</p> <p>prior to &#34;[POWERPC] spufs: Fix gang destroy leaks&#34; we used to have a problem with gang lifetimes - creation of a gang returns opened gang directory, which normally gets removed when that gets closed, but if somebody has created a context belonging to that gang and kept it alive until the gang got closed, removal failed and we ended up with a leak.</p> <p>Unfortunately, it had been fixed the wrong way. Dentry of gang directory was no longer pinned, and rmdir on close was gone. One problem was that failure of open kept calling simple_rmdir() as cleanup, which meant an unbalanced dput(). Another bug was in the success case - gang creation incremented link count on root directory, but that was no longer undone when gang got destroyed.</p> <p>Fix consists of * reverting the commit in question * adding a counter to gang, protected by -&gt;i_rwsem of gang directory inode. * having it set to 1 at creation time, dropped in both spufs_dir_close() and spufs_gang_close() and bumped in spufs_create_context(), provided that it&#39;s not 0. * using simple_recursive_removal() to take the gang directory out when counter reaches zero.</p> https://vulnerability.circl.lu/vuln/cve-2025-22072