vulnerability

Ubuntu: (CVE-2022-49767): linux vulnerability

Severity
6
CVSS
(AV:L/AC:M/Au:S/C:N/I:C/A:C)
Published
May 1, 2025
Added
May 6, 2025
Modified
Jun 12, 2025

Description

In the Linux kernel, the following vulnerability has been resolved:

9p/trans_fd: always use O_NONBLOCK read/write

syzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop()
from p9_conn_destroy() from p9_fd_close() is failing to interrupt already
started kernel_read() from p9_fd_read() from p9_read_work() and/or
kernel_write() from p9_fd_write() from p9_write_work() requests.

Since p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not
need to interrupt kernel_read()/kernel_write(). However, since p9_fd_open()
does not set O_NONBLOCK flag, but pipe blocks unless signal is pending,
p9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when
the file descriptor refers to a pipe. In other words, pipe file descriptor
needs to be handled as if socket file descriptor.

We somehow need to interrupt kernel_read()/kernel_write() on pipes.

A minimal change, which this patch is doing, is to set O_NONBLOCK flag
from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing
of regular files. But this approach changes O_NONBLOCK flag on userspace-
supplied file descriptors (which might break userspace programs), and
O_NONBLOCK flag could be changed by userspace. It would be possible to set
O_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still
remains small race window for clearing O_NONBLOCK flag.

If we don't want to manipulate O_NONBLOCK flag, we might be able to
surround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING)
and recalc_sigpending(). Since p9_read_work()/p9_write_work() works are
processed by kernel threads which process global system_wq workqueue,
signals could not be delivered from remote threads when p9_mux_poll_stop()
from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling
set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be
needed if we count on signals for making kernel_read()/kernel_write()
non-blocking.

[Dominique: add comment at Christian's suggestion]

Solution(s)

ubuntu-upgrade-linuxubuntu-upgrade-linux-awsubuntu-upgrade-linux-aws-5-15ubuntu-upgrade-linux-aws-5-4ubuntu-upgrade-linux-aws-fipsubuntu-upgrade-linux-aws-hweubuntu-upgrade-linux-azureubuntu-upgrade-linux-azure-4-15ubuntu-upgrade-linux-azure-5-15ubuntu-upgrade-linux-azure-5-4ubuntu-upgrade-linux-azure-fipsubuntu-upgrade-linux-bluefieldubuntu-upgrade-linux-fipsubuntu-upgrade-linux-gcpubuntu-upgrade-linux-gcp-4-15ubuntu-upgrade-linux-gcp-5-15ubuntu-upgrade-linux-gcp-5-4ubuntu-upgrade-linux-gcp-fipsubuntu-upgrade-linux-gkeubuntu-upgrade-linux-gkeopubuntu-upgrade-linux-hweubuntu-upgrade-linux-hwe-5-15ubuntu-upgrade-linux-hwe-5-4ubuntu-upgrade-linux-ibmubuntu-upgrade-linux-ibm-5-4ubuntu-upgrade-linux-intel-iot-realtimeubuntu-upgrade-linux-intel-iotgubuntu-upgrade-linux-intel-iotg-5-15ubuntu-upgrade-linux-iotubuntu-upgrade-linux-kvmubuntu-upgrade-linux-lowlatencyubuntu-upgrade-linux-lowlatency-hwe-5-15ubuntu-upgrade-linux-nvidiaubuntu-upgrade-linux-nvidia-tegra-5-15ubuntu-upgrade-linux-oracleubuntu-upgrade-linux-oracle-5-15ubuntu-upgrade-linux-oracle-5-4ubuntu-upgrade-linux-raspiubuntu-upgrade-linux-raspi-5-4ubuntu-upgrade-linux-realtimeubuntu-upgrade-linux-riscv-5-15ubuntu-upgrade-linux-xilinx-zynqmp
Title
NEW

Explore Exposure Command

Confidently identify and prioritize exposures from endpoint to cloud with full attack surface visibility and threat-aware risk context.