<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs, branch v6.18.36</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.36</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.36'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-19T11:44:14+00:00</updated>
<entry>
<title>fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling</title>
<updated>2026-06-19T11:44:14+00:00</updated>
<author>
<name>Mingyu Wang</name>
<email>25181214217@stu.xidian.edu.cn</email>
</author>
<published>2026-05-23T13:52:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=20a93e397abe850c49b6fa0e8cc827b5f634a8f5'/>
<id>urn:sha1:20a93e397abe850c49b6fa0e8cc827b5f634a8f5</id>
<content type='text'>
commit 00633c4683828acd5256fa8d5163f440d74bbe71 upstream.

A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in
send_sigio() and send_sigurg() when a process group receives a signal.

When FASYNC is configured for a process group (PIDTYPE_PGID), both
functions use read_lock(&amp;tasklist_lock) to traverse the task list.
However, they are frequently called from softirq context:
- send_sigio() via input_inject_event -&gt; kill_fasync
- send_sigurg() via tcp_check_urg -&gt; sk_send_sigurg (NET_RX_SOFTIRQ)

The deadlock is caused by the rwlock writer fairness mechanism:
1. CPU 0 (process context) holds read_lock(&amp;tasklist_lock) in do_wait().
2. CPU 1 (process context) attempts write_lock(&amp;tasklist_lock) in
   fork() or exit() and spins, which blocks all new readers.
3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).
4. The softirq calls send_sigurg() and attempts to acquire
   read_lock(&amp;tasklist_lock), deadlocking because CPU 1 is waiting.

Since PID hashing and do_each_pid_task() traversals are already
RCU-protected, the read_lock on tasklist_lock is no longer strictly
required for safe traversal. Fix this by replacing tasklist_lock with
rcu_read_lock(), aligning the process group signaling path with the
single-PID path. This also mitigates a potential remote denial of
service vector via TCP URG packets.

Lockdep splat:
=====================================================
WARNING: SOFTIRQ-safe -&gt; SOFTIRQ-unsafe lock order detected
[...]
Chain exists of:
  &amp;dev-&gt;event_lock --&gt; &amp;f_owner-&gt;lock --&gt; tasklist_lock

Possible interrupt unsafe locking scenario:
       CPU0                    CPU1
       ----                    ----
  lock(tasklist_lock);
                           local_irq_disable();
                           lock(&amp;dev-&gt;event_lock);
                           lock(&amp;f_owner-&gt;lock);
  &lt;Interrupt&gt;
    lock(&amp;dev-&gt;event_lock);

*** DEADLOCK ***

Reviewed-by: Jeff Layton &lt;jlayton@kernel.org&gt;
Signed-off-by: Mingyu Wang &lt;25181214217@stu.xidian.edu.cn&gt;
Link: https://patch.msgid.link/20260523135210.590928-1-w15303746062@163.com
Signed-off-by: Christian Brauner (Amutable) &lt;brauner@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios</title>
<updated>2026-06-19T11:44:07+00:00</updated>
<author>
<name>Jann Horn</name>
<email>jannh@google.com</email>
</author>
<published>2026-05-19T14:40:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=56763afa013444a9d84ca1b74e4b7130942177ba'/>
<id>urn:sha1:56763afa013444a9d84ca1b74e4b7130942177ba</id>
<content type='text'>
commit 4e3d1b2c48ca6c55f1e9ca7f8dccc76f120f276c upstream.

FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios
can contain uninitialized data.
Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already
in the page cache and not wait for data from the FUSE daemon, treat
!uptodate folios as if they weren't present.

This only has security impact on systems that don't enable automatic
zero-initialization of all page allocations via
CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.

Cc: stable@kernel.org
Fixes: 2d45ba381a74 ("fuse: add retrieve request")
Signed-off-by: Jann Horn &lt;jannh@google.com&gt;
Link: https://patch.msgid.link/20260519-fuse-retrieve-uptodate-v1-1-a7a1912a37f9@google.com
Acked-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Christian Brauner (Amutable) &lt;brauner@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>fuse: reject fuse_notify() pagecache ops on directories</title>
<updated>2026-06-19T11:44:07+00:00</updated>
<author>
<name>Jann Horn</name>
<email>jannh@google.com</email>
</author>
<published>2026-05-19T14:29:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=12df4cfa738aefff21756728e91056d7defb0fe6'/>
<id>urn:sha1:12df4cfa738aefff21756728e91056d7defb0fe6</id>
<content type='text'>
commit 9c954499d43aefac01c5dfb57a82b13d2dcf4b94 upstream.

The operations FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE allow the
FUSE daemon to actively write/read pagecache contents.

For directories with FOPEN_CACHE_DIR, the pagecache is used as
kernel-internal cache storage, and userspace is not supposed to have
direct access to this cache - in particular, fuse_parse_cache() will hit
WARN_ON() if the cache contains bogus data.

Reject FUSE_NOTIFY_STORE and FUSE_NOTIFY_RETRIEVE on anything other than
regular files with -EINVAL.

Fixes: 5d7bc7e8680c ("fuse: allow using readdir cache")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn &lt;jannh@google.com&gt;
Link: https://patch.msgid.link/20260519-fuse-dir-pagecache-v2-1-5428fa48e175@google.com
Acked-by: Miklos Szeredi &lt;mszeredi@redhat.com&gt;
Signed-off-by: Christian Brauner (Amutable) &lt;brauner@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>fs/qnx6: fix pointer arithmetic in directory iteration</title>
<updated>2026-06-19T11:44:07+00:00</updated>
<author>
<name>Arpith Kalaginanavoor</name>
<email>arpithk@nvidia.com</email>
</author>
<published>2026-05-26T12:38:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=57a9c085be07f7de76b9866107d8b06a101f06ae'/>
<id>urn:sha1:57a9c085be07f7de76b9866107d8b06a101f06ae</id>
<content type='text'>
commit 89c4a1167f3a0a0efd2ec3e1801036d2eb65ae1a upstream.

The conversion to qnx6_get_folio() in commit b2aa61556fcf
("qnx6: Convert qnx6_get_page() to qnx6_get_folio()")
introduced a regression in directory iteration. The pointer 'de'
and the 'limit' address were calculated using byte offsets from
a char pointer without scaling by the size of a QNX6 directory
entry.

This causes the driver to read from incorrect memory offsets,
leading to "invalid direntry size" errors and premature
termination of directory scans.

Fix this by casting 'kaddr' to 'struct qnx6_dir_entry *' before
applying the offset and last_entry(...) increments. This allows the
compiler to correctly scale the pointer arithmetic by the 32-byte
stride of the directory entry structure.

Fixes: b2aa61556fcf ("qnx6: Convert qnx6_get_page() to qnx6_get_folio()")
Cc: stable@vger.kernel.org
Signed-off-by: Arpith Kalaginanavoor &lt;arpithk@nvidia.com&gt;
Link: https://patch.msgid.link/20260526123858.1683035-1-arpithk@nvidia.com
Signed-off-by: Christian Brauner (Amutable) &lt;brauner@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>fhandle: fix UAF due to unlocked -&gt;mnt_ns read in may_decode_fh()</title>
<updated>2026-06-19T11:44:07+00:00</updated>
<author>
<name>Jann Horn</name>
<email>jannh@google.com</email>
</author>
<published>2026-06-03T19:31:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=32138633e51e6db59e474765cf93268c92b42888'/>
<id>urn:sha1:32138633e51e6db59e474765cf93268c92b42888</id>
<content type='text'>
commit 40ab6644b99685755f740b872c00ef40d9aa870e upstream.

may_decode_fh() accesses mount::mnt_ns without holding any locks; that
means the mount can concurrently be unmounted, and the mnt_namespace can
concurrently be freed after an RCU grace period.

This race can happens as follows, assuming that the mount point was
created by open_tree(..., OPEN_TREE_CLONE):

thread 1            thread 2            RCU
                    __do_sys_open_by_handle_at
                      do_handle_open
                        handle_to_path
                          may_decode_fh
                            is_mounted
                              [mount::mnt_ns access]
                            [mount::mnt_ns access]
__do_sys_close
  fput_close_sync
    __fput
      dissolve_on_fput
        umount_tree
        class_namespace_excl_destructor
          namespace_unlock
            free_mnt_ns
              mnt_ns_tree_remove
                call_rcu(mnt_ns_release_rcu)
                                        mnt_ns_release_rcu
                                          mnt_ns_release
                                            kfree
                            [mnt_namespace::user_ns access] **UAF**

Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like
in __prepend_path().
Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE()
for writers that can race with lockless readers.

This bug is unreachable unless one of the following is set:

 - CONFIG_PREEMPTION
 - CONFIG_RCU_STRICT_GRACE_PERIOD

because it requires an RCU grace period to happen during a syscall without
an explicit preemption.

This doesn't seem to have interesting security impact; worst-case, it could
leak the result of an integer comparison to userspace (from the level
check in cap_capable()), cause an endless loop, or crash the kernel by
dereferencing an invalid address.

Fixes: 620c266f3949 ("fhandle: relax open_by_handle_at() permission checks")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn &lt;jannh@google.com&gt;
Link: https://patch.msgid.link/20260603-vfs-fhandle-uaf-fix-v2-1-d05db76a5084@google.com
Signed-off-by: Christian Brauner (Amutable) &lt;brauner@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xfs: fix rtgroup cleanup in CoW fork repair</title>
<updated>2026-06-19T11:44:06+00:00</updated>
<author>
<name>Yingjie Gao</name>
<email>gaoyingjie@uniontech.com</email>
</author>
<published>2026-05-27T04:31:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fcfdff42e841d246397c3756d4218c66c2b3b263'/>
<id>urn:sha1:fcfdff42e841d246397c3756d4218c66c2b3b263</id>
<content type='text'>
commit c3e073894379532c00cca7ba5762e18fafe29da8 upstream.

xrep_cow_find_bad_rt() initializes scrub rtgroup state before the
force-rebuild path calls xrep_cow_mark_file_range(). If that call
fails, the code jumps directly to out_rtg, which skips the scrub
rtgroup cleanup and only drops the local rtgroup reference.

Remove the unnecessary jump so the function falls through to out_sr,
ensuring the realtime cursors, lock state, and sr-&gt;rtg reference are
released before returning.

Fixes: fd97fe111208 ("xfs: fix CoW forks for realtime files")
Cc: &lt;stable@vger.kernel.org&gt; # v6.14
Signed-off-by: Yingjie Gao &lt;gaoyingjie@uniontech.com&gt;
Reviewed-by: "Darrick J. Wong" &lt;djwong@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xfs: fix error returns in CoW fork repair</title>
<updated>2026-06-19T11:44:06+00:00</updated>
<author>
<name>Yingjie Gao</name>
<email>gaoyingjie@uniontech.com</email>
</author>
<published>2026-05-27T04:31:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d84ed2f9718efcfe7afae4821cefa1bcdccea970'/>
<id>urn:sha1:d84ed2f9718efcfe7afae4821cefa1bcdccea970</id>
<content type='text'>
commit fcf4faba9f986b3bb528da11913c9ec5d6e8f689 upstream.

xrep_cow_find_bad() returns success after the cleanup labels even if
AG setup, btree queries, or bitmap updates failed. This can make
repair continue with an incomplete bad-file-offset bitmap instead of
stopping at the original error.

The force-rebuild path has a related cleanup problem. If
xrep_cow_mark_file_range() fails, the function returns directly and
skips the scrub AG context and perag cleanup.

Let the force-rebuild path fall through to the existing cleanup code
and return the saved error after cleanup.

Fixes: dbbdbd008632 ("xfs: repair problems in CoW forks")
Cc: &lt;stable@vger.kernel.org&gt; # v6.8
Signed-off-by: Yingjie Gao &lt;gaoyingjie@uniontech.com&gt;
Reviewed-by: "Darrick J. Wong" &lt;djwong@kernel.org&gt;
Signed-off-by: Carlos Maiolino &lt;cem@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ksmbd: fix use-after-free of a deferred file_lock on double SMB2_CANCEL</title>
<updated>2026-06-19T11:44:04+00:00</updated>
<author>
<name>Gil Portnoy</name>
<email>dddhkts1@gmail.com</email>
</author>
<published>2026-05-31T23:27:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=14d2eee0193ac3cd1bf3d014373449f0b8d35d6d'/>
<id>urn:sha1:14d2eee0193ac3cd1bf3d014373449f0b8d35d6d</id>
<content type='text'>
commit f580d27e8928828693df44ba2db0fffdbe11dfea upstream.

A deferred byte-range lock (an SMB2_LOCK that blocks) registers an async work on
conn-&gt;async_requests via setup_async_work(), with cancel_fn =
smb2_remove_blocked_lock and cancel_argv[0] pointing at the struct file_lock.

When the request is cancelled, the worker frees the file_lock with
locks_free_lock() and takes the cancelled early-exit, which "goto out"s and never
reaches release_async_work() -- the only site that unlinks the work from
conn-&gt;async_requests and clears cancel_fn/cancel_argv. The work therefore stays
matchable on async_requests with a live cancel_fn pointing at the freed file_lock,
until connection teardown finally runs release_async_work().

smb2_cancel() fires cancel_fn unconditionally with no state guard, so a second
SMB2_CANCEL for the same AsyncId, arriving in that window, re-runs
smb2_remove_blocked_lock() on the freed file_lock -- a slab use-after-free:

  BUG: KASAN: slab-use-after-free in __locks_delete_block
    __locks_delete_block
    locks_delete_block
    ksmbd_vfs_posix_lock_unblock
    smb2_remove_blocked_lock
    smb2_cancel                 &lt;- 2nd SMB2_CANCEL fires cancel_fn
    handle_ksmbd_work
  Allocated by ...: locks_alloc_lock &lt;- smb2_lock
  Freed by ...:     locks_free_lock  &lt;- smb2_lock (cancelled branch)
  ... cache file_lock_cache of size 192

Reproduced on mainline with KASAN by an authenticated SMB client.

Skip a work whose state is already KSMBD_WORK_CANCELLED so its cancel callback
cannot be fired a second time.

Cc: stable@vger.kernel.org
Signed-off-by: Gil Portnoy &lt;dddhkts1@gmail.com&gt;
Acked-by: Namjae Jeon &lt;linkinjeon@kernel.org&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ksmbd: fix NULL-deref of opinfo-&gt;conn in oplock/lease break notifiers</title>
<updated>2026-06-19T11:43:52+00:00</updated>
<author>
<name>Gil Portnoy</name>
<email>dddhkts1@gmail.com</email>
</author>
<published>2026-05-28T00:00:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e735dbd489e3ea02be78dba991056fe1138be51e'/>
<id>urn:sha1:e735dbd489e3ea02be78dba991056fe1138be51e</id>
<content type='text'>
[ Upstream commit b003086d76968298f22e7cf62239833b5a3a06b1 ]

smb2_oplock_break_noti() and smb2_lease_break_noti() read opinfo-&gt;conn
into a local with neither READ_ONCE() nor a NULL check.  Both run from
oplock_break() after opinfo_get_list() has dropped ci-&gt;m_lock, so a
concurrent SMB2 LOGOFF (session_fd_check()) can set op-&gt;conn = NULL
under ci-&gt;m_lock within that window.  ksmbd_conn_r_count_inc(conn) then
writes through NULL at offset 0xc4 -- a remotely triggerable oops.

Guard both reads the way compare_guid_key() already does: read
opinfo-&gt;conn with READ_ONCE() and return early if it is NULL, before
allocating the work struct so nothing leaks.  A NULL conn means the
client is gone and the break is moot, so return 0; oplock_break() treats
that as success and runs the normal teardown.

Fixes: c8efcc786146 ("ksmbd: add support for durable handles v1/v2")
Assisted-by: Henry (Claude):claude-opus-4
Signed-off-by: Gil Portnoy &lt;dddhkts1@gmail.com&gt;
Acked-by: Namjae Jeon &lt;linkinjeon@kernel.org&gt;
Signed-off-by: Steve French &lt;stfrench@microsoft.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>erofs: fix use-after-free on sbi-&gt;sync_decompress</title>
<updated>2026-06-19T11:43:51+00:00</updated>
<author>
<name>Gao Xiang</name>
<email>hsiangkao@linux.alibaba.com</email>
</author>
<published>2026-05-22T08:27:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=00bf6868df65fa95b3854996246d15759fdc7070'/>
<id>urn:sha1:00bf6868df65fa95b3854996246d15759fdc7070</id>
<content type='text'>
[ Upstream commit 1aee05e814d292064bf5fa15733741040cdc48ba ]

z_erofs_decompress_kickoff() can race with filesystem unmount, causing
a use-after-free on sbi-&gt;sync_decompress.

When I/O completes, z_erofs_endio() calls z_erofs_decompress_kickoff()
to queue z_erofs_decompressqueue_work() asynchronously. Then, after all
folios are unlocked, unmount workflow can proceed and sbi will be freed
before accessing to sbi-&gt;sync_decompress.

Thread (unmount)        I/O completion        kworker
                        queue_work
                                              z_erofs_decompressqueue_work
                                               (all folios are unlocked)
cleanup_mnt
 ..
 erofs_kill_sb
  erofs_sb_free
   kfree(sbi)
                        access sbi-&gt;sync_decompress  // UAF!!

Fixes: 40452ffca3c1 ("erofs: add sysfs node to control sync decompression strategy")
Reported-by: syzbot+52bae5c495dbe261a0bc@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=52bae5c495dbe261a0bc
Reviewed-by: Chao Yu &lt;chao@kernel.org&gt;
Reviewed-by: Jianan Huang &lt;jnhuang95@gmail.com&gt;
Signed-off-by: Gao Xiang &lt;hsiangkao@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
