CVE-2024-26903

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security<br /> <br /> During our fuzz testing of the connection and disconnection process at the<br /> RFCOMM layer, we discovered this bug. By comparing the packets from a<br /> normal connection and disconnection process with the testcase that<br /> triggered a KASAN report. We analyzed the cause of this bug as follows:<br /> <br /> 1. In the packets captured during a normal connection, the host sends a<br /> `Read Encryption Key Size` type of `HCI_CMD` packet<br /> (Command Opcode: 0x1408) to the controller to inquire the length of<br /> encryption key.After receiving this packet, the controller immediately<br /> replies with a Command Completepacket (Event Code: 0x0e) to return the<br /> Encryption Key Size.<br /> <br /> 2. In our fuzz test case, the timing of the controller&amp;#39;s response to this<br /> packet was delayed to an unexpected point: after the RFCOMM and L2CAP<br /> layers had disconnected but before the HCI layer had disconnected.<br /> <br /> 3. After receiving the Encryption Key Size Response at the time described<br /> in point 2, the host still called the rfcomm_check_security function.<br /> However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)-&gt;chan-&gt;conn;`<br /> had already been released, and when the function executed<br /> `return hci_conn_security(conn-&gt;hcon, d-&gt;sec_level, auth_type, d-&gt;out);`,<br /> specifically when accessing `conn-&gt;hcon`, a null-ptr-deref error occurred.<br /> <br /> To fix this bug, check if `sk-&gt;sk_state` is BT_CLOSED before calling<br /> rfcomm_recv_frame in rfcomm_process_rx.