* [PATCH] cuse: wait for pending RCU callbacks on module exit
@ 2026-08-14 13:40 Baokun Li
2026-08-18 7:33 ` Miklos Szeredi
0 siblings, 1 reply; 4+ messages in thread
From: Baokun Li @ 2026-08-14 13:40 UTC (permalink / raw)
To: fuse-devel; +Cc: miklos, linux-fsdevel, linux-kernel, viro, jefflexu
Since commit 053fc4f755ad ("fuse: fix UAF in rcu pathwalks"),
fuse_conn_put() frees the fuse_conn through call_rcu() rather than
synchronously. For cuse, fc->release is cuse_fc_release(), which
lives in the cuse module. If the module is removed before the RCU
grace period ends, the callback jumps into freed module memory:
userspace / module unload | RCU softirq
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
close(/dev/cuse) |
cuse_channel_release() |
fuse_dev_release() |
fuse_conn_put(fch->conn) |
call_rcu(delayed_release) ------+---> callback queued
|
rmmod cuse |
cuse_exit() |
cuse_channel_destroy() |
... |
return |
|
<module text freed> |
| rcu_do_batch()
| delayed_release()
| fc->release()
| -> cuse_fc_release()
| ^^^ freed text!
The freed module text is unmapped by vfree(), so the jump into the
stale callback triggers a page-fault Oops. If the virtual address
is subsequently reused, the callback could execute unrelated code
(undefined behaviour).
Fix this by calling rcu_barrier() in cuse_exit() so that any pending
fuse_conn release callback completes before the module is removed.
Fixes: 053fc4f755ad ("fuse: fix UAF in rcu pathwalks")
Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
---
fs/fuse/cuse.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c
index 3c15b5ba16d7..1c71783ca5a5 100644
--- a/fs/fuse/cuse.c
+++ b/fs/fuse/cuse.c
@@ -653,6 +653,11 @@ static void __exit cuse_exit(void)
{
misc_deregister(&cuse_miscdev);
class_destroy(cuse_class);
+ /*
+ * Wait for pending call_rcu() callbacks that call back into
+ * this module via fc->release (cuse_fc_release).
+ */
+ rcu_barrier();
}
module_init(cuse_init);
--
2.43.7
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] cuse: wait for pending RCU callbacks on module exit
2026-08-14 13:40 [PATCH] cuse: wait for pending RCU callbacks on module exit Baokun Li
@ 2026-08-18 7:33 ` Miklos Szeredi
2026-08-18 7:59 ` Baokun Li
0 siblings, 1 reply; 4+ messages in thread
From: Miklos Szeredi @ 2026-08-18 7:33 UTC (permalink / raw)
To: Baokun Li; +Cc: fuse-devel, linux-fsdevel, linux-kernel, viro, jefflexu
On Fri, 14 Aug 2026 at 15:40, Baokun Li <libaokun@linux.alibaba.com> wrote:
>
> Since commit 053fc4f755ad ("fuse: fix UAF in rcu pathwalks"),
> fuse_conn_put() frees the fuse_conn through call_rcu() rather than
> synchronously. For cuse, fc->release is cuse_fc_release(), which
> lives in the cuse module. If the module is removed before the RCU
> grace period ends, the callback jumps into freed module memory:
free_module() calls synchronize_rcu(), so this should not be an issue.
Thanks,
Miklos
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] cuse: wait for pending RCU callbacks on module exit
2026-08-18 7:33 ` Miklos Szeredi
@ 2026-08-18 7:59 ` Baokun Li
2026-08-18 8:33 ` Miklos Szeredi
0 siblings, 1 reply; 4+ messages in thread
From: Baokun Li @ 2026-08-18 7:59 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: fuse-devel, linux-fsdevel, linux-kernel, viro, jefflexu
Hi Miklos,
On 2026/8/18 15:33, Miklos Szeredi wrote:
> On Fri, 14 Aug 2026 at 15:40, Baokun Li <libaokun@linux.alibaba.com> wrote:
>> Since commit 053fc4f755ad ("fuse: fix UAF in rcu pathwalks"),
>> fuse_conn_put() frees the fuse_conn through call_rcu() rather than
>> synchronously. For cuse, fc->release is cuse_fc_release(), which
>> lives in the cuse module. If the module is removed before the RCU
>> grace period ends, the callback jumps into freed module memory:
> free_module() calls synchronize_rcu(), so this should not be an issue.
synchronize_rcu() only waits for pre-existing RCU read-side critical
sections to complete. It does not wait for pending call_rcu() callbacks
to execute. The callback can still be queued when module text is freed.
The rcu_barrier() is needed to flush them.
Many modules (including fuse itself) already call rcu_barrier() on exit
for exactly this reason. Documentation/RCU/rcubarrier.rst also explicitly
states that synchronize_rcu() does not wait for callbacks and cannot
replace rcu_barrier().
Thanks,
Baokun
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] cuse: wait for pending RCU callbacks on module exit
2026-08-18 7:59 ` Baokun Li
@ 2026-08-18 8:33 ` Miklos Szeredi
0 siblings, 0 replies; 4+ messages in thread
From: Miklos Szeredi @ 2026-08-18 8:33 UTC (permalink / raw)
To: Baokun Li; +Cc: fuse-devel, linux-fsdevel, linux-kernel, viro, jefflexu
On Tue, 18 Aug 2026 at 10:00, Baokun Li <libaokun@linux.alibaba.com> wrote:
> Many modules (including fuse itself) already call rcu_barrier() on exit
> for exactly this reason. Documentation/RCU/rcubarrier.rst also explicitly
> states that synchronize_rcu() does not wait for callbacks and cannot
> replace rcu_barrier().
Got it.
Applied, thanks.
Miklos
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-08-18 8:33 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-08-14 13:40 [PATCH] cuse: wait for pending RCU callbacks on module exit Baokun Li
2026-08-18 7:33 ` Miklos Szeredi
2026-08-18 7:59 ` Baokun Li
2026-08-18 8:33 ` Miklos Szeredi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®