lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025050114-CVE-2022-49767-73e9@gregkh>
Date: Thu,  1 May 2025 16:09:17 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2022-49767: 9p/trans_fd: always use O_NONBLOCK read/write

From: Greg Kroah-Hartman <gregkh@...nel.org>

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]

The Linux kernel CVE team has assigned CVE-2022-49767 to this issue.


Affected and fixed versions
===========================

	Fixed in 4.9.334 with commit 0b5e6bd72b8171364616841603a70e4ba9837063
	Fixed in 4.14.300 with commit 9f8554615df668e4bf83294633ee9d232b28ce45
	Fixed in 4.19.267 with commit 7abf40f06a76c0dff42eada10597917e9776fbd4
	Fixed in 5.4.225 with commit b1ad04da7fe4515e2ce2d5f2dcab3b5b6d45614b
	Fixed in 5.10.156 with commit a8e2fc8f7b41fa9d9ca5f624f4e4d34fce5b40a9
	Fixed in 5.15.80 with commit 0e07032b4b4724b8ad1003698cb81083c1818999
	Fixed in 6.0.10 with commit 5af16182c5639349415118e9e9aecd8355f7a08b
	Fixed in 6.1 with commit ef575281b21e9a34dfae544a187c6aac2ae424a9

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-49767
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/9p/trans_fd.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/0b5e6bd72b8171364616841603a70e4ba9837063
	https://git.kernel.org/stable/c/9f8554615df668e4bf83294633ee9d232b28ce45
	https://git.kernel.org/stable/c/7abf40f06a76c0dff42eada10597917e9776fbd4
	https://git.kernel.org/stable/c/b1ad04da7fe4515e2ce2d5f2dcab3b5b6d45614b
	https://git.kernel.org/stable/c/a8e2fc8f7b41fa9d9ca5f624f4e4d34fce5b40a9
	https://git.kernel.org/stable/c/0e07032b4b4724b8ad1003698cb81083c1818999
	https://git.kernel.org/stable/c/5af16182c5639349415118e9e9aecd8355f7a08b
	https://git.kernel.org/stable/c/ef575281b21e9a34dfae544a187c6aac2ae424a9

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ