<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 23:48:25 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-40220 — fuse: fix livelock in synchronous file put from fuseblk workers</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-40220</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fuse: fix livelock in synchronous file put from fuseblk workers&lt;/p&gt;
&lt;p&gt;I observed a hang when running generic/323 against a fuseblk server.
This test opens a file, initiates a lot of AIO writes to that file
descriptor, and closes the file descriptor before the writes complete.
Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for
responses from the fuseblk server:&lt;/p&gt;
&lt;p&gt;# cat /proc/372265/task/372313/stack
[&amp;lt;0&amp;gt;] request_wait_answer+0x1fe/0x2a0 [fuse]
[&amp;lt;0&amp;gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]
[&amp;lt;0&amp;gt;] fuse_do_getattr+0xfc/0x1f0 [fuse]
[&amp;lt;0&amp;gt;] fuse_file_read_iter+0xbe/0x1c0 [fuse]
[&amp;lt;0&amp;gt;] aio_read+0x130/0x1e0
[&amp;lt;0&amp;gt;] io_submit_one+0x542/0x860
[&amp;lt;0&amp;gt;] __x64_sys_io_submit+0x98/0x1a0
[&amp;lt;0&amp;gt;] do_syscall_64+0x37/0xf0
[&amp;lt;0&amp;gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53&lt;/p&gt;
&lt;p&gt;But the /weird/ part is that the fuseblk server threads are waiting for
responses from itself:&lt;/p&gt;
&lt;p&gt;# cat /proc/372210/task/372232/stack
[&amp;lt;0&amp;gt;] request_wait_answer+0x1fe/0x2a0 [fuse]
[&amp;lt;0&amp;gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]
[&amp;lt;0&amp;gt;] fuse_file_put+0x9a/0xd0 [fuse]
[&amp;lt;0&amp;gt;] fuse_release+0x36/0x50 [fuse]
[&amp;lt;0&amp;gt;] __fput+0xec/0x2b0
[&amp;lt;0&amp;gt;] task_work_run+0x55/0x90
[&amp;lt;0&amp;gt;] syscall_exit_to_user_mode+0xe9/0x100
[&amp;lt;0&amp;gt;] do_syscall_64+0x43/0xf0
[&amp;lt;0&amp;gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53&lt;/p&gt;
&lt;p&gt;The fuseblk server is fuse2fs so there&amp;#39;s nothing all that exciting in
the server itself.  So why is the fuse server calling fuse_file_put?
The commit message for the fstest sheds some light on…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fuse: fix livelock in synchronous file put from fuseblk workers&lt;/p&gt;
&lt;p&gt;I observed a hang when running generic/323 against a fuseblk server.
This test opens a file, initiates a lot of AIO writes to that file
descriptor, and closes the file descriptor before the writes complete.
Unsurprisingly, the AIO exerciser threads are mostly stuck waiting for
responses from the fuseblk server:&lt;/p&gt;
&lt;p&gt;# cat /proc/372265/task/372313/stack
[&amp;lt;0&amp;gt;] request_wait_answer+0x1fe/0x2a0 [fuse]
[&amp;lt;0&amp;gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]
[&amp;lt;0&amp;gt;] fuse_do_getattr+0xfc/0x1f0 [fuse]
[&amp;lt;0&amp;gt;] fuse_file_read_iter+0xbe/0x1c0 [fuse]
[&amp;lt;0&amp;gt;] aio_read+0x130/0x1e0
[&amp;lt;0&amp;gt;] io_submit_one+0x542/0x860
[&amp;lt;0&amp;gt;] __x64_sys_io_submit+0x98/0x1a0
[&amp;lt;0&amp;gt;] do_syscall_64+0x37/0xf0
[&amp;lt;0&amp;gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53&lt;/p&gt;
&lt;p&gt;But the /weird/ part is that the fuseblk server threads are waiting for
responses from itself:&lt;/p&gt;
&lt;p&gt;# cat /proc/372210/task/372232/stack
[&amp;lt;0&amp;gt;] request_wait_answer+0x1fe/0x2a0 [fuse]
[&amp;lt;0&amp;gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]
[&amp;lt;0&amp;gt;] fuse_file_put+0x9a/0xd0 [fuse]
[&amp;lt;0&amp;gt;] fuse_release+0x36/0x50 [fuse]
[&amp;lt;0&amp;gt;] __fput+0xec/0x2b0
[&amp;lt;0&amp;gt;] task_work_run+0x55/0x90
[&amp;lt;0&amp;gt;] syscall_exit_to_user_mode+0xe9/0x100
[&amp;lt;0&amp;gt;] do_syscall_64+0x43/0xf0
[&amp;lt;0&amp;gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53&lt;/p&gt;
&lt;p&gt;The fuseblk server is fuse2fs so there&amp;#39;s nothing all that exciting in
the server itself.  So why is the fuse server calling fuse_file_put?
The commit message for the fstest sheds some light on…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-40220</guid>
    </item>
  </channel>
</rss>
