commit 0a2b39bfdc3144e95b32dcfd9f95e0a6d40eb901
author Joshua Haberman <haberman@google.com> Sat Sep 13 10:07:27 2025 -0700
committer Copybara-Service <copybara-worker@google.com> Sat Sep 13 10:10:50 2025 -0700
tree 844851074fbd9e0f343847d203817959b014a7be
parent 13117196da16e4299ddabbb60932a3e605c260fb

Fixed a fuzz bug by properly rejecting MiniTables with improper map fields at schema creation time.

Specifically, any enum used as a map value must contain a zero value.  Before we were not enforcing this, which could lead to the wrong enum value being serialized if we parsed a map entry with no value.

This change should have no real effect in prod, because protoc will already reject enum fields that break this invariant.

PiperOrigin-RevId: 806683268

upb/mini_descriptor/link.c

diff --git a/upb/mini_descriptor/link.c b/upb/mini_descriptor/link.c
index 97cd55d..8c2ffae 100644
--- a/upb/mini_descriptor/link.c
+++ b/upb/mini_descriptor/link.c
@@ -74,6 +74,17 @@
     return false;
   }
 
+  if ((table->UPB_PRIVATE(ext) & kUpb_ExtMode_IsMapEntry) &&
+      !upb_MiniTableEnum_CheckValue(sub, 0)) {
+    // An enum used in a map must include 0 as a value.  This matches a check
+    // performed in protoc ("Enum value in map must define 0 as the first
+    // value").  Protoc should ensure that we never get here.
+    //
+    // This ends up being important if we receive wire messages where a map
+    // entry omits the value (and thus defaults to 0).
+    return false;
+  }
+
   upb_MiniTableSub* table_sub =
       (void*)&table->UPB_PRIVATE(subs)[field->UPB_PRIVATE(submsg_index)];
   *table_sub = upb_MiniTableSub_FromEnum(sub);