]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
fsnotify: do not generate ACCESS/MODIFY events on child for special files
authorAmir Goldstein <amir73il@gmail.com>
Sun, 7 Dec 2025 10:44:55 +0000 (11:44 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 2 Jan 2026 11:57:23 +0000 (12:57 +0100)
commit7a93edb23bcf07a3aaf8b598edfc2faa8fbcc0b6
tree9cc9082e75c46cb0ded0a287a032d0487f332eed
parent7b9ea7aa24bd1cafa12aab519c8023048033fafc
fsnotify: do not generate ACCESS/MODIFY events on child for special files

commit 635bc4def026a24e071436f4f356ea08c0eed6ff upstream.

inotify/fanotify do not allow users with no read access to a file to
subscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the
same user to subscribe for watching events on children when the user
has access to the parent directory (e.g. /dev).

Users with no read access to a file but with read access to its parent
directory can still stat the file and see if it was accessed/modified
via atime/mtime change.

The same is not true for special files (e.g. /dev/null). Users will not
generally observe atime/mtime changes when other users read/write to
special files, only when someone sets atime/mtime via utimensat().

Align fsnotify events with this stat behavior and do not generate
ACCESS/MODIFY events to parent watchers on read/write of special files.
The events are still generated to parent watchers on utimensat(). This
closes some side-channels that could be possibly used for information
exfiltration [1].

[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf

Reported-by: Sudheendra Raghav Neela <sneela@tugraz.at>
CC: stable@vger.kernel.org
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/notify/fsnotify.c