Branch: refs/heads/master Home: https://github.com/bluez/bluez Commit: 00eea35722b73d922472c7fba006f711690ce195 https://github.com/bluez/bluez/commit/00eea35722b73d922472c7fba006f711690ce195 Author: Oliver Chang <ochang@xxxxxxxxxx> Date: 2025-08-19 (Tue, 19 Aug 2025) Changed paths: M src/sdp-xml.c Log Message: ----------- Fix heap-buffer-overflow in sdp_xml.c:compute_seq_size https://issues.oss-fuzz.com/issues/42516062 https://oss-fuzz.com/testcase-detail/5896441415729152 This can be triggered by using an input of `<sequence><foo/><text/></sequence>` against the harness in https://github.com/google/oss-fuzz/blob/master/projects/bluez/fuzz_xml.c The root cause of the heap-buffer-overflow was incorrect stack management in the SDP XML parser (element_end function) that led to type confusion. When an XML element failed to parse (e.g., an unrecognized tag like <foo/>), its corresponding entry was left on the parser stack because the we returned early if data was NULL. With the input <sequence><foo/><text/></sequence>, <foo/> failed parsing and remained on the stack with a NULL data. Then <text/> was parsed and also remained on the stack because it's only popped if ctx_data->stack_head->next->data != NULL. When </sequence> was encountered, the parser then mistakenly used the data from <text/> (which was now at the top of the stack) as the sequence data. This led to a type confusion: the TEXT data's string pointer (val.str) was interpreted as a sequence pointer (val.dataseq). This pointer pointed to a 1-byte allocation (for the empty string). The code then tried to dereference this pointer as an sdp_data_t struct to calculate the sequence size, leading to the out-of-bounds read. To fix this, in element_end, ensure that the stack is popped even if the element's data failed to parse. This prevents the stack desynchronization. To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
