Bugzilla

### Security Approval Request
* **How easily could an exploit be constructed based on the patch?**: Likely very tricky.  The current patch fixes no actual bugs, see comment 37; it just creates a framework that helps prevent us from running into those bugs.  To get to an exploit from this, an attacker would have to understand that what the patch does is prevent a register allocation confusion from occuring in very obscure cases, and from that, construct a wasm program that exploits that confusion with a test case that is more complicated than we've seen.  (The test case that started this bug is almost certainly benign, in that it causes the confusion of two integer-valued registers that contain the same value.  An assertion catches that in a debug build only.)

The patch is copiously commented but the comments don't point directly at this possible confusion.  If need be, I can remove comments and commit msg and land later, but I feel this is not necessary.
* **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 older supported branches are affected by this flaw?**: All - it's an old problem stemming from a weird interaction between the register allocator and the optimizer
* **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?**: I don't think we should do that, but in principle patches for older branches could be derived fairly straightforwardly from this one.
* **How likely is this patch to cause regressions; how much testing does it need?**: It is not likely to cause regressions; it guards against a very, very obscure problem and otherwise is no functional change from current code.

### Security Approval Request
* **How easily could an exploit be constructed based on the patch?**: Likely very tricky.  The current patch fixes no actual bugs, see comment 37; it just creates a framework that helps prevent us from running into those bugs.  To get to an exploit from this, an attacker would have to understand that what the patch does is prevent a register allocation confusion from occuring in very obscure cases, and from that, construct a wasm program that exploits that confusion with a test case that is more complicated than we've seen.  (The test case that started this bug is almost certainly benign, in that it causes the confusion of two integer-valued registers that contain the same value.  An assertion catches that in a debug build only.)  The patch is copiously commented but the comments don't point directly at this possible confusion.  If need be, I can remove comments and commit msg and land later, but I feel this is not necessary.
* **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 older supported branches are affected by this flaw?**: All - it's an old problem stemming from a weird interaction between the register allocator and the optimizer
* **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?**: I don't think we should do that, but in principle patches for older branches could be derived fairly straightforwardly from this one.
* **How likely is this patch to cause regressions; how much testing does it need?**: It is not likely to cause regressions; it guards against a very, very obscure problem and otherwise is no functional change from current code.