Thank you Em appreciate the response. I understand and totally agree, providing a valid reproduction for a DOS attack is problematic.
Let me may be ask two very specific questions : ( i am trying to really get to the bottom of this CVE and hopefully figure out in more details how the potential fix , fixes the issue) 1. The CVE says : e*mbedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms. * May i ask, exactly *which objects* are getting flipped from mutable to immutable. Given the lack of information in GHSA - this is what i am assuming. Do let me know if i correct, pls. the fields ( SmallSortedMap ie FieldSet<FieldDescriptor> in com.google.protobuf.DynamicMessage.Builder) are the ones getting flipped from mutable to immutable forms. 2. If the above is true, i am looking at fixed version 3.16.3, you can see fix commit has builder.setField(field, ((MessageLite.Builder) value).buildPartial()) <https://github.com/protocolbuffers/protobuf/commit/db7c17803320525722f45c1d26fc08bc41d1bf48#diff-eca77d4401894dba76fe6ed92f5ba8e6d0a7b17815b4df0d9ac41e26376223c3R417>. However based on my test, the buildPartial method calls the method fields.makeImmutable();, which ultimately wraps it in unmodifiableMap, however setField() method calls ensureIsMutable() which returns true, as in fields are mutable. The reason for my confusion is actually right there. Would appreciate any help in this regards. Somak. On Tuesday, July 22, 2025 at 9:05:00 PM UTC+5:30 Em Rauch wrote: > Sorry; unfortunately Google is not able to provide an explicit > reproduction case for the DOS attack in this case. > > Note that the DOS risks as described in the CVE do involve cases where > things may be structured in a way where they unfortunately end up converted > back and forth a very large number of times; there certainly are many cases > where even on vulnerable gencode + runtime that usage patterns which > were never sensitive to the issue, including where conversion may occur but > is sufficiently cheap that there is no DOS risks exposed from the > representation conversions. > > On Mon, Jul 21, 2025 at 1:06 PM 'Somak Dutta' via Protocol Buffers < > [email protected]> wrote: > >> Hello, >> >> *Question* : I am unsure how the fix commit provided fixes the >> vulnerability in question. Details below, if some one can please explain >> the actual fix for the vuln, would be great. >> >> Reaching out to talk about the potential fix done for vulnerability >> https://github.com/advisories/GHSA-4gg5-vx3j-xwc7 or >> https://github.com/advisories/GHSA-g5ww-5jh7-63cx in version 3.16.3 , >> as part of the fix commit >> https://github.com/protocolbuffers/protobuf/commit/db7c17803320525722f45c1d26fc08bc41d1bf48 >> >> The vulnerability speaks about - >> " >> *A parsing issue similar to CVE-2022-3171 >> <https://github.com/advisories/GHSA-h4h5-3hr4-j3g2>, but with Message-Type >> Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, >> 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing >> multiple instances of non-repeated embedded messages with repeated or >> unknown fields causes objects to be converted back-n-forth between mutable >> and immutable forms, resulting in potentially long garbage collection >> pauses. We recommend updating to the versions mentioned above.* >> " >> >> It speaks mostly about, how if fields are marked as immutable, messages >> would need to be cloned, leading to more object creation and thereby long >> garbage pauses. >> We can see the impact of it here >> <https://github.com/protocolbuffers/protobuf/blob/v3.16.3/java/core/src/main/java/com/google/protobuf/DynamicMessage.java#L659> >> As per the message in the fix commit , " Change the Lite runtime to >> prefer merging from the wireformat into mutable messages *rather than >> building *up a new immutable object before merging. This way results in >> fewer allocations and copy operations." >> >> >> *Doubt:* >> I tried generating a message structure that can potentially reproduce >> the vulnerability, however based on my debugging, fields are always mutable >> in fixed version 3.16.3 , as well as lower versions. >> >> The problem i see is, the fields are always remaining mutable, meaning >> there is no flipping between mutable and immutable forms as mentioned in >> the vulnerability. I am not sure if its my test thats flawed, hence >> reaching out for help. >> >> Attaching test case, and test data structure. >> >> Thank you and Regards, >> Somak >> >> >> >> >> *Confidentiality Notice: This email and any attachments are confidential >> and intended solely for the use of the individual or entity to whom they >> are addressed. If you have received this email in error, please notify the >> sender immediately and delete it from your system. Unauthorized use, >> disclosure, or copying of this email or its contents is strictly >> prohibited.* >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Protocol Buffers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/protobuf/74d07507-8712-42d0-ac4f-2756bf5f2ab9n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/protobuf/74d07507-8712-42d0-ac4f-2756bf5f2ab9n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- **Confidentiality Notice: *This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the sender immediately and delete it from your system. Unauthorized use, disclosure, or copying of this email or its contents is strictly prohibited.* -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/protobuf/4cf86ff8-0d3f-4602-995b-eda0225b4d86n%40googlegroups.com.
