[SERVER-68309] Investigate for unsafe narrowing conversions Created: 26/Jul/22  Updated: 17/Jan/23  Resolved: 22/Aug/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Dan Larkin-York Assignee: Dan Larkin-York
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
Related
related to SERVER-68796 Shard key index selection may ignore ... Backlog
related to SERVER-68714 NaN issues in secure random number ge... Closed
related to SERVER-68715 NaN issues in Check/Wait pid in mongo... Closed
related to SERVER-68716 Fix undefined behavior in mongo::quer... Closed
related to SERVER-68740 Non-default-seeded hashed indexes not... Closed
related to SERVER-68781 Check value of hidden maxChunkSizeBytes Closed
related to SERVER-68836 Properly handle NaN and 0 in for LDAP... Closed
related to SERVER-68838 Explicitly check for NaN when setting... Closed
related to SERVER-68842 Passing in w: NaN for write concern i... Closed
related to SERVER-68920 Haystack geoSearch accepts NaN for 'l... Closed
related to SERVER-68922 $natural parser should be stricter (r... Closed
related to SERVER-69008 Narrowing conversion of size paramete... Closed
related to SERVER-69009 Narrowing conversion of timestamp com... Closed
related to SERVER-69036 Cluster dbStats command rounds premat... Closed
related to SERVER-68741 Remove code handling the non-default ... Closed
related to SERVER-68705 Refactor BSONElement API to avoid uns... Backlog
related to SERVER-68720 Safely parse minWireVersion and maxWi... Closed
is related to SERVER-26148 Commands should convert integers from... Backlog
Sprint: Execution Team 2022-08-08, Execution Team 2022-08-22
Participants:
Linked BF Score: 138

 Description   

BSONElement methods numberLong and  numberInt are used in dozens of places in the codebase, but it's not clear a priori which uses might actually be problematic. If used on a NumberDouble with a NaN value, they simply cast to the desired type, and this can result in undefined behavior that differs depending on the platform. If we know that the type of element is the matching type, then we can safely use these methods to extract it. In many cases, this holds, either where we've already checked the type explicitly, or we know that we constructed this value to be a specific type because it's for internal use and we have a schema for these documents. But in some cases, we probably are just using these methods mistakenly to deal with input of unknown type, when we should be checking the type explicitly.

We are already aware of some issues (e.g. SERVER-68359), but more problematic uses could still be lingering, and we should audit the codebase.


Generated at Thu Feb 08 06:10:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.