[BUG] Bluetooth: rfcomm: possible circular locking dependency in the SAK vs. connect path

[BUG] Bluetooth: rfcomm: possible circular locking dependency in the SAK vs. connect path

[CJ]

Hi,


I am reporting an issue triggered by a syzkaller reproducer on Linux
7.3.0-rc2. The issue is reproducible with HEAD commit
df2908090cda368b01ff43709f51890076c56157.


The reproducer creates an RFCOMM socket on a vhci-backed HCI device, binds
and listens on it, and then injects four crafted RFCOMM frames through
syz_emit_vhci(). The frames drive the RFCOMM receiver into the connection
indication path.


Lockdep reports a circular locking dependency involving rfcomm. On the
reporting side the task holds console_lock (taken in vc_SAK) and tries to
acquire the tty buffer lock (&buf->lock, at tty_buffer_flush); the reverse
dependency chain shows console_lock being acquired by con_flush_chars() from
n_tty_write(). The lock class of interest for rfcomm is entered through
lock_sock_nested() from rfcomm_connect_ind(), which the earlier report on
linux-6.1 also showed.


This looks like a lock ordering problem between the RFCOMM receive/setup
path and the tty/console teardown path, rather than a specific bad pointer.
The earlier report against the same reproducer described the matching edge
of the cycle, with tty termios_rwsem taken at n_tty_flush_buffer() while
holding the tty buffer lock, so the cycle has been reachable for a while and
the participating locks are the same. Serializing the RFCOMM session setup
and teardown against the socket lock would be the direction; I have not
verified which of the recent RFCOMM locking changes already covers it.


This failure was reported earlier against the linux-6.1 longterm series at
https://syzkaller.appspot.com/bug?extid=3a1f869dcd8f26e5c216, and the
reproducer below is the one from that report. It still reproduces on the
tested mainline kernel.


Reproducer:


syz reproducer:
The reproducer is the program below, which requires no large encoded image:


r0 = syz_init_net_socket$bt_rfcomm(0x1f, 0x1, 0x3)
bind$bt_rfcomm(r0, &(0x7f0000000000)={0x1f, @any, 0x1}, 0xa)
listen(r0, 0x5)
syz_emit_vhci(&(0x7f0000000200)=ANY=[@ANYBLOB="02c8200c00080001000202040003004000"], 0x11)
syz_emit_vhci(&(0x7f0000000300)=ANY=[@ANYBLOB="02c8200c00080001000403040040000000"], 0x11)
syz_emit_vhci(&(0x7f0000000400)=ANY=[@ANYBLOB="02c8200e000a00010005010600400000000000"], 0x13)
syz_emit_vhci(&(0x7f0000000600)=ANY=[@ANYBLOB="02c82012000e00400003ef158311020007007f00000770"], 0x17)


console output: https://pastebin.com/raw/zLyVGhi5
kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=31dfefc4a14efea3


Kernel:


HEAD commit: df2908090cda368b01ff43709f51890076c56157
git tree: mainline
kernel version: 7.3.0-rc2
tested tag: v7.3-rc2 (annotated tag object 5e036ce12de91c6fd674dad33b169c6150be2a7a)


Let me know if you need more details or testing.


Best regards,
Changjian Liu