Summary

libbson's bson-as-json serialization tries to limit recursion depth to 200, in order to limit the otherwise hazardous stack memory usage and algorithmic overhead that would result from unbounded recursion. This limit is rendered ineffective by nested documents within legacy code-with-scope scopes. Documents of less than 1MB can be constructed that use all available stack space on a default php interpreter. With unlimited stack space, a full 16MB worst-case document takes over ten minutes of CPU time and 1GB of RAM to serialize.

Notably the server-side equivalent (bson_validate.cpp) does NOT contain the same bug, so this is not possible to trigger via any BSON document that could be stored inside MongoDB, only by other types of documents that are potentially read from an untrusted source.

Environment

Issue is not platform-specific, but the ramifications will be. I tested this on Linux (WSL2) especially in the php driver, with a default 8MB stack and with a stack increased by ulimit.

Tested on driver version 1.28.0 and on latest master. A mongod connection is not required, this issue is in libbson.

How to Reproduce

Example is attached, written in PHP. See the comments, it will generate a worst-case document of any requested size.

Additional Background

I don't think we have a clear broadly applicable specification for the allowed BSON recursion depth and how/where it should be enforced; that would be good to establish.

It is additionally feasible to rewrite bson-as-json serialization to avoid recursion entirely, and/or to have a stack overhead about 100x lower. These solutions would allow bson-as-json serialization to efficiently handle deeply nested documents, but without guidance toward consistent support for deeply nested documents across mongodb this would have limited use.