<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-15T10:51:59.731484+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2025-40220</id>
    <title>CVE-2025-40220 — fuse: fix livelock in synchronous file put from fuseblk workers</title>
    <updated>2026-10-15T10:51:59.801917+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>fuse: fix livelock in synchronous file put from fuseblk workers</p>
<p>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:</p>
<p># cat /proc/372265/task/372313/stack
[&lt;0&gt;] request_wait_answer+0x1fe/0x2a0 [fuse]
[&lt;0&gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]
[&lt;0&gt;] fuse_do_getattr+0xfc/0x1f0 [fuse]
[&lt;0&gt;] fuse_file_read_iter+0xbe/0x1c0 [fuse]
[&lt;0&gt;] aio_read+0x130/0x1e0
[&lt;0&gt;] io_submit_one+0x542/0x860
[&lt;0&gt;] __x64_sys_io_submit+0x98/0x1a0
[&lt;0&gt;] do_syscall_64+0x37/0xf0
[&lt;0&gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53</p>
<p>But the /weird/ part is that the fuseblk server threads are waiting for
responses from itself:</p>
<p># cat /proc/372210/task/372232/stack
[&lt;0&gt;] request_wait_answer+0x1fe/0x2a0 [fuse]
[&lt;0&gt;] __fuse_simple_request+0xd3/0x2b0 [fuse]
[&lt;0&gt;] fuse_file_put+0x9a/0xd0 [fuse]
[&lt;0&gt;] fuse_release+0x36/0x50 [fuse]
[&lt;0&gt;] __fput+0xec/0x2b0
[&lt;0&gt;] task_work_run+0x55/0x90
[&lt;0&gt;] syscall_exit_to_user_mode+0xe9/0x100
[&lt;0&gt;] do_syscall_64+0x43/0xf0
[&lt;0&gt;] entry_SYSCALL_64_after_hwframe+0x4b/0x53</p>
<p>The fuseblk server is fuse2fs so there'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…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2025-40220"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/usn-8029-1</id>
    <title>USN-8029-1 — linux, linux-raspi, linux-realtime vulnerabilities</title>
    <updated>2026-10-15T10:51:59.802043+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:25.10: linux, Ubuntu:25.10: linux-raspi, Ubuntu:25.10: linux-realtime</p>
<p>Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - ARM64 architecture;
  - MIPS architecture;
  - Nios II architecture;
  - PA-RISC architecture;
  - RISC-V architecture;
  - S390 architecture;
  - Sun Sparc architecture;
  - x86 architecture;
  - Xtensa architecture;
  - Block layer subsystem;
  - Cryptographic API;
  - Compute Acceleration Framework;
  - ACPI drivers;
  - Drivers core;
  - Network block device driver;
  - Bluetooth drivers;
  - Bus devices;
  - Hardware random number generator core;
  - Character device driver;
  - Clock framework and drivers;
  - Data acquisition framework and drivers;
  - CPU frequency scaling framework;
  - Hardware crypto device drivers;
  - CXL (Compute Express Link) drivers;
  - Device frequency scaling framework;
  - ARM SCMI message protocol;
  - GPIO subsystem;
  - GPU drivers;
  - Hardware monitoring drivers;
  - HW tracing;
  - InfiniBand drivers;
  - Input Device (Miscellaneous) drivers;
  - IOMMU subsystem;
  - ISDN/mISDN subsystem;
  - Mailbox framework;
  - Multiple devices driver;
  - Media drivers;
  - Fastrpc Driver;
  - PCI Endpoint Test driver;
  - VMware Balloon Driver;
  - MOST (Media Oriented Systems Transport) drivers;
  - Network drivers;
  - Mellanox network drivers;
  - STMicroelectronics network drivers;
  - NVME drivers;
  - PCI subsystem;
  - Performance monitor drivers;
  - Pin…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/usn-8029-1"/>
  </entry>
</feed>
