-
Type:
Task
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Server Programmability
-
Fully Compatible
-
Programmability 2025-01-06, Programmability 2025-01-20, Programmability 2025-02-03, Programmability 2025-02-17, Programmability 2025-03-03, Programmability 2025-03-17
-
200
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
As a fallout from recent now-public CVEs (linked to this issue) we'd like to ensure that we avoid any crashes on user/connection threads due to a noexcept boundary being triggered. We have recently updated our documentation to have a much stricter policy on when noexcept should be used at all, but have decided to separate out noexcepts on user threads as a targeted fix for teams to execute.
For every noexcept in code owned by your team identified by this spreadsheet, please:
- Check if the noexcept could be triggered on a user thread.
- If yes to 1, check if the noexcept qualifies to remain based on the documentation's criteria.
- If no to 2, remove the noexcept. If it is necessary – in some places a crash is truly and unequivocally preferable – add new logic that explicitly generates behavior that was being implicitly triggered by noexcept. If you were relying on crash behavior, strongly consider downgrading instead to a tassert, meaning that crashes only happen in test environment. Using a tassert would be much more preferable from a user safety standpoint.
- related to
-
SERVER-104691 Coverity analysis defect 174137: Uncaught exception
-
- Closed
-