0

Managed to get signed length value to memcpy()

02-16 01:44:49.096  6423  6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch reassemble_and_dispatch
02-16 01:44:49.096  6423  6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch partial_packet->offset 40 packet->len 304 HCI_ACL_PREAMBLE_SIZE 4  
02-16 01:44:49.096  6423  6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch projected_offset 340 partial_packet->len 41  
02-16 01:44:49.096  6423  6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch got packet which would exceed expected length of 41. Truncating.
02-16 01:44:49.096  6423  6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch memcpy packet->len 1 packet->offset 4 expr -3  
02-16 01:44:49.096  6423  6471 W bt_hci_packet_fragmenter: reassemble_and_dispatch partial_packet->data 0xacb14580 partial_packet->data + partial_packet->offset 0xacb145a8  packet->data 0xa553e110 packet->data + packet->offset 0xa553e114  
02-16 01:44:49.097  6423  6469 W bt_hci_packet_fragmenter: fragment_and_dispatch fragment_and_dispatch

In the example above, with a memcpy size of -3, this value is interpreted as an unsigned integer (4294967293) and the memcpy continues until there is a page fault due to unmapped memory and the process should terminate.

My phone is 32 bits, maybe that's why. Mobile is Samsung S3 Neo+. Using jemalloc at least at Android 9.0 tests. Device is ARM arch.

Any ideas why memcpy does not crash the process here?

memcpy(partial_packet->data + partial_packet->offset,
             packet->data + packet->offset, packet->len - packet->offset);

https://android.googlesource.com/platform/system/bt/+/3cb7149d8fed2d7d77ceaa95bf845224c4db3baf/hci/src/packet_fragmenter.cc#229

More info also here:

https://github.com/marcinguy/CVE-2020-0022

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.