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

NamespaceString's no-arguments constructor results in an improperly initialized object, can later cause segfault

    • Fully Compatible
    • ALL
    • v3.4, v3.2, v3.0
    • Query 2017-10-23
    • 0

      The NamespaceString class represents a fully-qualified collection name, such as "myDb.myCollection". Underneath the hood, it consists of a std::string (which owns the string itself), and a size_t giving the index of the '.' character:

      https://github.com/mongodb/mongo/blob/b1d1b244c73a726c0c6708cf1cb196079f570414/src/mongo/db/namespace_string.h#L395-L396

      It also supports a no-arguments constructor, which can be used to initialize a NamespaceString in an empty state. The intended design is that in the empty state the _ns member is the empty string, and the _dotIndex member is equal to std::string::npos. However, the constructor improperly initializes the _dotIndex member to zero:

      https://github.com/mongodb/mongo/blob/b1d1b244c73a726c0c6708cf1cb196079f570414/src/mongo/db/namespace_string-inl.h#L121

      This is wrong, because the NamespaceString::db() and NamespaceString::coll() methods check for std::string::npos in order to make sure that they correctly handle the empty state:

      https://github.com/mongodb/mongo/blob/b1d1b244c73a726c0c6708cf1cb196079f570414/src/mongo/db/namespace_string-inl.h#L34-L41

      If the coll() method is called on an empty NamespaceString, it will end up returning a corrupt StringData. Specifically, it looks like we end up computing the length of the string as -1, then assigning this value to a size_t, resulting in a large positive length value for the string (despite the memory not having been allocated to hold such a long string).

      There are few code paths which actually call NamespaceString::coll() on an empty namespace string. At the very least, this has been observed to cause a crash when a globally-owned cursor is killed on a system that is configured to use auditing.

            Assignee:
            david.storch@mongodb.com David Storch
            Reporter:
            david.storch@mongodb.com David Storch
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: