linux-stable.git/fs/fuse, branch v7.1.4

fuse-uring: remove request-less entries from ent_w_req_queue to fix NULL deref

2026-07-18T14:55:51+00:00

commit 1c57a69be962d459c5e705f5cb4355b841b3461c upstream.

If a copy into the userspace ring buffer fails, a request will be
terminated and fuse_uring_req_end() will set ent->fuse_req to NULL but
it will leave the entry on ent_w_req_queue in FRRS_FUSE_REQ state. This
can lead to a NULL deref if the request expiration logic scans
ent_w_req_queue in the window before the entry is moved off it.

Fix this by taking the entry off ent_w_req_queue and changing its state
from FRRS_FUSE_REQ to FRRS_INVALID before terminating the request.

Fixes: 4fea593e625c ("fuse: optimize over-io-uring request expiration check")
Cc: stable@kernel.org
Signed-off-by: Joanne Koong 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse-uring: make a fuse_req on SQE commit only findable after memcpy

2026-07-18T14:55:51+00:00

commit 1efd3d474fc0ba74dfd984249bca78807d739812 upstream.

Bad userspace might try to trick us and send commit SQEs request
unique / commit-id of requests that are not even send to
fuse-server (io_uring_cmd_done() not called) yet.

fuse_uring_commit_fetch() ends the fuse request when the ring entry
has a wrong state, but that could have caused a use-after-free
with the memcpy operations in fuse_uring_send_in_task().
In order to avoid such races the call of fuse_uring_add_to_pq()
is moved after the copy operations and just before completing
the io-uring request - malicious userspace cannot find the request
anymore until all prepration work in fuse-client/kernel is completed.

This also moves fuse_uring_add_to_pq() a bit up in the code to
avoid a forward declaration. Also not with a preparation commit,
to make it easier to back port to older kernels.

Reported-by: xlabai 
Reported-by: Berkant Koc 
Fixes: c090c8abae4b6b ("fuse: Add io-uring sqe commit and fetch support")
Cc: stable@kernel.org # 6.14
Signed-off-by: Bernd Schubert 
Reviewed-by: Joanne Koong 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse-uring: Avoid queue->stopped races and set/read that value under lock

2026-07-18T14:55:51+00:00

commit b70a3aca16934c196f92abb17b01c1647b9bb63c upstream.

There are several readers of queue->stopped that check the value
under lock, but fuse_uring_commit_fetch() did not and actually
the value was not set under the lock in fuse_uring_abort_end_requests()
either. Especially in fuse_uring_commit_fetch it is important
to check under a lock, because due to races 'struct fuse_req'
might be freed with fuse_request_end, but another thread/cpu
might already do teardown work.

Cc: stable@kernel.org # 6.14
Fixes: 4a9bfb9b6850fec ("fuse: {io-uring} Handle teardown of ring entries")
Reported-by: Berkant Koc 
Reported-by: xlabai 
Signed-off-by: Bernd Schubert 
Reviewed-by: Joanne Koong 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse-uring: Avoid use-after-free in fuse_uring_async_stop_queues

2026-07-18T14:55:51+00:00

commit d351da75066955144515cb2f9aa959f24a04287a upstream.

fuse_uring_async_stop_queues() might run when the last reference
on ring->queue_refs was already dropped.

In order to avoid an early destruction a reference on struct fuse_conn
is now taken before starting fuse_uring_async_stop_queues() and that
reference is only released when that delayed work queue terminates.

Fixes: 4a9bfb9b6850 ("fuse: {io-uring} Handle teardown of ring entries")
Cc: stable@kernel.org # 6.14
Reported-by: Berkant Koc 
Signed-off-by: Bernd Schubert 
Reviewed-by: Joanne Koong 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse-uring: end fuse_req on io-uring cancel task work

2026-07-18T14:55:51+00:00

commit bea4fe98204b6ce7eb8e29f7bf867dd7619b3ddd upstream.

When io_uring delivers task work with tw.cancel set (PF_EXITING,
PF_KTHREAD fallback, or percpu_ref_is_dying on the ring context),
fuse_uring_send_in_task() takes the cancel branch, assigns
-ECANCELED, and falls through to fuse_uring_send(). That path only
flips the entry to FRRS_USERSPACE and completes the io_uring cmd;
it never discharges the ring entry's owning reference to the
fuse_req that fuse_uring_add_req_to_ring_ent() handed it at
dispatch time.

    fuse_uring_send_in_task()
      tw.cancel == true
        err = -ECANCELED
      fuse_uring_send(ent, cmd, err, issue_flags)
        ent->state = FRRS_USERSPACE
        list_move(&ent->list, &queue->ent_in_userspace)
        ent->cmd = NULL
        io_uring_cmd_done(-ECANCELED)
        /* ent->fuse_req still set, req still hashed */

The fuse_req stays linked on fpq->processing[hash] and
fuse_request_end() is never invoked. The originating syscall
thread blocks in D-state in request_wait_answer() until
fuse_abort_conn() runs, which can be the entire connection
lifetime. For FR_BACKGROUND requests fc->num_background is never
decremented either, so repeated cancels inflate the counter until
max_background is hit and all later background ops stall. tw.cancel does
not imply a connection abort (e.g. a single io_uring worker thread exits
while the fuse connection stays up), so this cannot be left for
fuse_abort_conn() to clean up.

Ending the req but still routing the entry through fuse_uring_send()
is not enough: that leaves a req-less entry on ent_in_userspace, and
ent_list_request_expired() dereferences ent->fuse_req unconditionally
on the head of that list, which would then NULL-deref.

Fix the cancel branch to release the entry directly. Remove it from the
queue, complete the io_uring cmd, end the fuse_req, free the entry, and
drop its queue_refs (waking the teardown waiter if it was the last).

Fixes: c2c9af9a0b13 ("fuse: Allow to queue fg requests through io-uring")
Cc: stable@vger.kernel.org
Reviewed-by: Joanne Koong 
Assisted-by: kres (claude-opus-4-7)
Signed-off-by: Chris Mason 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse-uring: fix moving cancelled entry to ent_in_userspace list

2026-07-18T14:55:51+00:00

commit 198f45eeb9f78b2a2d6d8be95e4e43468eb2c6bc upstream.

fuse_uring_cancel() moves entries that are available (these have no reqs
attached) to the ent_in_userspace list. ent_list_request_expired()
checks the first entry on ent_in_userspace and dereferences
ent->fuse_req unconditionally, which will crash on a cancelled entry
that was moved to this list.

Fix this by freeing the entry and dropping queue_refs directly in
fuse_uring_cancel(). This is safe because cancel is the cancel handler
itself - after io_uring_cmd_done(), no more cancels will be dispatched
for this command, and teardown serializes with cancel via queue->lock.

Since cancel now decrements queue_refs, fuse_uring_abort() must no
longer gate fuse_uring_abort_end_requests() on queue_refs > 0, as
cancelled entries may have already dropped queue_refs while requests are
still queued. Remove the gate so abort always flushes requests and stops
queues.

Reported-by: Heechan Kang 
Tested-by: Heechan Kang 
Reviewed-by: Bernd Schubert 
Fixes: 4fea593e625c ("fuse: optimize over-io-uring request expiration check")
Cc: stable@vger.kernel.org
Suggested-by: Jian Huang Li 
Suggested-by: Horst Birthelmer 
Signed-off-by: Joanne Koong 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse-uring: fix data races on ring->ready

2026-07-18T14:55:50+00:00

commit 46725a0056c884cf58a6897f222892807327d82d upstream.

On weakly-ordered architectures, the store to fiq->ops can be
reordered past the store to ring->ready, allowing a CPU that sees
ring->ready == true via fuse_uring_ready() to dispatch requests
through a stale fiq->ops pointer. Upgrade the store to
smp_store_release() and the load in fuse_uring_ready() to
smp_load_acquire() so that the preceding WRITE_ONCE(fiq->ops, ...)
is visible to any CPU that observes ring->ready == true.

Additionally, fuse_uring_do_register() publishes ring->ready with
WRITE_ONCE() but the fast-path check reads it with a plain load.
This is a marked-vs-unmarked access that KCSAN will flag. Wrap it in
READ_ONCE() to mark it without adding unnecessary ordering.

Also wrap the fc->ring load in fuse_uring_ready() in READ_ONCE() to
prevent the compiler from reloading it between the NULL check and the
dereference.

Fixes: c2c9af9a0b13 ("fuse: Allow to queue fg requests through io-uring")
Cc: stable@vger.kernel.org
Reviewed-by: Joanne Koong 
Assisted-by: kres (claude-opus-4-7)
Signed-off-by: Chris Mason 
Reviewed-by: Bernd Schubert 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse-uring: fix EFAULT clobber in fuse_uring_commit

2026-07-18T14:55:50+00:00

commit 3a0a8bc51a13951c5141262bf770eeea3e0b6228 upstream.

copy_from_user() returns the number of bytes not copied as an unsigned
residual on failure (1..sizeof(struct fuse_out_header)). fuse_uring_commit
stores that residual in ssize_t err, sets req->out.h.error to -EFAULT,
then jumps to out: with err still holding the positive residual.

    err = copy_from_user(&req->out.h, &ent->headers->in_out,
                         sizeof(req->out.h));
    if (err) {
        req->out.h.error = -EFAULT;
        goto out;          /* err is the positive residual */
    }
    ...
    out:
        fuse_uring_req_end(ent, req, err);

fuse_uring_req_end() then runs

    if (error)
        req->out.h.error = error;

which overwrites the just-assigned -EFAULT with the positive residual.
FUSE callers such as fuse_simple_request() test err < 0 to detect
failure, so the positive value is interpreted as success and the
caller proceeds with an uninitialised or partial req->out.args.

Fix by assigning err = -EFAULT in the failure branch before jumping
to out, so fuse_uring_req_end() receives a negative errno and sets
req->out.h.error to -EFAULT.

Fixes: c090c8abae4b ("fuse: Add io-uring sqe commit and fetch support")
Cc: stable@vger.kernel.org
Reviewed-by: Joanne Koong 
Assisted-by: kres (claude-opus-4-7)
Signed-off-by: Chris Mason 
Reviewed-by: Bernd Schubert 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse: clear intr_entry in fuse_resend and fuse_remove_pending_req

2026-07-18T14:55:50+00:00

commit f8fce75fedf73ac72aa09163deb8f4291fdcaad2 upstream.

When fuse_resend() moves a request from fpq->processing back to
fiq->pending, it sets FR_PENDING and clears FR_SENT but does not
remove the requests intr_entry from fiq->interrupts.  If the
request had FR_INTERRUPTED set from a prior signal, intr_entry
remains dangling on fiq->interrupts.  When the requesting task
then receives a fatal signal, fuse_remove_pending_req() sees
FR_PENDING=1, removes the request from fiq->pending and frees it
via the refcount path, also without cleaning intr_entry.  The
stale intr_entry causes use-after-free when fuse_read_interrupt()
iterates fiq->interrupts:
  - list_del_init(&req->intr_entry) -> UAF write on freed slab
  - req->in.h.unique -> UAF read, data leaked to userspace

Remove intr_entry from fiq->interrupts in fuse_resend() for
interrupted requests before they are placed back on fiq->pending.

Add a WARN_ON if the intr_entry is not empty on request destruction.

Fixes: 760eac73f9f6 ("fuse: Introduce a new notification type for resend pending requests")
Cc: stable@vger.kernel.org # 6.9
Signed-off-by: Ji'an Zhou 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman

fuse: don't block in fuse_get_dev() for non-sync_init case

2026-07-18T14:55:50+00:00

commit 9f6f44aa5a58aaae0838126dc09460c3e1f56ccb upstream.

Commit a8dd5f1b73bc ("fuse: create fuse_dev on /dev/fuse open instead of
mount") changed behavior so that fuse_get_dev() now unconditionally
blocks waiting for a connection, even in the case where sync_init was
not set. Previously, non-sync_init opens returned -EPERM immediately.

Restore the previous behavior of returning -EPERM.

Fixes: a8dd5f1b73bc ("fuse: create fuse_dev on /dev/fuse open instead of mount")
Reported-by: Mark Brown 
Closes: https://lore.kernel.org/all/3c9f8396-41f4-4c88-b883-34bede72b427@sirena.org.uk/
Cc: 
Signed-off-by: Joanne Koong 
Tested-by: Mark Brown 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman