[SERVER-58420] Gracefully handle the demotion of data-types in umask Created: 12/Jul/21  Updated: 29/Oct/23  Resolved: 26/Jul/21

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 5.0.3, 5.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Rishab Joshi (Inactive) Assignee: Rishab Joshi (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v5.0
Sprint: Query Execution 2021-07-26, QE 2021-08-09
Participants:
Linked BF Score: 35

 Description   

The Umask code in MozJS translates the input BSON to the type double. The double is then statically typed to the unsigned int (uint32). This could create a problem when the shell is run with the UBSAN and there is an integer overflow, ie. double has a value that does not find in 32 bits. The UBSAN would complain and crash the process.

MozJS seems to translate any number type to double internally, we should clamp the value from double to integer safely as part of the fix.



 Comments   
Comment by Vivian Ge (Inactive) [ 06/Oct/21 ]

Updating the fixversion since branching activities occurred yesterday. This ticket will be in rc0 when it’s been triggered. For more active release information, please keep an eye on #server-release. Thank you!

Comment by Githook User [ 20/Aug/21 ]

Author:

{'name': 'Rishab Joshi', 'email': 'rishab.joshi@mongodb.com', 'username': 'rishvin'}

Message: SERVER-58420 Clamp safely the input value of changeUmask.
Branch: v5.0
https://github.com/mongodb/mongo/commit/2e8cc64d061a0cd8ed0f98db92dd9232521f94ca

Comment by Githook User [ 26/Jul/21 ]

Author:

{'name': 'Rishab Joshi', 'email': 'rishab.joshi@mongodb.com', 'username': 'rishvin'}

Message: SERVER-58420 Clamp safely the input value of changeUmask.
Branch: master
https://github.com/mongodb/mongo/commit/0630fc161e7ff748d30c2e7790524ef95c3d6aae

Generated at Thu Feb 08 05:44:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.