-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Fully Compatible
-
ALL
-
-
Service Arch 2022-2-07, Service Arch 2022-2-21
-
64
-
3
Scenario
On a debug build of a MongoDB cluster:
- A commandObj passed into runCommandWithReadPreferenceSecondary here has the $readPreference field specified at the top level.
- The commandObj is wrapped in a query object here, meaning that the original $readPreference object is now at the second level.
- The function checks here if the top level of the object has the $readPreference field (it does not).
- The function adds a $readPreference field – the BSONObj now has two $readPreference fields.
- rpc::upconvertRequest() adds the $readPreference field from the query object to the top level erroneously.
- The shell crashes when attempting to send the commandObj, because the $readPreference field was duplicated.
There's reason to believe this could also happen with an old driver sending OP_QUERY messages and specifying a readPreference on both the query object and the top-level, but I wasn't able to reproduce it easily.
Suggested fix
Throw ErrorCodes::InvalidOptions in rpc::upconvertRequest() if there is a $readPreference specified in both the query object and the top level.