MongoDB Resource Locking Mechanism Vulnerability Leading to Denial-of-Service

A vulnerability exists in the MongoDB server's internal locking mechanism, where collections may unintentionally collide in their resource encoding. This collision can lead to conflicting locks, causing unavailability between collections. The issue arises because the lock manager relies on ResourceIds to manage lock acquisitions, and an adversary could exploit this by forcing constant MODE_X lock acquisitions on a collection that shares a ResourceId with an internal collection, such as the oplog. This exploitation could disrupt availability for other collections by interfering with their lock acquisition processes.

Impact

Exploitation of this vulnerability can cause certain collections to become unavailable, disrupting normal database operations.

Reproduction

To reproduce this vulnerability, an adversary can identify a collection that shares the same ResourceId as an internal collection like the oplog. Once identified, the adversary can perform index DDL operations that require MODE_X locks on the targeted collection. This will cause the internal collection to become unavailable by preventing it from acquiring necessary intent locks. The vulnerability can be further exploited by creating a large collection and continuously building indexes on it, which would exacerbate the disruption of service for other collections.

Remediation

To address this vulnerability, MongoDB has released patches in versions 8.3.0-rc0, 8.2.4, 8.0.18, and 7.0.29. Users should upgrade to one of these versions.