libbluetooth.so_new
libbluetooth.so_old

I have two binaries, and I'd like to study CVE-2023-21273. The following patch fixes this CVE:

diff
diff --git a/system/stack/sdp/sdp_db.cc b/system/stack/sdp/sdp_db.cc
index 297b312..acef4a5 100644
--- a/system/stack/sdp/sdp_db.cc
+++ b/system/stack/sdp/sdp_db.cc
@@ -355,6 +355,11 @@
   uint16_t xx, yy, zz;
   tSDP_RECORD* p_rec = &sdp_cb.server_db.record[0];
 
+  if (p_val == nullptr) {
+    SDP_TRACE_WARNING("Trying to add attribute with p_val == nullptr, skipped");
+    return (false);
+  }
+
   if (sdp_cb.trace_level >= BT_TRACE_LEVEL_DEBUG) {
     if ((attr_type == UINT_DESC_TYPE) ||
         (attr_type == TWO_COMP_INT_DESC_TYPE) ||
@@ -402,6 +407,13 @@
     if (p_rec->record_handle == handle) {
       tSDP_ATTRIBUTE* p_attr = &p_rec->attribute[0];
 
+      // error out early, no need to look up
+      if (p_rec->free_pad_ptr >= SDP_MAX_PAD_LEN) {
+        SDP_TRACE_ERROR("the free pad for SDP record with handle %d is "
+                        "full, skip adding the attribute", handle);
+        return (false);
+      }
+
       /* Found the record. Now, see if the attribute already exists */
       for (xx = 0; xx < p_rec->num_attributes; xx++, p_attr++) {
         /* The attribute exists. replace it */
@@ -440,15 +452,13 @@
           attr_len = 0;
       }
 
-      if ((attr_len > 0) && (p_val != 0)) {
+      if (attr_len > 0) {
         p_attr->len = attr_len;
         memcpy(&p_rec->attr_pad[p_rec->free_pad_ptr], p_val, (size_t)attr_len);
         p_attr->value_ptr = &p_rec->attr_pad[p_rec->free_pad_ptr];
         p_rec->free_pad_ptr += attr_len;
-      } else if ((attr_len == 0 &&
-                  p_attr->len !=
-                      0) || /* if truncate to 0 length, simply don't add */
-                 p_val == 0) {
+      } else if (attr_len == 0 && p_attr->len != 0) {
+        /* if truncate to 0 length, simply don't add */
         SDP_TRACE_ERROR(
             "SDP_AddAttribute fail, length exceed maximum: ID %d: attr_len:%d ",
             attr_id, attr_len);

libbluetooth.so_new is a bluetooth driver that has already fixed this CVE. The corresponding function that was affected was at 0x4f2bf0. Now I'm given an unknown binary libbluetooth.so_old. Can you help me analyze if the vulnerability exisits in this unknown binary?

Tool call: get_similar_function with args: {"function":"0x4f2bf0"} succeeded

Tool call: decompile_function_by_address with args: {"address":"0x4f2bf0"} succeeded

Tool call: decompile_function_by_address with args: {"address":"0x4f2858"} succeeded

I diff’d the SDP_AddAttribute implementations in the two .so’s and confirmed the key guard added by the patch is missing in the “old” library.

Specifically, in the new build (at 0x4f2bf0) you see:

c
  if (p_val == nullptr) {
    SDP_TRACE_WARNING("…p_val==nullptr, skipped");
    return false;
  }
  …
  if (p_rec->free_pad_ptr >= SDP_MAX_PAD_LEN) {
    SDP_TRACE_ERROR("free pad full, skip adding attribute");
    return false;
  }
  …
  if (attr_len > 0) {
    …
  } else if (attr_len == 0 && p_attr->len != 0) {
    // truncate‐to‐zero case only
    SDP_TRACE_ERROR("…length exceed maximum…");
    return false;
  }

In the old build (at 0x4f2858) none of those early returns on p_val == NULL or free‐pad/full‐pad checks appear. Worse, the old version immediately dereferences p_val in some debug‐logging branches (*p_val, p_val[length-1]) without ever null‐checking it. That means if you ever call SDP_AddAttribute with a zero pointer you can crash or corrupt memory.

Conclusion: libbluetooth.so_old (0x4f2858) is vulnerable to CVE-2023-21273. You’ll want to upgrade to the “new” build or back‐port the same null checks.