Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-73534

Serialization of 'sbe::TypeTags::ArraySet' to 'KeyString' can segfault

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 6.3.0-rc0, 6.0.5
    • Affects Version/s: None
    • Component/s: Query Execution
    • Labels:
    • Fully Compatible
    • ALL
    • v6.0
    • QE 2023-02-06
    • 164

      This code is incorrect:


      In the case that the input tag indicates that the value is type Array, everything works as expected. When the value is an ArraySet, however, this code leads to undefined behavior. I've seen it consistently crash the server with a segfault in practice.

      The problem is that it calls getArrayView() on a value of type Array. This ends up interpreting the value as a pointer to an Array object when the value's actual runtime type is ArraySet. As soon as we try to access a data member of the pointed-to object, which happens here, we crash.

      The buggy function is used for spilling to disk in SBE's HashAggStage and HashLookupStage. Therefore, the crash can happen if we ever decide to spill an entry in the hash table whose key contains a value of type ArraySet. This is a somewhat unusual situation, since it requires the following:

      1. A $group or $lookup that needs to spill at runtime.
      2. The $group or $lookup must be pushed down to SBE.
      3. The query must be such that an ArraySet becomes a key in the hash table. This is presumably an unusual use of MQL's set arithmetic operators.

      This is a latent issue that was discovered our generational agg fuzzer. It was exposed due to the changes from SERVER-70395, but I believe that it affects all 6.0.x and 6.2.x versions. The reason we found it is that SERVER-70395 made a change to artificially increase the likelihood of spilling in debug builds. For this reason, as soon as SERVER-70395 was merged we started seeing the fuzzer cause this crash on debug builds only.

            david.storch@mongodb.com David Storch
            david.storch@mongodb.com David Storch
            0 Vote for this issue
            8 Start watching this issue