linux-stable.git/fs/notify, branch master

fsnotify: Fix stale object mask after concurrent mark updates

2026-08-05T09:50:45+00:00

When a mark gets a new event bit, fanotify and inotify may avoid
recalculating the object mask if the cached aggregate already contains that
bit. This is racy with a recalculation triggered by a concurrent update to
another mark on the same connector.

The concurrent scan can read the mark before the new bit is added, while
the updater reads the old aggregate before that scan publishes its result.
The updater then skips recalculation and the scan publishes a mask without
the bit, leaving the object mask stale after both updates complete.

This can be reproduced with two fanotify groups watching the same inode:
one thread removes FAN_MODIFY from one existing mark while another thread
adds FAN_MODIFY to the other mark. After both fanotify_mark() calls return,
writes can fail to produce FAN_MODIFY for the group whose mark now contains
the bit. This was reproduced on an unmodified v6.12.95 kernel. The
equivalent inotify interleaving loses IN_MODIFY events.

For normal fanotify additions, recalculate whenever the raw mark mask
changes. The normal mask is not cleared asynchronously, so an unchanged
addition cannot introduce missing interest. Always recalculate ignore-mask
updates because FS_MODIFY handling may clear the ignore mask without taking
mark->lock, making snapshot comparisons unreliable.

Always recalculate after updating an existing inotify watch. Its replace
path temporarily sets mark->mask to zero, so a concurrent scan can observe
zero even when the old and final masks are equal. Assigning the replacement
mask directly would avoid the transient zero, but existing-watch updates
are infrequent, so unconditional recalculation is simpler.

Link: https://lore.kernel.org/all/CACwKKmCZdiZDoFuYm6LZhQ=XvHPk0fNKH=X3LmoXMqakYqJaNw@mail.gmail.com/
Fixes: 63c882a05416 ("inotify: reimplement inotify using fsnotify")
Fixes: 912ee3946c5e ("fanotify: do not call fanotify_update_object_mask in fanotify_add_mark")
Cc: stable@vger.kernel.org # needs adjustments for <= 7.0
Suggested-by: Jan Kara 
Suggested-by: Amir Goldstein 
Signed-off-by: Youngjae Kwon 
Link: https://patch.msgid.link/20260802015801.2426818-1-yjkwon0026@snu.ac.kr
Signed-off-by: Jan Kara

fanotify: report full event length for FIONREAD

2026-07-31T12:18:17+00:00

fanotify_ioctl(FIONREAD) reports the number of bytes available to read
from the event queue.  It currently accounts only FAN_EVENT_METADATA_LEN
for each queued event.

That underestimates events that carry additional information records, such
as FAN_REPORT_DFID_NAME events.  A userspace program that uses FIONREAD to
size its read buffer can receive a length that is smaller than the next
event.  Reading with that buffer then fails with -EINVAL, while a larger
buffer succeeds and reports a larger metadata.event_len.

Use fanotify_event_len() when summing queued events so FIONREAD includes
all info records.

Fixes: 5e469c830fdb ("fanotify: copy event fid info to user")
Signed-off-by: Yichong Chen 
Link: https://patch.msgid.link/20260731021827.602479-1-chenyichong@uniontech.com
Signed-off-by: Jan Kara

fanotify: fix use-after-free of file range info

2026-07-31T11:34:22+00:00

fsnotify_pre_content() builds its file_range on the triggering task's
stack. fanotify_alloc_perm_event() saves a pointer to range.pos in the
heap-allocated permission event so copy_range_info_to_user() can report
the offset later.

The event reader can set the event state to FAN_EVENT_REPORTED and then
sleep while preparing the file descriptor. If a signal interrupts the
triggering task at that point, fanotify_get_response() changes the state
to FAN_EVENT_CANCELED and returns. This unwinds the file_range stack
frame while the reader still owns the event. The reader then dereferences
pevent->ppos and copies the stale stack value to userspace.

KASAN reported:

  BUG: KASAN: use-after-free in fanotify_read+0x293e/0x2970
  Read of size 8 at addr ffff88811434fc50 by task fanotify_inotif/95
  Call Trace:
   fanotify_read+0x293e/0x2970
   vfs_read+0x177/0xa20
   ksys_read+0xf7/0x1c0
   do_syscall_64+0xf9/0x540
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

Store the range position directly in the permission event and use
FANOTIFY_NO_RANGE when range information is unavailable. The event remains
alive until the reader finishes, so the reported offset no longer depends
on the triggering task's stack.

Fixes: 870499bc1d4d ("fanotify: report file range info with pre-content events")
Cc: stable@vger.kernel.org
Suggested-by: Jan Kara 
Signed-off-by: Chengfeng Ye 
Link: https://patch.msgid.link/20260730134316.2085087-1-nicoyip.dev@gmail.com
Signed-off-by: Jan Kara

fanotify: stop permission watchdog when timeout is zero

2026-07-30T09:54:53+00:00

The fanotify permission watchdog can be disabled by writing zero to
fs/fanotify/watchdog_timeout.  fanotify_perm_watchdog_group_add() already
checks for a zero timeout before scheduling the watchdog.

However, once the watchdog work has been scheduled, perm_group_watchdog()
unconditionally schedules itself again with the current timeout.  If the
sysctl is changed to zero while the work is active, secs_to_jiffies(0)
causes the work to be rescheduled immediately, resulting in a kworker
busy loop.

Read the timeout once in perm_group_watchdog_schedule() and do not
schedule the work when it is zero.  This lets a running watchdog stop
after the next execution when the sysctl is set to zero.

Fixes: b8cf8fda522d ("fanotify: add watchdog for permission events")
Signed-off-by: Yichong Chen 
Link: https://patch.msgid.link/20260730070648.549458-1-chenyichong@uniontech.com
Signed-off-by: Jan Kara

fanotify: initialize permission event watchdog state

2026-07-03T15:11:30+00:00

fanotify permission events are allocated with kmem_cache_alloc(), but
fanotify_alloc_perm_event() does not initialize watchdog_cnt.

The watchdog reads watchdog_cnt after the event is moved to access_list.
A stale value can make it warn too early or skip the warning.

Initialize watchdog_cnt when allocating a permission event.

Fixes: b8cf8fda522d ("fanotify: add watchdog for permission events")
Signed-off-by: Xuanqiang Luo 
Link: https://patch.msgid.link/20260703031345.9354-1-xuanqiang.luo@linux.dev
Signed-off-by: Jan Kara

Merge tag 'fsnotify_for_v7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs

2026-06-16T06:26:43+00:00

Pull fsnotify updates from Jan Kara:

 - fanotify improvements for pidfd reporting

 - small cleanup in fanotify_error_event_equal

* tag 'fsnotify_for_v7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  fanotify: allow reporting pidfds for reaped tasks
  fanotify: report thread pidfds for FAN_REPORT_TID
  fanotify: simplify fanotify_error_event_equal

Merge tag 'vfs-7.2-rc1.directory.delegations' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

2026-06-14T21:20:44+00:00

Pull vfs directory delegations from Christian Brauner:
 "This contains the VFS prerequisites for supporting directory
  delegations in nfsd via CB_NOTIFY callbacks.

  The filelock core gains support for ignoring delegation breaks for
  directory change events together with an inode_lease_ignore_mask()
  helper, and fsnotify gains fsnotify_modify_mark_mask() and a
  FSNOTIFY_EVENT_RENAME data type.

  With this in place nfsd can request delegations on directories and set
  up inotify watches to trigger sending CB_NOTIFY events to clients
  instead of having every directory change break the delegation.

  New tracepoints are added to fsnotify() and to the start of
  break_lease(), and trace_break_lease_block() is passed the currently
  blocking lease instead of the new one.

  A follow-up fix moves the LEASE_BREAK_* flags out of
  #ifdef CONFIG_FILE_LOCKING to fix the build for CONFIG_FILE_LOCKING=n
  configurations"

* tag 'vfs-7.2-rc1.directory.delegations' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
  filelock: move LEASE_BREAK_* flags out of #ifdef CONFIG_FILE_LOCKING
  fsnotify: add FSNOTIFY_EVENT_RENAME data type
  fsnotify: add fsnotify_modify_mark_mask()
  fsnotify: new tracepoint in fsnotify()
  filelock: add an inode_lease_ignore_mask helper
  filelock: add a tracepoint to start of break_lease()
  filelock: add support for ignoring deleg breaks for dir change events
  filelock: pass current blocking lease to trace_break_lease_block() rather than "new_fl"

fanotify: allow reporting pidfds for reaped tasks

2026-06-10T09:08:23+00:00

Fanotify used to refuse to report pidfds for reaped tasks by applying a
pid_has_task() check before calling pidfd_prepare(). This prevented
userspace from obtaining information about the task.

Register the event pid with pidfs when creating the fanotify event if
pidfd reporting was requested, so pidfd_prepare() can later create a
pidfd for the reaped task.

Suggested-by: Christian Brauner 
Link: https://lore.kernel.org/linux-fsdevel/20260528-schmuckvoll-heilen-garen-be77b4208671@brauner/
Signed-off-by: AnonymeMeow 
Signed-off-by: Christian Brauner (Amutable) 
Link: https://patch.msgid.link/20260607003343.425939-3-anonymemeow@gmail.com
Signed-off-by: Jan Kara

fanotify: report thread pidfds for FAN_REPORT_TID

2026-06-10T09:07:47+00:00

The FAN_REPORT_PIDFD and FAN_REPORT_TID flags used to be mutually
exclusive because by the time the pidfd support was introduced to
fanotify, pidfds could only be created for thread group leaders. Now
that the pidfd API supports thread-specific pidfds via PIDFD_THREAD,
this restriction can be lifted.

Reviewed-by: Amir Goldstein 
Signed-off-by: AnonymeMeow 
Link: https://patch.msgid.link/20260607003343.425939-2-anonymemeow@gmail.com
Signed-off-by: Jan Kara

fanotify: simplify fanotify_error_event_equal

2026-05-28T13:08:16+00:00

Return the result of calling fanotify_fsid_equal() directly to simplify
the code.

Signed-off-by: Thorsten Blum 
Link: https://patch.msgid.link/20260527142233.1256340-3-thorsten.blum@linux.dev
Signed-off-by: Jan Kara