[Bug 218323] New: KASAN: null-ptr-deref in rfcomm_check_security in Kernel 6.7-rc2

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=218323

            Bug ID: 218323
           Summary: KASAN: null-ptr-deref in rfcomm_check_security in
                    Kernel 6.7-rc2
           Product: Drivers
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: high
          Priority: P3
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: 20373622@buaa.edu.cn
        Regression: No

Created attachment 305656
  --> https://bugzilla.kernel.org/attachment.cgi?id=305656&action=edit
terminal log

Hello All,

Our fuzzing tool find a null-ptr-deref in rfcomm_check_security in Linux
6.7-rc2.

During our fuzz testing of the connection and disconnection process at the
RFCOMM layer, we discovered this bug. By comparing the packets from a normal
connection and disconnection process with the testcase that triggered a KASAN
report, we analyzed the cause of this bug as follows:

1. In the packets captured during a normal connection, the host sends a `Read
Encryption Key Size` type of `HCI_CMD` packet (Command Opcode: 0x1408) to the
controller to inquire the length of encryption key. After receiving this
packet, the controller immediately replies with a Command Complete packet
(Event Code: 0x0e) to return the Encryption Key Size. (See Attachment 2)

2. In our fuzz test case, the timing of the controller's response to this
packet was delayed to an unexpected point: after the RFCOMM and L2CAP layers
had disconnected but before the HCI layer had disconnected. (See Attachment 3)

3. After receiving the Encryption Key Size Response at the time described in
point 2, the host still called the rfcomm_check_security function. However, by
this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;` had already
been released, and when the function executed `return
hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`, specifically
when accessing `conn->hcon`, a null-ptr-deref error occurred.

Attachment 1(vm.log) is the complete terminal log when this bug was triggered,
including the KASAN report and the HCI layer packets. The HCI packets exchanged
between host and controller were printed by the HCI driver. For example:
[H->D:CMD] indicates an HCI_CMD packet sent from the host to the controller.

This bug can be reproduced with a relatively high level of consistency. We
conducted 10 tests using the same sequence of packets, and out of those, the
bug triggered the KASAN report 7 times.

Here is the KASAN report:

general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 PID: 539 Comm: krfcommd Tainted: G           O       6.7.0-rc2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1
04/01/2014
RIP: 0010:rfcomm_check_security+0x142/0x230 [rfcomm]
Code: 00 00 48 89 e8 48 c1 e8 03 42 8a 1c 20 84 db 0f 85 9a 00 00 00 bf ea 04
20 50 e8 c9 3c d9 ff 44 8a 6d 00 4c 89 f8 48 c1 e8 03 <42> 80 3c 20 00 74 12 bf
1b 2f 83 28 e8 ad 3c d9 ff 4c 89 ff e8 f5
RSP: 0018:ffff88800b797c20 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88800559f000 RCX: 00000000c0249000
RDX: dffffc0000000000 RSI: 0000000000000246 RDI: ffffffffc0249000
RBP: ffff8880072f9893 R08: ffff88800b797b73 R09: 1ffff110016f2f6e
R10: dffffc0000000000 R11: ffffed10016f2f6f R12: dffffc0000000000
R13: ffff8880072f9801 R14: ffff8880072f9800 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd235665000 CR3: 0000000004784000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 ? __die_body+0x62/0xb0 
 ? die_addr+0xbe/0xf0 
 ? exc_general_protection+0x2a7/0x3c0
 ? asm_exc_general_protection+0x22/0x30
 ? rfcomm_check_security+0x142/0x230 [rfcomm]
 rfcomm_process_connect+0x1ad/0x280 [rfcomm]
 rfcomm_process_rx+0x1064/0x1b80 [rfcomm]
 ? __mfuzz_coverage__+0x16/0x140 [mfuzz_monitor]
 rfcomm_process_sessions+0x758/0x1d20 [rfcomm]
 ? _raw_spin_lock_irqsave+0x8d/0x130
 ? __mfuzz_coverage__+0x16/0x140 [mfuzz_monitor]
 rfcomm_run+0x49f/0x6d0 [rfcomm]
 ? wait_woken+0xf0/0xf0
 ? skb_tail_pointer+0xc0/0xc0 [rfcomm]
 kthread+0x275/0x300
 ? skb_tail_pointer+0xc0/0xc0 [rfcomm]
 ? kthread_blkcg+0xa0/0xa0
 ret_from_fork+0x30/0x60
 ? kthread_blkcg+0xa0/0xa0
 ret_from_fork_asm+0x11/0x20
 </TASK>
Modules linked in: btvirt(O) rfcomm(O) bnep(O) btintel bluetooth(O)
mfuzz_monitor(O) ecdh_generic ecc [last unloaded: btvirt(O)]
---[ end trace 0000000000000000 ]---
RIP: 0010:rfcomm_check_security+0x142/0x230 [rfcomm]
Code: 00 00 48 89 e8 48 c1 e8 03 42 8a 1c 20 84 db 0f 85 9a 00 00 00 bf ea 04
20 50 e8 c9 3c d9 ff 44 8a 6d 00 4c 89 f8 48 c1 e8 03 <42> 80 3c 20 00 74 12 bf
1b 2f 83 28 e8 ad 3c d9 ff 4c 89 ff e8 f5
RSP: 0018:ffff88800b797c20 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88800559f000 RCX: 00000000c0249000
RDX: dffffc0000000000 RSI: 0000000000000246 RDI: ffffffffc0249000
RBP: ffff8880072f9893 R08: ffff88800b797b73 R09: 1ffff110016f2f6e
R10: dffffc0000000000 R11: ffffed10016f2f6f R12: dffffc0000000000
R13: ffff8880072f9801 R14: ffff8880072f9800 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd235665000 CR3: 0000000004784000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


Any feedback would be appreciated, thanks!

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.