]> git.baikalelectronics.ru Git - kernel.git/commit
__follow_mount_rcu(): verify that mount_lock remains unchanged
authorAl Viro <viro@zeniv.linux.org.uk>
Mon, 4 Jul 2022 21:26:29 +0000 (17:26 -0400)
committerAl Viro <viro@zeniv.linux.org.uk>
Tue, 5 Jul 2022 20:14:14 +0000 (16:14 -0400)
commitbcbb7f77b7e083544c7fca95551a4c6c36d7a47d
tree2e2b659ebe352056d1d9d80a31c5797d9f739aff
parent71374b58ebc7666369d670c06d1176f81c437c59
__follow_mount_rcu(): verify that mount_lock remains unchanged

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: e38dd2e5c293 "vfs: add cross-rename"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
fs/namei.c