linux-kernel - Re: [PATCH v2 2/2] tty: Fix race against tty_open() in tty_register_device

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <16cc8c9d-f89a-406c-9427-94ca75984752@enpas.org>
Date: Mon, 2 Jun 2025 22:40:55 +0900
From: Max Staudt <max@...as.org>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Jiri Slaby <jirislaby@...nel.org>, Johan Hovold <johan@...nel.org>,
 linux-serial <linux-serial@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org
Subject: Re: [PATCH v2 2/2] tty: Fix race against tty_open() in
 tty_register_device_attr()

On 6/2/25 19:31, Ilpo Järvinen wrote:
>> +	mutex_lock(&tty_mutex);
> 
> Use guard() so you don't need to change the returns and rollback path.

Thanks, I didn't know about this new kind of helper.

I'll leave it up to the TTY maintainers - if they don't express a 
preference for guard(), then I deem this code simple enough to leave it 
as-is, because I don't have any experience with guard(), and in fact, 
until 5 minutes ago, I didn't know at all that GCC cleanup attributes 
even exist.

Interestingly, Documentation/process/maintainer-netdev.rst documents a 
preference against guard(). I wonder why, but that's for another day.

Do you have an idea on how to solve the circular lock that the kernel 
test robot found for v1 of this patch?

   https://lore.kernel.org/linux-serial/202505281412.8c836cb7-lkp@intel.com/

Max