linux-kernel - virtio_console: lost wakeup due to race between port_fops_poll() and vring

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: <CAN+4W8hLrR1B1pNdDXiVuzoJ1q8Ta1kjV0v8vKVEZeHdRFKGcg@mail.gmail.com>
Date: Fri, 5 Dec 2025 18:06:41 +0000
From: Lorenz Bauer <lmb@...valent.com>
To: Amit Shah <amit@...nel.org>, Arnd Bergmann <arnd@...db.de>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, virtualization@...ts.linux.dev, 
	LKML <linux-kernel@...r.kernel.org>
Subject: virtio_console: lost wakeup due to race between port_fops_poll() and vring_interrupt()

Hi,

I've been chasing a bug when using virtio console to exchange data
between guest and host. It manifests in a process inside the guest
getting stuck while writing to the serial port:

    [<0>] wait_port_writable+0x139/0x2d0
    [<0>] port_fops_write+0x88/0x130
    [<0>] vfs_write+0xf3/0x450
    [<0>] ksys_write+0x6d/0xe0
    [<0>] do_syscall_64+0x9e/0x1a0
    [<0>] entry_SYSCALL_64_after_hwframe+0x77/0x7

I managed to track this down to a race in virtio_console.c. The driver
doesn't properly account for a port that receives blocking writes and
is polled at the same time. I suspect that a similar problem exists in
port_fops_read().

Here is how it goes. We need two threads inside the guest, A and B.

- Thread A writes to the serial port until the virtqueue fills up.
- Thread A invokes port_fops_write() which calls wait_port_writable().
There are no used buffers to reclaim and the thread is suspended,
waiting on port->waitqueue.
- The host side of the device makes some progress, marks some buffers
as consumed / used and  sends an interrupt to the guest.
- Before the guest can service the interrupt, thread B executes
port_fops_poll(). This calls into
  reclaim_consumed_buffers() via will_write_block(), which removes all
used buffers.
- The interrupt gets serviced, calling into vring_interrupt(). Here
the check for more_used() returns false because the poll just went
through all the work. The handler returns without waking
port->waitqueue.
- port_fops_write() never returns.

I'm not exactly sure how to best fix this. Maybe it's enough to only
check outvq_full in poll? It'd also be nice to fix this on the read
side as well.

I only have a reproducer which requires a Go toolchain unfortunately:
https://github.com/lmb/vimto/issues/29

Best
Lorenz