Описание
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
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:
-
In the packets captured during a normal connection, the host sends a
Read Encryption Key Sizetype ofHCI_CMDpacket (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size. -
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.
-
After re...
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
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:
-
In the packets captured during a normal connection, the host sends a
Read Encryption Key Sizetype ofHCI_CMDpacket (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size. -
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.
-
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 executedreturn hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);, specifically when accessingconn->hcon, a null-ptr-deref error occurred.
To fix this bug, check if sk->sk_state is BT_CLOSED before calling
rfcomm_recv_frame in rfcomm_process_rx.
Ссылки
- https://nvd.nist.gov/vuln/detail/CVE-2024-26903
- https://git.kernel.org/stable/c/2535b848fa0f42ddff3e5255cf5e742c9b77bb26
- https://git.kernel.org/stable/c/369f419c097e82407dd429a202cde9a73d3ae29b
- https://git.kernel.org/stable/c/3ead59bafad05f2967ae2438c0528d53244cfde5
- https://git.kernel.org/stable/c/567c0411dc3b424fc7bd1e6109726d7ba32d4f73
- https://git.kernel.org/stable/c/5f369efd9d963c1f711a06c9b8baf9f5ce616d85
- https://git.kernel.org/stable/c/5f9fe302dd3a9bbc50f4888464c1773f45166bfd
- https://git.kernel.org/stable/c/81d7d920a22fd58ef9aedb1bd0a68ee32bd23e96
- https://git.kernel.org/stable/c/8d1753973f598531baaa2c1033cf7f7b5bb004b0
- https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html
- https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security 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 Completepacket (Event Code: 0x0e) to return the Encryption Key Size. 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. 3. After receivi...
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security 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 Completepacket (Event Code: 0x0e) to return the Encryption Key Size. 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. 3. After receivi...
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security 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 Completepacket (Event Code: 0x0e) to return the Encryption Key Size. 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. 3. After recei
In the Linux kernel, the following vulnerability has been resolved: B ...