OK, I think I got it the condition Below is Mobile (Android) Bluetooth subsystem log: 02-12 22:33:26.928 2416 2461 W bt_hci_packet_fragmenter: reassemble_and_dispatch reassemble_and_dispatch 02-12 22:33:26.928 2416 2461 W bt_hci_packet_fragmenter: reassemble_and_dispatch partial_packet->offset 21 packet->len 683 HCI_ACL_PREAMBLE_SIZE 4 02-12 22:33:26.928 2416 2461 W bt_hci_packet_fragmenter: reassemble_and_dispatch projected_offset 700 partial_packet->len 209 02-12 22:33:26.928 2416 2461 W bt_hci_packet_fragmenter: reassemble_and_dispatch got packet which would exceed expected length of 209. Truncating. 02-12 22:33:26.928 2416 2461 W bt_hci_packet_fragmenter: reassemble_and_dispatch memcpy packet->len 188 packet->offset 4 expr 184 02-12 22:33:26.929 2416 2460 W bt_hci_packet_fragmenter: fragment_and_dispatch fragment_and_dispatch Still working on crashing the process, maybe this is due to memory allocator (possibly jemalloc) Thanks, Marcin On Wed, Feb 12, 2020 at 12:20 PM Matias Karhumaa <matias.karhumaa@xxxxxxxxx> wrote: > > Hi Marcin, > > Most obvious question first: are you testing against device that does not have the fix for this vulnerability yet? > > There are still huge amount of devices out there without access to the fix. This is why full technical report has not been published yet. > > Best regards, > Matias Karhumaa > > ke 12. helmik. 2020 klo 12.38 Marcin Kozlowski <marcinguy@xxxxxxxxx> kirjoitti: >> >> Hi list, >> >> Hope is ok to ask here. Can somebody give some insight when this can >> happen: https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf/hci/src/packet_fragmenter.cc#220 >> >> Tried sending fragmented GAP ACL L2CAP packets via HCI, but I cannot >> imagine how this condition (in packet_fragmenter.cc#220) can be met: >> >> https://stackoverflow.com/questions/60116790/sending-gap-acl-l2cap-data-packets >> >> Anybody knows? Can shed some more light on this? >> >> Thanks,
