https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 24 Oct 2026 20:10:13 +0000 https://db.gcve.eu/vuln/cve-2026-98996 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs: don&#39;t silently unmount busy mounts</p> <p>The propagate_mount_busy() helper exists to decide whether a synchronous can suceed. It does that by looking at the copies of the victims in the mounts its parent propagates to. One of those functions from propagation hell.</p> <p>It skips a copy that has child mounts except for the case of a single child mount covering the copy&#39;s root. That algorithm used to be exact. It isn&#39;t anymore.</p> <p>Originally only childless copies were unmounted during propagation. And 1064f874abc0 (&#34;mnt: Tuck mounts under others instead of creating shadow/side mounts.&#34;) ended up adding covered mounts to both sides in one go.</p> <p>Along came 99b19d16471e (&#34;mnt: In propgate_umount handle visiting mounts in any order&#34;) and that started to unmount more than before:</p> <p>[1]: A copy of a mount is unmounted when each of its children is either its overmount or a copy of the victim itself. In the former case the overmount gets reparented. In the latter case the copy of the victim will end up being unmounted.</p> <p>So propagate_umount() ended up being rewritten without adjusting propagate_mount_busy(). And currently propagate_mount_busy() doesn&#39;t look at copies of the victim that have two or more children nor a single child that is not the overmount.</p> <p>So any such copy in [1] is not checked for references. The result is that a synchronous unmount succeeds, pulling out a mount that is still in use.</p> <p>A contain…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs: don&#39;t silently unmount busy mounts</p> <p>The propagate_mount_busy() helper exists to decide whether a synchronous can suceed. It does that by looking at the copies of the victims in the mounts its parent propagates to. One of those functions from propagation hell.</p> <p>It skips a copy that has child mounts except for the case of a single child mount covering the copy&#39;s root. That algorithm used to be exact. It isn&#39;t anymore.</p> <p>Originally only childless copies were unmounted during propagation. And 1064f874abc0 (&#34;mnt: Tuck mounts under others instead of creating shadow/side mounts.&#34;) ended up adding covered mounts to both sides in one go.</p> <p>Along came 99b19d16471e (&#34;mnt: In propgate_umount handle visiting mounts in any order&#34;) and that started to unmount more than before:</p> <p>[1]: A copy of a mount is unmounted when each of its children is either its overmount or a copy of the victim itself. In the former case the overmount gets reparented. In the latter case the copy of the victim will end up being unmounted.</p> <p>So propagate_umount() ended up being rewritten without adjusting propagate_mount_busy(). And currently propagate_mount_busy() doesn&#39;t look at copies of the victim that have two or more children nor a single child that is not the overmount.</p> <p>So any such copy in [1] is not checked for references. The result is that a synchronous unmount succeeds, pulling out a mount that is still in use.</p> <p>A contain…</p> https://db.gcve.eu/vuln/cve-2026-98996