Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 11 May 2021 15:28:42 +0800
Message-Id: <20210511152807.Bluez.v1.1.I6d2ab6907d9a84fa62ac8a39daef5bef7ff545d5@changeid>
Mime-Version: 1.0
Subject: [Bluez PATCH v1] monitor: Fix possible crash of rfcomm packet
From:   Howard Chung <howardchung@google.com>
To:     linux-bluetooth@vger.kernel.org, luiz.dentz@gmail.com
Cc:     chromeos-bluetooth-upstreaming@chromium.org,
        Yun-Hao Chung <howardchung@chromium.org>, apusaka@chromium.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

From: Yun-Hao Chung <howardchung@chromium.org>

When RFCOMM_TEST_EA returns false, btmon assumes packet data has at
least 5 bytes long. If that assumption fails, btmon could crash when
trying to read the next byte.
This patch fix it by checking the remaining size before reading the last
byte.

Reviewed-by: apusaka@chromium.org
---

 monitor/rfcomm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/monitor/rfcomm.c b/monitor/rfcomm.c
index 9b88a3440e31..76b1123bb23d 100644
--- a/monitor/rfcomm.c
+++ b/monitor/rfcomm.c
@@ -452,6 +452,9 @@ void rfcomm_packet(const struct l2cap_frame *frame)
 		hdr.length = GET_LEN16(hdr.length);
 	}
 
+	if (l2cap_frame->size == 0)
+		goto fail;
+
 	l2cap_frame_pull(&tmp_frame, l2cap_frame, l2cap_frame->size-1);
 
 	if (!l2cap_frame_get_u8(&tmp_frame, &hdr.fcs))
-- 
2.31.1.607.g51e8a6a459-goog