Summary
In rfcomm_handle_data
in subsys/bluetooth/host/rfcomm.c
, the buf->len
is not verified, leading to undefined behavior in the subsequent net_buf_pull_u8(buf)
operation.
Details
The function rfcomm_handle_data
is called from rfcomm_recv
.
Although there is an initial check to ensure buf->len
is larger than sizeof(*hdr) + 1
:
if (buf->len < (sizeof(*hdr) + 1)) {
BT_ERR("Too small RFCOMM Frame");
return 0;
}
there are no additional checks on the remaining size of buf
.
If buf
is exactly sizeof(*hdr) + 1
, it will cause a crash in executing net_buf_pull_u8(buf)
in the following code within rfcomm_handle_data
:
if (pf == BT_RFCOMM_PF_UIH_CREDIT) {
rfcomm_dlc_tx_give_credits(dlc, net_buf_pull_u8(buf));
}
I believe there should be proper length check of buf
.
PoC
buf
given to rfcomm_recv
could be like ff ff 0a 30
.
Impact
Result of exploitation could lead to instability (i.e., crash) or denial of service attacks.
Patches
main: #74640
For more information
If you have any questions or comments about this advisory:
embargo: 2024-09-05
Summary
In
rfcomm_handle_data
insubsys/bluetooth/host/rfcomm.c
, thebuf->len
is not verified, leading to undefined behavior in the subsequentnet_buf_pull_u8(buf)
operation.Details
The function
rfcomm_handle_data
is called fromrfcomm_recv
.Although there is an initial check to ensure
buf->len
is larger thansizeof(*hdr) + 1
:there are no additional checks on the remaining size of
buf
.If
buf
is exactlysizeof(*hdr) + 1
, it will cause a crash in executingnet_buf_pull_u8(buf)
in the following code withinrfcomm_handle_data
:I believe there should be proper length check of
buf
.PoC
buf
given torfcomm_recv
could be likeff ff 0a 30
.Impact
Result of exploitation could lead to instability (i.e., crash) or denial of service attacks.
Patches
main: #74640
For more information
If you have any questions or comments about this advisory:
embargo: 2024-09-05