All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Chang <noreply@github.com>
To: linux-bluetooth@vger.kernel.org
Subject: [bluez/bluez] 1663ae: Fix heap-buffer-overflow in sdp_xml.c:compute_seq_...
Date: Wed, 13 Aug 2025 03:43:29 -0700	[thread overview]
Message-ID: <bluez/bluez/push/refs/heads/990970/000000-1663ae@github.com> (raw)

  Branch: refs/heads/990970
  Home:   https://github.com/bluez/bluez
  Commit: 1663ae444fa2a670d2e7cc2fdfc3eb3e057621e6
      https://github.com/bluez/bluez/commit/1663ae444fa2a670d2e7cc2fdfc3eb3e057621e6
  Author: Oliver Chang <ochang@google.com>
  Date:   2025-08-13 (Wed, 13 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

                 reply	other threads:[~2025-08-13 10:43 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bluez/bluez/push/refs/heads/990970/000000-1663ae@github.com \
    --to=noreply@github.com \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.