[SERVER-43350] The server crashes when trying to join collections ($ lookup with pipeline). Created: 16/Sep/19 Updated: 29/Oct/23 Resolved: 02/Oct/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Usability |
| Affects Version/s: | 3.6.14, 4.0.12, 4.2.0 |
| Fix Version/s: | 3.6.15, 4.0.13, 4.2.1, 4.3.1 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Alexey Glukhov | Assignee: | Bernard Gorman |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Backport Requested: |
v4.2, v4.0, v3.6
|
||||||||
| Sprint: | Query 2019-10-07 | ||||||||
| Participants: | |||||||||
| Description |
|
CVE-2019-2393 Title: Crash while joining collections with $lookup Description: CVSS score: Affected versions: CWE: CWE-416: Use After Free |
| Comments |
| Comment by Githook User [ 03/Oct/19 ] | |||||||||||||||||
|
Author: {'name': 'Bernard Gorman', 'username': 'gormanb', 'email': 'bernard.gorman@mongodb.com'}Message: (cherry picked from commit d6133a3a5464fac202f512b0310dfeb200c126f9) | |||||||||||||||||
| Comment by Githook User [ 02/Oct/19 ] | |||||||||||||||||
|
Author: {'name': 'Bernard Gorman', 'username': 'gormanb', 'email': 'bernard.gorman@mongodb.com'}Message: (cherry picked from commit d6133a3a5464fac202f512b0310dfeb200c126f9) | |||||||||||||||||
| Comment by Githook User [ 02/Oct/19 ] | |||||||||||||||||
|
Author: {'name': 'Bernard Gorman', 'username': 'gormanb', 'email': 'bernard.gorman@mongodb.com'}Message: (cherry picked from commit d6133a3a5464fac202f512b0310dfeb200c126f9) | |||||||||||||||||
| Comment by Githook User [ 01/Oct/19 ] | |||||||||||||||||
|
Author: {'name': 'Bernard Gorman', 'username': 'gormanb', 'email': 'bernard.gorman@mongodb.com'}Message: | |||||||||||||||||
| Comment by Bernard Gorman [ 27/Sep/19 ] | |||||||||||||||||
|
In the case where we have a pipeline on a collection with no user-defined collation and no default collation, the ExpressionContext will be initialized with a nullptr collator and an empty BSONObj collation spec. When we create the $lookup pipeline stage, we make a copy of this ExpressionContext for use in the foreign pipeline. When we come to actually build the execution machinery, we find our way down to prepareExecution, where the lack of a defined collation spec causes us to adopt the foreign collection's default collation by setting an owned clone on the CanonicalQuery, which in turn is propagated back into the ExpressionContext as an unowned pointer. This is OK as long as there is only one document in the local collection. But if the pipeline is torn down and rebuilt for a second local document, the CanonicalQuery and its owned collator are destroyed, leaving the unowned pointer in the ExpressionContext dangling. This does not happen if an explicit collation spec is provided by the user - or if we inherited a collator from the local collection, because we serialize the collator into its equivalent BSONObj spec here before creating the CanonicalQuery. The solution is to have $lookup explicitly request the simple collation on the foreign ExpressionContext in the case where the local collator is null and the user did not specify a collation. | |||||||||||||||||
| Comment by Danny Hatcher (Inactive) [ 16/Sep/19 ] | |||||||||||||||||
|
Thank you Alexey I was able to retrieve the files and I've reproduced your issue. When the collection in the from portion of an aggregation has a collation but the collection running the aggregation command does not and there are multiple records in the latter, the invariant will occur.
I will forward this on to the appropriate team to take a closer look. | |||||||||||||||||
| Comment by Alexey Glukhov [ 16/Sep/19 ] | |||||||||||||||||
|
I`m uploaded two files: | |||||||||||||||||
| Comment by Danny Hatcher (Inactive) [ 16/Sep/19 ] | |||||||||||||||||
|
You can upload everything to our Secure Uploader where things can only be viewed by MongoDB Engineers. | |||||||||||||||||
| Comment by Alexey Glukhov [ 16/Sep/19 ] | |||||||||||||||||
|
Ок, getCollectionInfos() result uploaded. Can I somehow give you data not for public viewing? | |||||||||||||||||
| Comment by Danny Hatcher (Inactive) [ 16/Sep/19 ] | |||||||||||||||||
|
Thanks for the repeated attempts in the log; it provides a lot of context. It appears to be related to our concept of Collation which I notice you are not specifying in the sample aggregation you provided. I assume that you have different collations specified at the collection level for both "items" and "orders"? Could you please provide the output of the following command run against the appropriate logical database?
Additionally, if you could provide a few sample documents from each collection I can emulate them in my own testing. | |||||||||||||||||
| Comment by Alexey Glukhov [ 16/Sep/19 ] | |||||||||||||||||
|
It is also reproduced in version 4.0, in the enterprise and community. In 3.x did not try. | |||||||||||||||||
| Comment by Danny Hatcher (Inactive) [ 16/Sep/19 ] | |||||||||||||||||
|
Have you seen this issue only once or is it reproducible? Have you run the same queries on earlier versions of MongoDB 4.0 and seen the queries succeed? Please provide the full mongod log for the server from the last restart until the crash so that we can investigate. |