Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-947-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <6572ae72-0d2e-4c48-9a46-877f46890811@buaa.edu.cn>
Date: Mon, 8 Jan 2024 19:28:51 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH V3] Bluetooth: rfcomm: Fix null-ptr-deref in
 rfcomm_check_security
To: marcel@holtmann.org, johan.hedberg@gmail.com, luiz.dentz@gmail.com,
 pmenzel@molgen.mpg.de
Cc: linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
 baijiaju1990@gmail.com, sy2239101@buaa.edu.cn
References: <20240103090238.3376565-1-20373622@buaa.edu.cn>
From: Yuxuan-Hu <20373622@buaa.edu.cn>
In-Reply-To: <20240103090238.3376565-1-20373622@buaa.edu.cn>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear All:

I hope this email finds you well. I hope you haven't missed my previous 
email, as I understand that everyone has a busy schedule. I just wanted 
to follow up on my previous message sent.

I understand that you may be occupied with other tasks or priorities. 
However, I would greatly appreciate it if you could spare a few moments 
to check the patch in my previous email. Your prompt response would be 
highly valuable to me.

Thank you for your attention to this matter, and I look forward to 
hearing from you soon.


On 2024/1/3 17:02, Yuxuan Hu wrote:
> 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.
>
> 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>
> ---
> V1 -> V2: Check earlier on rfcomm_process_rx
> V2 -> V3: Fixed formatting errors in the commit
>
>   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 053ef8f25fae..1d34d8497033 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -1941,7 +1941,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;