Bugzilla

### Security Approval Request
* **How easily could an exploit be constructed based on the patch?**: Despite being a small patch, reverse-engineering the condition for this issue is not straightforward:
* Prerequisite (Border-collapsed MathML table): Involvement of border-collapse is hidden & not directly referenced in the patch.
* Trigger (Column span that exceeds the overall size of the table gets restyled): Not directly referenced in the patch - Need to know about existence of "ghost cells" being inserted for invalid spans like this.

However, once the conditions are figured out, the exploit is not hard to create, especially intentionally.
That said, this is a null pointer dereference rather than OOB access, given the guard [here](https://searchfox.org/mozilla-central/rev/a8cc31504a2379bcf8ba395d2da7bb632b5521d6/layout/tables/nsTableFrame.cpp#419)) .
* **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
* **If not all supported branches, which bug introduced the flaw?**: None
* **Do you have backports for the affected branches?**: No
* **If not, how different, hard to create, and risky will they be?**: Highly localized patch, should be easy & low risk.
* **How likely is this patch to cause regressions; how much testing does it need?**: As above - highly localized patch, that opens a code path for a very specific (i.e. MathML) case, so low risk.
Attached test patch + existing border-collapsed table tests should suffice.
* **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?**: Despite being a small patch, reverse-engineering the condition for this issue is not straightforward:
    * Prerequisite (Border-collapsed MathML table): Involvement of border-collapse is hidden & not directly referenced in the patch.
    * Trigger (Column span that exceeds the overall size of the table gets restyled): Not directly referenced in the patch - Need to know about existence of "ghost cells" being inserted for invalid spans like this.

However, once the conditions are figured out, the exploit is not hard to create, especially intentionally.
That said, this is a null pointer dereference rather than OOB access, given the guard [here](https://searchfox.org/mozilla-central/rev/a8cc31504a2379bcf8ba395d2da7bb632b5521d6/layout/tables/nsTableFrame.cpp#419)) .
* **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
* **If not all supported branches, which bug introduced the flaw?**: None
* **Do you have backports for the affected branches?**: No
* **If not, how different, hard to create, and risky will they be?**: Highly localized patch, should be easy & low risk.
* **How likely is this patch to cause regressions; how much testing does it need?**: As above - highly localized patch, that opens a code path for a very specific (i.e. MathML) case, so low risk.
Attached test patch + existing border-collapsed table tests should suffice.
* **Is the patch ready to land after security approval is given?**: Yes
* **Is Android affected?**: Yes