Al Viro 6fc0b164bb __follow_mount_rcu(): verify that mount_lock remains unchanged
commit 20aac6c60981f5bfacd66661d090d907bf1482f0 upstream.

Validate mount_lock seqcount as soon as we cross into mount in RCU
mode.  Sure, ->mnt_root is pinned and will remain so until we
do rcu_read_unlock() anyway, and we will eventually fail to unlazy if
the mount_lock had been touched, but we might run into a hard error
(e.g. -ENOENT) before trying to unlazy.  And it's possible to end
up with RCU pathwalk racing with rename() and umount() in a way
that would fail with -ENOENT while non-RCU pathwalk would've
succeeded with any timings.

Once upon a time we hadn't needed that, but analysis had been subtle,
brittle and went out of window as soon as RENAME_EXCHANGE had been
added.

It's narrow, hard to hit and won't get you anything other than
stray -ENOENT that could be arranged in much easier way with the
same priveleges, but it's a bug all the same.

Cc: stable@kernel.org
X-sky-is-falling: unlikely
Fixes: da1ce0670c14 "vfs: add cross-rename"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-17 15:16:06 +02:00
..
2022-06-17 06:03:30 +09:00
2022-05-09 16:21:44 -04:00
2022-05-09 16:21:45 -04:00
2022-05-09 16:21:45 -04:00
2022-05-02 11:23:49 -05:00
2022-06-03 10:34:34 -07:00
2022-05-24 19:55:07 -07:00
2022-05-09 16:21:45 -04:00
2022-05-24 19:55:07 -07:00
2022-06-03 16:57:16 -07:00
2022-05-09 23:12:53 -04:00
2022-05-09 16:21:46 -04:00
2022-05-23 20:24:12 -05:00
2022-05-24 19:55:07 -07:00
2022-05-24 19:55:07 -07:00
2022-05-24 19:55:07 -07:00
2022-03-28 17:29:53 -07:00
2022-05-27 15:49:30 -07:00
2022-05-09 18:20:49 -07:00
2022-06-04 18:52:00 -07:00
2022-04-01 19:35:56 -07:00
2022-08-17 15:14:20 +02:00
2022-04-19 10:19:02 -07:00
2022-05-22 21:03:01 +01:00
2022-04-17 19:49:59 -06:00