Dear Paul, > Thank you for the patch. For the summary, I’d use imperative mood and do > not add a dot/period at the end: > > Fix heap-buffer-overflow in `compute_seq_size` Thank you for the suggestion, I will make sure to do this for future commit summaries. What do I need to do here in this instance to make this change? Do I need to resend the patch with a new subject? > The last comment says: > > > This issue was migrated from crbug.com/oss-fuzz/51480?no_tracker_redirect=1 > > But that URL gives *Page Not Found*. Apologies for that. We had a migration from a legacy issue tracking system, and that legacy system has since been turned down. > > > https://oss-fuzz.com/testcase-detail/5896441415729152 > > I am unable to access this without logging in. The emails that can access this are the ones listed here: https://github.com/google/oss-fuzz/blob/ef1c29822d62470fb6b0af7b73412d245d05f80c/projects/bluez/project.yaml#L3. Are there any other emails we should add? These emails also receive automatic email notifications whenever OSS-Fuzz finds a new bug. Note though, to view the oss-fuzz.com report, you'll need either a GitHub or Google account associated with the email. https://oss-fuzz.com/testcase-detail/5896441415729152 contains the ASan stacktrace, which I've also included in my earlier email. > > With your patch and the test case, what error is logged now? There is still a memory leak detected by ASan that's unrelated to this patch/issue, but the buffer overflow report is gone. I don't see any other log messages, including the ones I added in the patch. This is likely because `sdp_xml_parse_record` calls `g_markup_parse_context_parse` with a NULL `error`, so any parsing errors encountered are not propagated. ``` if (g_markup_parse_context_parse(ctx, data, size, NULL) == FALSE) { ``` It seems useful to enable propagating of parsing errors to `sdp_xml_parse_record` in the future. But if preferred, I can remove the logging I added since they're not going anywhere right now. Kind regards, Oliver
