linux-kernel - Re: 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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAN+4W8j004VeXm8gVGz=TJKNzt=LS-UKhRVRew1iLLiKxYPSSQ@mail.gmail.com>
Date: Mon, 15 Dec 2025 09:51:40 +0000
From: Lorenz Bauer <lmb@...valent.com>
To: Amit Shah <amit@...nel.org>
Cc: Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	virtualization@...ts.linux.dev, LKML <linux-kernel@...r.kernel.org>
Subject: Re: virtio_console: lost wakeup due to race between port_fops_poll()
 and vring_interrupt()

On Wed, Dec 10, 2025 at 3:58 PM Amit Shah <amit@...nel.org> wrote:
>
> Both port_fops_write() and port_fops_poll() call will_write_block() for
> checking the block condition -- which is whether port->outvq_full is
> set.  Even if buffers were consumed via poll, outvq_full should just
> return false, right?

Yes, it would. However, the problem is that port_fops_write never gets
to that part. It is stuck in wait_event_freezable(port->waitqueue).

> Hm, does adding wake_up(port->waitqueue) in case 'ret' is false in
> will_write_block() help?

It would, but I think it only addresses half of the problem. The read path
also calls reclaim_consumed_buffers. I've thrown together a patch which
issues a wakeup from reclaim_consumed_buffers instead, which seems
to work.

Best
Lorenz