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

race in setting OpDebug ns can cause invalid BSON to be returned from currentOp command

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical - P2
    • Resolution: Fixed
    • Affects Version/s: 3.1.4
    • Fix Version/s: 3.1.5
    • Component/s: Internal Code
    • Labels:
    • Backwards Compatibility:
      Minor Change
    • Operating System:
      ALL
    • Steps To Reproduce:
      Hide

      run evalc.js in a loop, or run basic or basicPlus.js

      Show
      run evalc.js in a loop, or run basic or basicPlus.js
    • Sprint:
      Platform 5 06/26/16
    • Linked BF Score:
      0

      Description

      The currentOp command calls CurOp::reportState to report the state of an operation.

      CurOp::reportState will fill in the "ns" field of its passed BSONObjBuilder with it's _ns field OR the ns field of its OpDebug member if _ns is not set.

      builder->append("ns", !_ns.empty() ? _ns : _debug.ns);
      

      Unfortunately, access to the OpDebug field is not synchronized. As such, the "ns" field of an operation object returned in the currentOp command can contain garbage data. When the garbage data does not end with a null byte, this can resullt in invalid BSON being returned to the client.

      As part of OP_COMMAND work, the shell will now validate BSON in command responses from the server, which uncovered this issue.

      For example - here are the raw bytes from a problematic currentOp response:

      "\xb2\x02\x00\x00\x04inprog\x00\x99\x02\x00\x00\x030\x00q\x01\x00\x00\x02desc\x00\x07\x00\x00\x00conn54\x00\x02threadId\x00\r\x00\x00\x007ff2a6112700\x00\x10connectionId\x006\x00\x00\x00\x02client\x00\x10\x00\x$
      0\x00127.0.0.1:58533\x00\x08active\x00\x01\x10opid\x00a\xed\x03\x00\x02op\x00\x06\x00\x00\x00query\x00\x02ns\x00\x01\x00\x00\x00t\x03query\x00\x05\x00\x00\x00\x00\x10numYields\x00\x00\x00\x00\x00\x03locks\x00\x$
      3\x00\x00\x00\x02Global\x00\x02\x00\x00\x00W\x00\x00\x08waitingForLock\x00\x00\x03lockStats\x00\x97\x00\x00\x00\x03Global\x00.\x00\x00\x00\x03acquireCount\x00\x1b\x00\x00\x00\x12r\x00\x03\x00\x00\x00\x00\x00\x00
      \x00\x12W\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03Database\x00#\x00\x00\x00\x03acquireCount\x00\x10\x00\x00\x00\x12r\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03Collection\x00#\x00\x00\x00\x03acquireCo
      unt\x00\x10\x00\x00\x00\x12r\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x031\x00\x1d\x01\x00\x00\x02desc\x00\x07\x00\x00\x00conn55\x00\x02threadId\x00\r\x00\x00\x007ff2a6238700\x00\x10connectionId\x007\
      x00\x00\x00\x02client\x00\x10\x00\x00\x00127.0.0.1:58534\x00\x08active\x00\x01\x10opid\x000\xee\x03\x00\x10secs_running\x00\x00\x00\x00\x00\x12microsecs_running\x00'\x00\x00\x00\x00\x00\x00\x00\x02op\x00\x08\x00
      \x00\x00command\x00\x02ns\x00\x0b\x00\x00\x00admin.$cmd\x00\x03query\x00\x18\x00\x00\x00\x01currentOp\x00\x00\x00\x00\x00\x00\x00\xf0?\x00\x10numYields\x00\x00\x00\x00\x00\x03locks\x00\x05\x00\x00\x00\x00\x08wai
      tingForLock\x00\x00\x03lockStats\x00\x05\x00\x00\x00\x00\x00\x00\x01ok\x00\x00\x00\x00\x00\x00\x00\xf0?\x00"
      

      Problematic part (offsets 148 through 155)

      ns\x00\x01\x00\x00\x00t\x03query
      

      at offset 154, the content of an 'ns' field has a 't' (0x74) instead of a trailing null before the start of the next element.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              adam.midvidy Adam Midvidy
              Reporter:
              adam.midvidy Adam Midvidy
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: