Linux bluetooth development
 help / color / mirror / Atom feed
* [PATCH 0/2] Bluetooth: HIDP: validate short receive frames
@ 2026-07-23  3:28 Sangho Lee
  2026-07-23  3:28 ` [PATCH 1/2] Bluetooth: HIDP: reject frames without a transaction header Sangho Lee
  2026-07-23  3:28 ` [PATCH 2/2] Bluetooth: HIDP: validate numbered report payloads Sangho Lee
  0 siblings, 2 replies; 4+ messages in thread
From: Sangho Lee @ 2026-07-23  3:28 UTC (permalink / raw)
  To: luiz.dentz, marcel, linux-bluetooth
  Cc: jikos, alan, padovan, linux-kernel, stable, kudo3228

The HIDP control and interrupt receive paths assume that every L2CAP SDU
contains a transaction header. The raw-report return path also assumes that
a numbered DATA response contains a report ID. Both assumptions allow a
connected peer to make HIDP consume data beyond the logical skb boundary.

The tests used two BlueZ 5.87 btvirt BR/EDR controllers, real L2CAP PSM
0x11/0x13 channels, HIDPCONNADD, and HIDIOCGFEATURE on bluetooth.git at
df541cd485ff. The series also applies without changes to bluetooth-next at
6f55ad8fb0ac.

On the unpatched KMSAN kernel, an empty control SDU produced two
uninitialized-value reports in hidp_session_run(), an empty interrupt SDU
produced one, and a DATA | FEATURE header without a report payload produced
one. Patch 1 removed only the first three reports; applying both patches
removed all four.

The tests also placed a controlled byte after the declared L2CAP PDU. A
trailing 0x15 after a zero-length control SDU was interpreted as virtual
cable unplug and terminated the unpatched HIDP session. The patched session
rejected the frame and completed a later feature report request. A trailing
report ID after a header-only DATA response made the unpatched raw-report
request complete with a zero-byte result; the patched kernel rejected it.

Finally, each path received 10,000 malformed responses on KASAN and UBSAN
kernels. No KASAN, UBSAN, Oops, or kernel BUG was observed. The KASAN runs
and all patched UBSAN runs accepted a subsequent valid feature report. The
unpatched UBSAN numbered-report run instead completed requests from queued
short responses, which further exposed the missing payload validation. No
information disclosure or code execution is claimed.

Sangho Lee (2):
  Bluetooth: HIDP: reject frames without a transaction header
  Bluetooth: HIDP: validate numbered report payloads

 net/bluetooth/hidp/core.c | 30 ++++++++++++++++++------------
 1 file changed, 18 insertions(+), 12 deletions(-)

-- 
2.43.0

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-07-23  4:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-23  3:28 [PATCH 0/2] Bluetooth: HIDP: validate short receive frames Sangho Lee
2026-07-23  3:28 ` [PATCH 1/2] Bluetooth: HIDP: reject frames without a transaction header Sangho Lee
2026-07-23  4:58   ` Bluetooth: HIDP: validate short receive frames bluez.test.bot
2026-07-23  3:28 ` [PATCH 2/2] Bluetooth: HIDP: validate numbered report payloads Sangho Lee

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox