A memory management bug in code that tracks updates to documents can cause undefined behavior; including failed operations, process crashes, and in-memory corruption of data that may be persisted to disk.
The code returns an un-owned object, which can be freed and re-used even though the object is still referenced. If this memory is accessed after it is re-used, the contents may cause a MongoDB server to incorrectly write to any memory used by the mongod process.
Even though serious impact is unlikely, all MongoDB 4.2.0 replica sets are considered vulnerable.
The most likely impact is failed operations with BSONElement: bad type error message in the mongod logs or in responses to clients. Another common failure mode is a process crash with BSONElement: bad type or Invalid access errors in the mongod logs. However, in-memory and on-disk corruption of documents are technically possible.
The risk of triggering the bug in an impactful way goes up with the use of features that rely on the bugged code and in scenarios that require freeing and reusing memory frequently. This includes:
- the use of retryable writes, transactions, and change streams
- sharded collection chunk migrations
- high cache pressure (as measured by cache in/out and cache page eviction metrics)
- frequent replica set failovers during periods of replication lag
Upgrading to 4.2.1 corrects the bug. It is possible to reduce risk by addressing the risk factors described above, but because of the potential impact we strongly recommend upgrading from 4.2.0 to 4.2.1 immediately.
MongoDB 4.2.0. Earlier versions of MongoDB are not affected.
TransactionHistoryIterator::next() retrieves an unowned BSONObj from the call to PlanExecutor::getNext(). This is problematic because callers may save the resulting object and call next() several times without taking ownership (making a copy) first. This results in a bugs where an unowned BSONObj can point to freed or overwritten memory.