5.10-stable patches

added patches:
	fuse-fix-device-node-leak-in-cuse_process_init_reply.patch
	fuse-re-lock-request-before-returning-from-fuse_ref_folio.patch

diff --git a/queue-5.10/fuse-fix-device-node-leak-in-cuse_process_init_reply.patch b/queue-5.10/fuse-fix-device-node-leak-in-cuse_process_init_reply.patch
new file mode 100644 (file)
index 0000000..a58cb95
--- /dev/null
+++ b/queue-5.10/fuse-fix-device-node-leak-in-cuse_process_init_reply.patch
@@ -0,0 +1,68 @@
+From 9fa4f7a53406430ee9982f2f636a15b338185122 Mon Sep 17 00:00:00 2001
+From: Alberto Ruiz <aruiz@redhat.com>
+Date: Wed, 8 Apr 2026 17:23:40 +0200
+Subject: fuse: fix device node leak in cuse_process_init_reply()
+
+From: Alberto Ruiz <aruiz@redhat.com>
+
+commit 9fa4f7a53406430ee9982f2f636a15b338185122 upstream.
+
+If device_add() succeeds during CUSE initialization but a subsequent
+step (cdev_alloc() or cdev_add()) fails, the error path calls
+put_device() without first calling device_del().  This leaks the
+devtmpfs entry created by device_add(), leaving a stale /dev/<name>
+node that persists until reboot.
+
+Since the cuse_conn is never linked into cuse_conntbl on the failure
+path, cuse_channel_release() sees cc->dev == NULL and skips
+device_unregister(), so no other code path cleans up the node.
+
+This has several consequences:
+
+ - The device name is permanently poisoned: any subsequent attempt to
+   create a CUSE device with the same name hits the stale sysfs entry,
+   device_add() fails, and the new device is aborted.
+
+ - The collision manifests as ENODEV returned to userspace with no
+   dmesg diagnostic, making it very difficult to debug.
+
+ - The failure is self-perpetuating: once a name is leaked, all future
+   attempts with that name fail identically.
+
+Fix this by introducing an err_dev label that calls device_del() to
+undo device_add() before falling through to err_unlock.  The existing
+err_unlock path from a device_add() failure correctly skips device_del()
+since the device was never added.
+
+Testing instructions can be found at the lore link below.
+
+Link: https://lore.kernel.org/all/20260408-wip-cuse-leak-fix-v1-0-1c028d575e97@redhat.com/
+Signed-off-by: Alberto Ruiz <aruiz@redhat.com>
+Fixes: 151060ac1314 ("CUSE: implement CUSE - Character device in Userspace")
+Cc: stable@vger.kernel.org
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fuse/cuse.c |    4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/fuse/cuse.c
++++ b/fs/fuse/cuse.c
+@@ -386,7 +386,7 @@ static void cuse_process_init_reply(stru
+       rc = -ENOMEM;
+       cdev = cdev_alloc();
+       if (!cdev)
+-              goto err_unlock;
++              goto err_dev;
+ 
+       cdev->owner = THIS_MODULE;
+       cdev->ops = &cuse_frontend_fops;
+@@ -412,6 +412,8 @@ out:
+ 
+ err_cdev:
+       cdev_del(cdev);
++err_dev:
++      device_del(dev);
+ err_unlock:
+       mutex_unlock(&cuse_lock);
+       put_device(dev);

diff --git a/queue-5.10/fuse-re-lock-request-before-returning-from-fuse_ref_folio.patch b/queue-5.10/fuse-re-lock-request-before-returning-from-fuse_ref_folio.patch
new file mode 100644 (file)
index 0000000..7993e01
--- /dev/null
+++ b/queue-5.10/fuse-re-lock-request-before-returning-from-fuse_ref_folio.patch
@@ -0,0 +1,37 @@
+From b5befa80fdbe287a98480effed9564712924add5 Mon Sep 17 00:00:00 2001
+From: Joanne Koong <joannelkoong@gmail.com>
+Date: Mon, 18 May 2026 22:28:07 -0700
+Subject: fuse: re-lock request before returning from fuse_ref_folio()
+
+From: Joanne Koong <joannelkoong@gmail.com>
+
+commit b5befa80fdbe287a98480effed9564712924add5 upstream.
+
+fuse_ref_folio() unlocks the request but does not re-lock it before
+returning. fuse_chan_abort() can end the request and the async end
+callback (eg fuse_writepage_free()) can free the args while the
+subsequent copy chain logic after fuse_ref_folio() accesses them,
+leading to use-after-free issues.
+
+Fix this by locking the request in fuse_ref_folio() before returning.
+
+Fixes: c3021629a0d8 ("fuse: support splice() reading from fuse device")
+Cc: stable@vger.kernel.org
+Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fuse/dev.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/fuse/dev.c
++++ b/fs/fuse/dev.c
+@@ -927,7 +927,7 @@ static int fuse_ref_page(struct fuse_cop
+       cs->nr_segs++;
+       cs->len = 0;
+ 
+-      return 0;
++      return lock_request(cs->req);
+ }
+ 
+ /*

diff --git a/queue-5.10/series b/queue-5.10/series
index 23f5975829624cadbd114715ffb47b5fbed1467e..8af9e925ad0ef2a8fd8a98889c410f8ef7643ae1 100644 (file)
--- a/queue-5.10/series
+++ b/queue-5.10/series
@@ -154,3 +154,5 @@ input-maple_keyb-set-driver-data-before-registering-input-device.patch
 input-maplemouse-set-driver-data-before-registering-input-device.patch
 input-maplecontrol-set-driver-data-before-registering-input-device.patch
 rdma-siw-bound-read-response-placement-to-the-rread-length.patch
+fuse-fix-device-node-leak-in-cuse_process_init_reply.patch
+fuse-re-lock-request-before-returning-from-fuse_ref_folio.patch