linux-kernel - Re: [PATCH] n_tty: fix data race in n_tty

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: <2025052123-landmark-capitol-effb@gregkh>
Date: Wed, 21 May 2025 13:27:06 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Jeongjun Park <aha310510@...il.com>
Cc: jirislaby@...nel.org, linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH] n_tty: fix data race in n_tty_poll()

On Sun, May 11, 2025 at 01:38:27AM +0900, Jeongjun Park wrote:
> I found data-race in my fuzzer:
> 
> ==================================================================
> BUG: KCSAN: data-race in n_tty_poll / tty_set_termios
> 
> read to 0xffff8880116b4d14 of 4 bytes by task 5443 on cpu 0:
>  n_tty_poll+0xa4/0x4c0 drivers/tty/n_tty.c:2452
>  tty_poll+0x8f/0x100 drivers/tty/tty_io.c:2208
>  vfs_poll include/linux/poll.h:82 [inline]
>  select_poll_one fs/select.c:480 [inline]
>  do_select+0x95f/0x1030 fs/select.c:536
>  core_sys_select+0x284/0x6d0 fs/select.c:677
> ....
> 
> write to 0xffff8880116b4d08 of 44 bytes by task 14547 on cpu 1:
>  tty_set_termios+0xf9/0x500 drivers/tty/tty_ioctl.c:339
>  set_termios.part.0+0x3bc/0x4d0 drivers/tty/tty_ioctl.c:520
>  set_termios drivers/tty/tty_ioctl.c:454 [inline]
>  tty_mode_ioctl+0x2db/0xa00 drivers/tty/tty_ioctl.c:807
>  n_tty_ioctl_helper+0x4e/0x230 drivers/tty/tty_ioctl.c:986
>  n_tty_ioctl+0x67/0x230 drivers/tty/n_tty.c:2509
> ....
> ==================================================================
> 
> In n_tty_poll() we are doing a read on tty->termios but we are missing
> rwsem lock, which causes a concurrency problem. To fix this, we need to
> add rwsem lock at the appropriate location.

Does this "concurrency problem" actually cause a real issue?

As the tools point out, your change will not work as you will have a
locking deadlock, which makes me wonder how you tested it?

thanks,

greg k-h