diff options
Diffstat (limited to 'debian/patches/bugfix/all/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_.patch')
| -rw-r--r-- | debian/patches/bugfix/all/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_.patch | 57 |
1 files changed, 0 insertions, 57 deletions
diff --git a/debian/patches/bugfix/all/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_.patch b/debian/patches/bugfix/all/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_.patch deleted file mode 100644 index 258ab6ea4..000000000 --- a/debian/patches/bugfix/all/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_.patch +++ /dev/null @@ -1,57 +0,0 @@ -From: Yuxuan Hu <20373622@buaa.edu.cn> -Date: Wed, 3 Jan 2024 17:10:43 +0800 -Subject: Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security -Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id=567c0411dc3b424fc7bd1e6109726d7ba32d4f73 -Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-22099 - -[ Upstream commit 2535b848fa0f42ddff3e5255cf5e742c9b77bb26 ] - -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 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. - -To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling -rfcomm_recv_frame in rfcomm_process_rx. - -Signed-off-by: Yuxuan Hu <20373622@buaa.edu.cn> -Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> -Signed-off-by: Sasha Levin <sashal@kernel.org> ---- - net/bluetooth/rfcomm/core.c | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c -index 8d6fce9005bd..4f54c7df3a94 100644 ---- a/net/bluetooth/rfcomm/core.c -+++ b/net/bluetooth/rfcomm/core.c -@@ -1937,7 +1937,7 @@ static struct rfcomm_session *rfcomm_process_rx(struct rfcomm_session *s) - /* Get data directly from socket receive queue without copying it. */ - while ((skb = skb_dequeue(&sk->sk_receive_queue))) { - skb_orphan(skb); -- if (!skb_linearize(skb)) { -+ if (!skb_linearize(skb) && sk->sk_state != BT_CLOSED) { - s = rfcomm_recv_frame(s, skb); - if (!s) - break; --- -2.43.0 - |