Uploaded image for project: 'Drivers'
  1. Drivers
  2. DRIVERS-2651

Add decimal128 clamped zeros tests with very large exponents

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Unknown Unknown
    • None
    • Component/s: Decimal128
    • None
    • Not Needed
    • $i18n.getText("admin.common.words.hide")
      Key Status/Resolution FixVersion
      PHPC-2259 Fixed 1.17.0
      $i18n.getText("admin.common.words.show")
      #scriptField, #scriptField *{ border: 1px solid black; } #scriptField{ border-collapse: collapse; } #scriptField td { text-align: center; /* Center-align text in table cells */ } #scriptField td.key { text-align: left; /* Left-align text in the Key column */ } #scriptField a { text-decoration: none; /* Remove underlines from links */ border: none; /* Remove border from links */ } /* Add green background color to cells with FixVersion */ #scriptField td.hasFixVersion { background-color: #00FF00; /* Green color code */ } /* Center-align the first row headers */ #scriptField th { text-align: center; } Key Status/Resolution FixVersion PHPC-2259 Fixed 1.17.0

      Summary

      The Go driver recently fixed a bug that could cause an effectively infinite loop when parsing decimal128 Extended JSON values that contain extremely large positive or negative integers (see GODRIVER-1519). We should add tests to the BSON corpus that check for similar bugs in other drivers.

      Motivation

      Who is the affected end user?

      Customers who want to parse decimal128 values from Extended JSON strings or other strings.

      How does this affect the end user?

      The parser may hang indefinitely or behave unexpectedly when clamping certain values with very large positive or negative exponents.

      How likely is it that this problem or use case will occur?

      The problem only occurs when parsing specific strings as decimal128. Examples include:

      • "0E999999999999"
      • "0E-999999999999"

      An Extended JSON marshaler that passes the BSON test corpus should never generate the problematic strings, so the problem is only likely to happen if a customer uses the string-to-decimal128 parser to parse user-provided input.

      If the problem does occur, what are the consequences and how severe are they?

      The customer's application could hang. If the customer's application parses user-provided input, it could expose the customer to a denial-of-service attack.

      Is this issue urgent?

      No.

      Is this ticket required by a downstream team?

      No.

      Is this ticket only for tests?

      Yes.

      Acceptance Criteria

      • Add decimal128 Extended JSON parse tests for clamped zeros with very large exponents.

            Assignee:
            matt.dale@mongodb.com Matt Dale
            Reporter:
            matt.dale@mongodb.com Matt Dale
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: