lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250420042412.GQ2023217@ZenIV>
Date: Sun, 20 Apr 2025 05:24:12 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Christian Brauner <brauner@...nel.org>
Cc: Ian Kent <raven@...maw.net>, Mark Brown <broonie@...nel.org>,
	Eric Chanudet <echanude@...hat.com>, Jan Kara <jack@...e.cz>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Clark Williams <clrkwllms@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>, Ian Kent <ikent@...hat.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-rt-devel@...ts.linux.dev,
	Alexander Larsson <alexl@...hat.com>,
	Lucas Karpinski <lkarpins@...hat.com>, Aishwarya.TCV@....com
Subject: Re: [PATCH v4] fs/namespace: defer RCU sync for MNT_DETACH umount

On Thu, Apr 17, 2025 at 05:12:26PM +0200, Christian Brauner wrote:

> (2) If a userspace task is dealing with e.g., a broken NFS server and
>     does a umount(MNT_DETACH) and that NFS server blocks indefinitely
>     then right now it will be the task's problem that called the umount.
>     It will simply hang and pay the price.
> 
>     With your patch however, that cleanup_mnt() and the
>     deactivate_super() call it entails will be done from
>     delayed_mntput_work...
> 
>     So if there's some userspace process with a broken NFS server and it
>     does umount(MNT_DETACH) it will end up hanging every other
>     umount(MNT_DETACH) on the system because the dealyed_mntput_work
>     workqueue (to my understanding) cannot make progress.
> 
>     So in essence this patch to me seems like handing a DOS vector for
>     MNT_DETACH to userspace.

(3) Somebody does umount -l and a few minutes later proceeds to reboot.
All filesystems involved are pinned only by mounts, but the very first
victim happens to be an NFS mount from a slow server.  No indication
of the problem, just a bunch of local filesystems that got a dirty shutdown...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ