Bug 2003278 Comment 7 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

### Security Approval Request
* **How easily could an exploit be constructed based on the patch?**: The patch does only reveal that std:sort/stable_sort in general may go out of bounds for bad comparators, which is probably well known. There is no hint on the motivating case from bug 2001855 or other related bugs.
The two exceptions added in the patch are for cases that motivated the change to not have bounds check in general and thus believed to be performance critical and well tested enough to be kept.
So I'd say there is no other info here than trying to hammer on any sort may reveal issues we did not yet find ourselves.
* **Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?**: No
* **Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?**: All branches but 115 ESR. Flags seem up to date.
* **If not all supported branches, which bug introduced the flaw?**: Bug 1887697
* **Do you have backports for the affected branches?**: No
* **If not, how different, hard to create, and risky will they be?**: I assume the patch should graft cleanly on all affected branches.
* **How likely is this patch to cause regressions; how much testing does it need?**: The patch may cause performance regression we will want to monitor. We can add more exceptions if needed (and if we trust those comparators enough).
* **Is the patch ready to land after security approval is given?**: Yes
* **Is Android affected?**: Yes
### Security Approval Request
* **How easily could an exploit be constructed based on the patch?**: The patch does only reveal that std:sort/stable_sort in general may go out of bounds for bad comparators, which is probably well known. There is no hint on the motivating case from bug 2001855 or other related bugs.
The exception added in the patch is for a case that motivated the change to not have bounds check in general and thus believed to be performance critical and well tested enough to be kept.
So I'd say there is no other info here than trying to hammer on any sort may reveal issues we did not yet find ourselves.
* **Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?**: No
* **Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?**: All branches but 115 ESR. Flags seem up to date.
* **If not all supported branches, which bug introduced the flaw?**: Bug 1887697
* **Do you have backports for the affected branches?**: No
* **If not, how different, hard to create, and risky will they be?**: I assume the patch should graft cleanly on all affected branches.
* **How likely is this patch to cause regressions; how much testing does it need?**: The patch may cause performance regression we will want to monitor. We can add more exceptions if needed (and if we trust those comparators enough).
* **Is the patch ready to land after security approval is given?**: Yes
* **Is Android affected?**: Yes

Back to Bug 2003278 Comment 7