Detections
Analytics
Unity Linux 20.1070a Security Update: kernel (UTSA-2026-012997)
medium Nessus Plugin ID 307743
Synopsis
The Unity Linux host is missing one or more security updates.Description
The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-012997 advisory.In the Linux kernel, the following vulnerability has been resolved:
fuse: fix livelock in synchronous file put from fuseblk workers
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:
# cat /proc/372265/task/372313/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_do_getattr+0xfc/0x1f0 [fuse] [<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse] [<0>] aio_read+0x130/0x1e0 [<0>] io_submit_one+0x542/0x860 [<0>] __x64_sys_io_submit+0x98/0x1a0 [<0>] do_syscall_64+0x37/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
But the /weird/ part is that the fuseblk server threads are waiting for responses from itself:
# cat /proc/372210/task/372232/stack [<0>] request_wait_answer+0x1fe/0x2a0 [fuse] [<0>] __fuse_simple_request+0xd3/0x2b0 [fuse] [<0>] fuse_file_put+0x9a/0xd0 [fuse] [<0>] fuse_release+0x36/0x50 [fuse] [<0>] __fput+0xec/0x2b0 [<0>] task_work_run+0x55/0x90 [<0>] syscall_exit_to_user_mode+0xe9/0x100 [<0>] do_syscall_64+0x43/0xf0 [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53
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 that:
By closing the file descriptor before calling io_destroy, you pretty much guarantee that the last put on the ioctx will be done in interrupt context (during I/O completion).
Aha. AIO fgets a new struct file from the fd when it queues the ioctx.
The completion of the FUSE_WRITE command from userspace causes the fuse server to call the AIO completion function. The completion puts the struct file, queuing a delayed fput to the fuse server task. When the fuse server task returns to userspace, it has to run the delayed fput, which in the case of a fuseblk server, it does synchronously.
Sending the FUSE_RELEASE command sychronously from fuse server threads is a bad idea because a client program can initiate enough simultaneous AIOs such that all the fuse server threads end up in delayed_fput, and now there aren't any threads left to handle the queued fuse commands.
Fix this by only using asynchronous fputs when closing files, and leave a comment explaining why.
Tenable has extracted the preceding description block directly from the Unity Linux security advisory.
Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.
Solution
Update the affected kernel package.See Also
http://www.nessus.org/u?31fec39e
Plugin Details
Severity: Medium
ID: 307743
File Name: unity_linux_UTSA-2026-012997.nasl
Version: 1.1
Type: Local
Published: 4/21/2026
Updated: 4/21/2026
Supported Sensors: Nessus
Risk Information
VPR
Risk Factor: Medium
Score: 4.4
CVSS v2
Risk Factor: Medium
Base Score: 5.2
Temporal Score: 3.8
Vector: CVSS2#AV:L/AC:L/Au:S/C:N/I:P/A:C
CVSS Score Source: CVE-2025-40220
CVSS v3
Risk Factor: Medium
Base Score: 5.5
Temporal Score: 4.8
Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C
Vulnerability Information
Required KB Items: Host/local_checks_enabled, Host/UOS-Server/release, Host/UOS-Server/rpm-list, Host/cpu
Exploit Ease: No known exploits are available
Patch Publication Date: 4/21/2026
Vulnerability Publication Date: 11/14/2025
Reference Information
CVE: CVE-2025-40220