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:   Wed, 12 May 2021 10:36:06 +0800
Message-Id: <20210512103550.Bluez.v2.1.I6d2ab6907d9a84fa62ac8a39daef5bef7ff545d5@changeid>
Mime-Version: 1.0
Subject: [Bluez PATCH v2] 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
---

Changes in v2:
- Rewrite the if statement

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

diff --git a/monitor/rfcomm.c b/monitor/rfcomm.c
index 9b88a3440e31..3eb19faf0297 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)
+		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