Shared security patch analysis results
AI Used: DEEPSEEK deepseek-chat--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/python/mozbuild/mozbuild/mozinfo.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/python/mozbuild/mozbuild/mozinfo.py@@ -97,6 +97,7 @@ d["ccov"] = substs.get("MOZ_CODE_COVERAGE") == "1" d["cc_type"] = substs.get("CC_TYPE") d["non_native_theme"] = True+ d["domstreams"] = substs.get("MOZ_DOM_STREAMS") == "1" def guess_platform(): if d["buildapp"] == "browser":
Analyzing the provided code diff for security fixes:
1. Vulnerability Existed: no
No specific vulnerability found [python/mozbuild/mozbuild/mozinfo.py] [Lines 97-98]
Old Code: No previous line for domstreams
Fixed Code: d["domstreams"] = substs.get("MOZ_DOM_STREAMS") == "1"
Additional Details:
- The change appears to be a feature addition rather than a security fix
- No known vulnerability is being addressed here
- The code simply adds a new configuration flag for DOM streams functionality
- No insecure patterns or vulnerabilities are being fixed in this diff
Note: If this were a security fix, we would expect to see changes to existing code that had security implications, such as input validation, permission checks, or similar security-related modifications. This appears to be purely a feature enhancement.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.attributes.shadowBlur.valid.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.attributes.shadowBlur.valid.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.shadowBlur = 1; _assertSame(ctx.shadowBlur, 1, "ctx.shadowBlur", "1");
Analysis of the provided code diff:
1. Vulnerability Existed: no
No security vulnerability found [File] [Lines 17-18]
Old Code:
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
Fixed Code:
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
Additional Details:
- The change appears to be a simple variable renaming from "offscreenCanvas" to "canvas"
- No security implications are evident in this change
- This is likely a code style/readability improvement rather than a security fix
- The functionality remains exactly the same, just with a different variable name
No known vulnerability patterns (e.g., XSS, injection, memory issues) are present in this change. The modification doesn't affect any security-relevant behavior of the canvas or shadow operations.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.clearRect.transform.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.clearRect.transform.html@@ -17,15 +17,15 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50); ctx.scale(10, 10); ctx.translate(0, 5); ctx.clearRect(0, -5, 10, 5);-_assertPixel(offscreenCanvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0");+_assertPixel(canvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0"); t.done(); });
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely cosmetic/refactoring changes (variable renaming) rather than security fixes. Here's the analysis:
1. Vulnerability Existed: no
No security vulnerability found
File: testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.clearRect.transform.html
Lines: 17-25
Old Code:
```
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0");
```
Fixed Code:
```
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0");
```
The changes simply rename the variable `offscreenCanvas` to `canvas` and update all references to it. The functionality remains exactly the same, and there are no security implications to this change. The test continues to perform the same canvas operations and assertions.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/compositing/mix-blend-mode/mix-blend-mode-parent-with-text.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/compositing/mix-blend-mode/mix-blend-mode-parent-with-text.html@@ -10,7 +10,6 @@ <link rel="help" href="https://drafts.fxtf.org/compositing-1/#mix-blend-mode"> <meta name="assert" content="Test checks that an element with mix-blend-mode only blends with the contents of a parent that creates a stacking context.">- <meta name="flags" content=""/> <link rel="match" href="reference/mix-blend-mode-parent-with-text-ref.html"> <style type="text/css"> .parent {
Based on the provided diff, I'll analyze it for potential security vulnerabilities: Vulnerability Existed: no [No specific vulnerability found] [testing/web-platform/tests/css/compositing/mix-blend-mode/mix-blend-mode-parent-with-text.html] [Lines 10] [Old Code: `<meta name="flags" content=""/>`] [Fixed Code: (line removed)] Additional Details: - The change simply removes an empty meta tag for "flags" which appears to be test configuration related - No security-relevant changes were made - This appears to be a test file cleanup rather than a security fix - No known vulnerability patterns (XSS, injection, etc.) are present in this change No other vulnerabilities were identified in the provided diff. The change is minor and doesn't appear to be security-related.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/urlpattern/resources/urlpatterntestdata.json+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/urlpattern/resources/urlpatterntestdata.json@@ -2508,7 +2508,7 @@ "pattern": [{ "pathname": "{:foo}{(.*)bar}" }], "inputs": [{ "pathname": "foobarbaz" }], "expected_obj": {- "pathname": ":foo{(.*)bar}"+ "pathname": ":foo{*bar}" }, "expected_match": null },@@ -2516,7 +2516,7 @@ "pattern": [{ "pathname": "{:foo}{bar(.*)}" }], "inputs": [{ "pathname": "foobarbaz" }], "expected_obj": {- "pathname": ":foo{bar(.*)}"+ "pathname": ":foo{bar*}" }, "expected_match": { "pathname": { "input": "foobarbaz", "groups": { "foo": "foo", "0": "baz" }}@@ -2636,5 +2636,86 @@ "expected_match": { "pathname": { "input": "bazbar", "groups": { "foo": "baz" }} }+ },+ {+ "pattern": [{ "pathname": "*/*" }],+ "inputs": [{ "pathname": "foo/bar" }],+ "expected_match": {+ "pathname": { "input": "foo/bar", "groups": { "0": "foo", "1": "bar" }}+ }+ },+ {+ "pattern": [{ "pathname": "*\\/*" }],+ "inputs": [{ "pathname": "foo/bar" }],+ "expected_obj": {+ "pathname": "*/{*}"+ },+ "expected_match": {+ "pathname": { "input": "foo/bar", "groups": { "0": "foo", "1": "bar" }}+ }+ },+ {+ "pattern": [{ "pathname": "*/{*}" }],+ "inputs": [{ "pathname": "foo/bar" }],+ "expected_match": {+ "pathname": { "input": "foo/bar", "groups": { "0": "foo", "1": "bar" }}+ }+ },+ {+ "pattern": [{ "pathname": "*//*" }],+ "inputs": [{ "pathname": "foo/bar" }],+ "expected_match": null+ },+ {+ "pattern": [{ "pathname": "/:foo." }],+ "inputs": [{ "pathname": "/bar." }],+ "expected_match": {+ "pathname": { "input": "/bar.", "groups": { "foo": "bar" } }+ }+ },+ {+ "pattern": [{ "pathname": "/:foo.." }],+ "inputs": [{ "pathname": "/bar.." }],+ "expected_match": {+ "pathname": { "input": "/bar..", "groups": { "foo": "bar" } }+ }+ },+ {+ "pattern": [{ "pathname": "./foo" }],+ "inputs": [{ "pathname": "./foo" }],+ "expected_match": {+ "pathname": { "input": "./foo", "groups": {}}+ }+ },+ {+ "pattern": [{ "pathname": "../foo" }],+ "inputs": [{ "pathname": "../foo" }],+ "expected_match": {+ "pathname": { "input": "../foo", "groups": {}}+ }+ },+ {+ "pattern": [{ "pathname": ":foo./" }],+ "inputs": [{ "pathname": "bar./" }],+ "expected_match": {+ "pathname": { "input": "bar./", "groups": { "foo": "bar" }}+ }+ },+ {+ "pattern": [{ "pathname": ":foo../" }],+ "inputs": [{ "pathname": "bar../" }],+ "expected_match": {+ "pathname": { "input": "bar../", "groups": { "foo": "bar" }}+ }+ },+ {+ "pattern": [{ "pathname": "/:foo\\bar" }],+ "inputs": [{ "pathname": "/bazbar" }],+ "expected_obj": {+ "pathname": "{/:foo}bar"+ },+ "expected_match": {+ "pathname": { "input": "/bazbar", "groups": { "foo": "baz" }}+ } } ]
Here's the analysis of the provided code diff for security fixes:
1. Vulnerability Existed: not sure
[Potential URL Pattern Parsing Issue] [File: testing/web-platform/tests/urlpattern/resources/urlpatterntestdata.json] [Lines: 2508-2516]
[Old Code]
```json
"pathname": ":foo{(.*)bar}"
```
[Fixed Code]
```json
"pathname": ":foo{*bar}"
```
Additional Details: The change modifies the pattern syntax, but it's unclear if this was fixing a security vulnerability or just improving pattern matching behavior.
2. Vulnerability Existed: not sure
[Potential URL Pattern Parsing Issue] [File: testing/web-platform/tests/urlpattern/resources/urlpatterntestdata.json] [Lines: 2516-2524]
[Old Code]
```json
"pathname": ":foo{bar(.*)}"
```
[Fixed Code]
```json
"pathname": ":foo{bar*}"
```
Additional Details: Similar to the first change, this modifies pattern syntax but it's unclear if it addresses a security issue.
3. Vulnerability Existed: not sure
[Potential Path Traversal] [File: testing/web-platform/tests/urlpattern/resources/urlpatterntestdata.json] [Lines: 2636-2700+]
[Old Code]
(No previous test cases for relative paths)
[Fixed Code]
```json
{
"pattern": [{ "pathname": "../foo" }],
"inputs": [{ "pathname": "../foo" }],
"expected_match": {
"pathname": { "input": "../foo", "groups": {}}
}
}
```
Additional Details: The addition of tests for relative paths ("./foo", "../foo") might indicate previous path traversal vulnerabilities, but this is speculative.
Note: The diff appears to be primarily test case modifications and additions rather than direct security fixes. The changes could be related to improving URL pattern matching robustness, but without more context about the actual implementation changes, it's difficult to confirm specific vulnerabilities. The test cases added at the end suggest improved handling of various URL pattern edge cases, which could prevent potential security issues related to URL parsing.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/text/2d.text.draw.space.collapse.start.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/text/2d.text.draw.space.collapse.start.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); var f = new FontFace("CanvasTest", "url('/fonts/CanvasTest.ttf')"); let fonts = (self.fonts ? self.fonts : document.fonts);@@ -26,8 +26,8 @@ ctx.fillRect(0, 0, 100, 50); ctx.fillStyle = '#0f0'; ctx.fillText(' EE', 0, 37.5);- _assertPixelApprox(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255", 2); }).then(t_pass, t_fail); });
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming and don't affect security. Here's the analysis:
1. Vulnerability Existed: no
Variable Renaming [File] [Lines 13-14, 26-27]
Old Code:
```
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
```
Fixed Code:
```
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
```
2. Vulnerability Existed: no
Variable Renaming [File] [Lines 26-27]
Old Code:
```
_assertPixelApprox(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255", 2);
_assertPixelApprox(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255", 2);
```
Fixed Code:
```
_assertPixelApprox(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255", 2);
_assertPixelApprox(canvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255", 2);
```
The changes are purely cosmetic, renaming the variable `offscreenCanvas` to `canvas` for consistency or readability. No security-related changes were made in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/js/src/jit/x64/MacroAssembler-x64.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/jit/x64/MacroAssembler-x64.cpp@@ -64,6 +64,18 @@ propagateOOM(val->uses.append(j)); }+void MacroAssemblerX64::vpRiprOpSimd128(+ const SimdConstant& v, FloatRegister src, FloatRegister dest,+ JmpSrc (X86Encoding::BaseAssemblerX64::*op)(+ X86Encoding::XMMRegisterID srcId, X86Encoding::XMMRegisterID destId)) {+ SimdData* val = getSimdData(v);+ if (!val) {+ return;+ }+ JmpSrc j = (masm.*op)(src.encoding(), dest.encoding());+ propagateOOM(val->uses.append(j));+}+ void MacroAssemblerX64::loadConstantSimd128Int(const SimdConstant& v, FloatRegister dest) { if (maybeInlineSimd128Int(v, dest)) {@@ -80,314 +92,320 @@ vpRiprOpSimd128(v, dest, &X86Encoding::BaseAssemblerX64::vmovaps_ripr); }-void MacroAssemblerX64::vpaddbSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpaddb_ripr);-}--void MacroAssemblerX64::vpaddwSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpaddw_ripr);-}--void MacroAssemblerX64::vpadddSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpaddd_ripr);-}--void MacroAssemblerX64::vpaddqSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpaddq_ripr);-}--void MacroAssemblerX64::vpsubbSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpsubb_ripr);-}--void MacroAssemblerX64::vpsubwSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpsubw_ripr);-}--void MacroAssemblerX64::vpsubdSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpsubd_ripr);-}--void MacroAssemblerX64::vpsubqSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpsubq_ripr);-}--void MacroAssemblerX64::vpmullwSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpmullw_ripr);-}--void MacroAssemblerX64::vpmulldSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpmulld_ripr);-}--void MacroAssemblerX64::vpaddsbSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpaddsb_ripr);+void MacroAssemblerX64::vpaddbSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpaddb_ripr);+}++void MacroAssemblerX64::vpaddwSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpaddw_ripr);+}++void MacroAssemblerX64::vpadddSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpaddd_ripr);+}++void MacroAssemblerX64::vpaddqSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpaddq_ripr);+}++void MacroAssemblerX64::vpsubbSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpsubb_ripr);+}++void MacroAssemblerX64::vpsubwSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpsubw_ripr);+}++void MacroAssemblerX64::vpsubdSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpsubd_ripr);+}++void MacroAssemblerX64::vpsubqSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpsubq_ripr);+}++void MacroAssemblerX64::vpmullwSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpmullw_ripr);+}++void MacroAssemblerX64::vpmulldSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpmulld_ripr);+}++void MacroAssemblerX64::vpaddsbSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpaddsb_ripr); } void MacroAssemblerX64::vpaddusbSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpaddusb_ripr);-}--void MacroAssemblerX64::vpaddswSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpaddsw_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpaddusb_ripr);+}++void MacroAssemblerX64::vpaddswSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpaddsw_ripr); } void MacroAssemblerX64::vpadduswSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpaddusw_ripr);-}--void MacroAssemblerX64::vpsubsbSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpsubsb_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpaddusw_ripr);+}++void MacroAssemblerX64::vpsubsbSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpsubsb_ripr); } void MacroAssemblerX64::vpsubusbSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpsubusb_ripr);-}--void MacroAssemblerX64::vpsubswSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpsubsw_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpsubusb_ripr);+}++void MacroAssemblerX64::vpsubswSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpsubsw_ripr); } void MacroAssemblerX64::vpsubuswSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpsubusw_ripr);-}--void MacroAssemblerX64::vpminsbSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpminsb_ripr);-}--void MacroAssemblerX64::vpminubSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpminub_ripr);-}--void MacroAssemblerX64::vpminswSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpminsw_ripr);-}--void MacroAssemblerX64::vpminuwSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpminuw_ripr);-}--void MacroAssemblerX64::vpminsdSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpminsd_ripr);-}--void MacroAssemblerX64::vpminudSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpminud_ripr);-}--void MacroAssemblerX64::vpmaxsbSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpmaxsb_ripr);-}--void MacroAssemblerX64::vpmaxubSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpmaxub_ripr);-}--void MacroAssemblerX64::vpmaxswSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpmaxsw_ripr);-}--void MacroAssemblerX64::vpmaxuwSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpmaxuw_ripr);-}--void MacroAssemblerX64::vpmaxsdSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpmaxsd_ripr);-}--void MacroAssemblerX64::vpmaxudSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpmaxud_ripr);-}--void MacroAssemblerX64::vpandSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpand_ripr);-}--void MacroAssemblerX64::vpxorSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpxor_ripr);-}--void MacroAssemblerX64::vporSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpor_ripr);-}--void MacroAssemblerX64::vaddpsSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vaddps_ripr);-}--void MacroAssemblerX64::vaddpdSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vaddpd_ripr);-}--void MacroAssemblerX64::vsubpsSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vsubps_ripr);-}--void MacroAssemblerX64::vsubpdSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vsubpd_ripr);-}--void MacroAssemblerX64::vdivpsSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vdivps_ripr);-}--void MacroAssemblerX64::vdivpdSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vdivpd_ripr);-}--void MacroAssemblerX64::vmulpsSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vmulps_ripr);-}--void MacroAssemblerX64::vmulpdSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vmulpd_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpsubusw_ripr);+}++void MacroAssemblerX64::vpminsbSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpminsb_ripr);+}++void MacroAssemblerX64::vpminubSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpminub_ripr);+}++void MacroAssemblerX64::vpminswSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpminsw_ripr);+}++void MacroAssemblerX64::vpminuwSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpminuw_ripr);+}++void MacroAssemblerX64::vpminsdSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpminsd_ripr);+}++void MacroAssemblerX64::vpminudSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpminud_ripr);+}++void MacroAssemblerX64::vpmaxsbSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpmaxsb_ripr);+}++void MacroAssemblerX64::vpmaxubSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpmaxub_ripr);+}++void MacroAssemblerX64::vpmaxswSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpmaxsw_ripr);+}++void MacroAssemblerX64::vpmaxuwSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpmaxuw_ripr);+}++void MacroAssemblerX64::vpmaxsdSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpmaxsd_ripr);+}++void MacroAssemblerX64::vpmaxudSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpmaxud_ripr);+}++void MacroAssemblerX64::vpandSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpand_ripr);+}++void MacroAssemblerX64::vpxorSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpxor_ripr);+}++void MacroAssemblerX64::vporSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpor_ripr);+}++void MacroAssemblerX64::vaddpsSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vaddps_ripr);+}++void MacroAssemblerX64::vaddpdSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vaddpd_ripr);+}++void MacroAssemblerX64::vsubpsSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vsubps_ripr);+}++void MacroAssemblerX64::vsubpdSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vsubpd_ripr);+}++void MacroAssemblerX64::vdivpsSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vdivps_ripr);+}++void MacroAssemblerX64::vdivpdSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vdivpd_ripr);+}++void MacroAssemblerX64::vmulpsSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vmulps_ripr);+}++void MacroAssemblerX64::vmulpdSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vmulpd_ripr); } void MacroAssemblerX64::vpacksswbSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpacksswb_ripr);+ FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpacksswb_ripr); } void MacroAssemblerX64::vpackuswbSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpackuswb_ripr);+ FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpackuswb_ripr); } void MacroAssemblerX64::vpackssdwSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpackssdw_ripr);+ FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpackssdw_ripr); } void MacroAssemblerX64::vpackusdwSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpackusdw_ripr);-}--void MacroAssemblerX64::vpshufbSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpshufb_ripr);+ FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpackusdw_ripr);+}++void MacroAssemblerX64::vpshufbSimd128(const SimdConstant& v, FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpshufb_ripr); } void MacroAssemblerX64::vptestSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vptest_ripr);+ FloatRegister lhs) {+ vpRiprOpSimd128(v, lhs, &X86Encoding::BaseAssemblerX64::vptest_ripr); } void MacroAssemblerX64::vpmaddwdSimd128(const SimdConstant& v,- FloatRegister srcDest) {- vpRiprOpSimd128(v, srcDest, &X86Encoding::BaseAssemblerX64::vpmaddwd_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpmaddwd_ripr); } void MacroAssemblerX64::vpcmpeqbSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vpcmpeqb_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpcmpeqb_ripr); } void MacroAssemblerX64::vpcmpgtbSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vpcmpgtb_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpcmpgtb_ripr); } void MacroAssemblerX64::vpcmpeqwSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vpcmpeqw_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpcmpeqw_ripr); } void MacroAssemblerX64::vpcmpgtwSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vpcmpgtw_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpcmpgtw_ripr); } void MacroAssemblerX64::vpcmpeqdSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vpcmpeqd_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpcmpeqd_ripr); } void MacroAssemblerX64::vpcmpgtdSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vpcmpgtd_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vpcmpgtd_ripr); } void MacroAssemblerX64::vcmpeqpsSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vcmpeqps_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vcmpeqps_ripr); } void MacroAssemblerX64::vcmpneqpsSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vcmpneqps_ripr);+ FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vcmpneqps_ripr); } void MacroAssemblerX64::vcmpltpsSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vcmpltps_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vcmpltps_ripr); } void MacroAssemblerX64::vcmplepsSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vcmpleps_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vcmpleps_ripr); } void MacroAssemblerX64::vcmpeqpdSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vcmpeqpd_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vcmpeqpd_ripr); } void MacroAssemblerX64::vcmpneqpdSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vcmpneqpd_ripr);+ FloatRegister lhs,+ FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vcmpneqpd_ripr); } void MacroAssemblerX64::vcmpltpdSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vcmpltpd_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vcmpltpd_ripr); } void MacroAssemblerX64::vcmplepdSimd128(const SimdConstant& v,- FloatRegister src) {- vpRiprOpSimd128(v, src, &X86Encoding::BaseAssemblerX64::vcmplepd_ripr);+ FloatRegister lhs, FloatRegister dest) {+ vpRiprOpSimd128(v, lhs, dest, &X86Encoding::BaseAssemblerX64::vcmplepd_ripr); } void MacroAssemblerX64::bindOffsets(@@ -922,12 +940,17 @@ void MacroAssembler::wasmLoad(const wasm::MemoryAccessDesc& access, Operand srcAddr, AnyRegister out) {+ // NOTE: the generated code must match the assembly code in gen_load in+ // GenerateAtomicOperations.py memoryBarrierBefore(access.sync()); MOZ_ASSERT_IF( access.isZeroExtendSimd128Load(), access.type() == Scalar::Float32 || access.type() == Scalar::Float64);- MOZ_ASSERT_IF(access.isSplatSimd128Load(), access.type() == Scalar::Float64);+ MOZ_ASSERT_IF(+ access.isSplatSimd128Load(),+ access.type() == Scalar::Uint8 || access.type() == Scalar::Uint16 ||+ access.type() == Scalar::Float32 || access.type() == Scalar::Float64); MOZ_ASSERT_IF(access.isWidenSimd128Load(), access.type() == Scalar::Float64); append(access, size());@@ -936,21 +959,33 @@ movsbl(srcAddr, out.gpr()); break; case Scalar::Uint8:- movzbl(srcAddr, out.gpr());+ if (access.isSplatSimd128Load()) {+ vbroadcastb(srcAddr, out.fpu());+ } else {+ movzbl(srcAddr, out.gpr());+ } break; case Scalar::Int16: movswl(srcAddr, out.gpr()); break; case Scalar::Uint16:- movzwl(srcAddr, out.gpr());+ if (access.isSplatSimd128Load()) {+ vbroadcastw(srcAddr, out.fpu());+ } else {+ movzwl(srcAddr, out.gpr());+ } break; case Scalar::Int32: case Scalar::Uint32: movl(srcAddr, out.gpr()); break; case Scalar::Float32:- // vmovss does the right thing also for access.isZeroExtendSimd128Load()- vmovss(srcAddr, out.fpu());+ if (access.isSplatSimd128Load()) {+ vbroadcastss(srcAddr, out.fpu());+ } else {+ // vmovss does the right thing also for access.isZeroExtendSimd128Load()+ vmovss(srcAddr, out.fpu());+ } break; case Scalar::Float64: if (access.isSplatSimd128Load()) {@@ -1000,6 +1035,8 @@ void MacroAssembler::wasmLoadI64(const wasm::MemoryAccessDesc& access, Operand srcAddr, Register64 out) {+ // NOTE: the generated code must match the assembly code in gen_load in+ // GenerateAtomicOperations.py memoryBarrierBefore(access.sync()); append(access, size());@@ -1042,6 +1079,8 @@ void MacroAssembler::wasmStore(const wasm::MemoryAccessDesc& access, AnyRegister value, Operand dstAddr) {+ // NOTE: the generated code must match the assembly code in gen_store in+ // GenerateAtomicOperations.py memoryBarrierBefore(access.sync()); append(access, masm.size());@@ -1327,6 +1366,8 @@ const wasm::MemoryAccessDesc* access, AtomicOp op, Register value, const T& mem, Register temp, Register output) {+ // NOTE: the generated code must match the assembly code in gen_fetchop in+ // GenerateAtomicOperations.py if (op == AtomicFetchAddOp) { if (value != output) { masm.movq(value, output);@@ -1426,6 +1467,8 @@ const Address& mem, Register64 expected, Register64 replacement, Register64 output) {+ // NOTE: the generated code must match the assembly code in gen_cmpxchg in+ // GenerateAtomicOperations.py MOZ_ASSERT(output.reg == rax); if (expected != output) { movq(expected.reg, output.reg);@@ -1448,6 +1491,8 @@ void MacroAssembler::atomicExchange64(const Synchronization&, const Address& mem, Register64 value, Register64 output) {+ // NOTE: the generated code must match the assembly code in gen_exchange in+ // GenerateAtomicOperations.py if (value != output) { movq(value.reg, output.reg); }
After analyzing the provided code diff, I don't identify any clear security vulnerabilities that were fixed. The changes appear to be primarily functional improvements and code refactoring rather than security fixes. Here's my analysis:
1. For the SIMD operations changes:
Vulnerability Existed: no
The changes mainly involve refactoring SIMD operation functions to use separate source and destination registers rather than combined srcDest registers. This improves code clarity but doesn't appear to address any security issues.
2. For the wasm memory operations changes:
Vulnerability Existed: no
The changes add support for more SIMD load/store operations and improve comments, but don't appear to fix any security vulnerabilities.
3. For the atomic operations changes:
Vulnerability Existed: no
The changes add notes about matching generated code with assembly references, but these appear to be documentation improvements rather than security fixes.
The diff shows significant changes to the SIMD and atomic operation implementations, but these appear to be:
1. Refactoring for better code organization
2. Adding support for additional operations
3. Improving documentation
4. Making the interface more consistent
Without any specific CVE references or security-related commit messages, and given the nature of the changes, I don't find evidence of security vulnerabilities being addressed in this diff. The changes seem focused on functionality, performance, and code quality improvements rather than security fixes.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/naga/src/front/wgsl/lexer.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/naga/src/front/wgsl/lexer.rs@@ -322,7 +322,12 @@ if next == Some('=') && !generic { (Token::LogicalOperation(cur), chars.as_str()) } else if next == Some(cur) && !generic {- (Token::ShiftOperation(cur), chars.as_str())+ input = chars.as_str();+ if chars.next() == Some('=') {+ (Token::AssignmentOperation(cur), chars.as_str())+ } else {+ (Token::ShiftOperation(cur), input)+ } } else { (Token::Paren(cur), input) }@@ -356,14 +361,22 @@ (Token::Trivia, chars.as_str()) } '-' => {- let og_chars = chars.as_str();+ let sub_input = chars.as_str(); match chars.next() { Some('>') => (Token::Arrow, chars.as_str()), Some('0'..='9') | Some('.') => consume_number(input),- _ => (Token::Operation(cur), og_chars),- }- }- '+' | '*' | '/' | '%' | '^' => (Token::Operation(cur), chars.as_str()),+ Some('=') => (Token::AssignmentOperation(cur), chars.as_str()),+ _ => (Token::Operation(cur), sub_input),+ }+ }+ '+' | '*' | '/' | '%' | '^' => {+ input = chars.as_str();+ if chars.next() == Some('=') {+ (Token::AssignmentOperation(cur), chars.as_str())+ } else {+ (Token::Operation(cur), input)+ }+ } '!' | '~' => { input = chars.as_str(); if chars.next() == Some('=') {@@ -374,8 +387,11 @@ } '=' | '&' | '|' => { input = chars.as_str();- if chars.next() == Some(cur) {+ let next = chars.next();+ if next == Some(cur) { (Token::LogicalOperation(cur), chars.as_str())+ } else if next == Some('=') {+ (Token::AssignmentOperation(cur), chars.as_str()) } else { (Token::Operation(cur), input) }
I'll analyze the code diff and provide the security fixes following the specified format.
1. Vulnerability Existed: not sure
[Incomplete Operator Handling] [third_party/rust/naga/src/front/wgsl/lexer.rs] [Lines 322-330]
[Old Code]
} else if next == Some(cur) && !generic {
(Token::ShiftOperation(cur), chars.as_str())
} else {
(Token::Paren(cur), input)
}
[Fixed Code]
} else if next == Some(cur) && !generic {
input = chars.as_str();
if chars.next() == Some('=') {
(Token::AssignmentOperation(cur), chars.as_str())
} else {
(Token::ShiftOperation(cur), input)
}
} else {
(Token::Paren(cur), input)
}
2. Vulnerability Existed: not sure
[Incomplete Operator Handling] [third_party/rust/naga/src/front/wgsl/lexer.rs] [Lines 356-362]
[Old Code]
'-' => {
let og_chars = chars.as_str();
match chars.next() {
Some('>') => (Token::Arrow, chars.as_str()),
Some('0'..='9') | Some('.') => consume_number(input),
_ => (Token::Operation(cur), og_chars),
}
}
[Fixed Code]
'-' => {
let sub_input = chars.as_str();
match chars.next() {
Some('>') => (Token::Arrow, chars.as_str()),
Some('0'..='9') | Some('.') => consume_number(input),
Some('=') => (Token::AssignmentOperation(cur), chars.as_str()),
_ => (Token::Operation(cur), sub_input),
}
}
3. Vulnerability Existed: not sure
[Incomplete Operator Handling] [third_party/rust/naga/src/front/wgsl/lexer.rs] [Lines 364]
[Old Code]
'+' | '*' | '/' | '%' | '^' => (Token::Operation(cur), chars.as_str()),
[Fixed Code]
'+' | '*' | '/' | '%' | '^' => {
input = chars.as_str();
if chars.next() == Some('=') {
(Token::AssignmentOperation(cur), chars.as_str())
} else {
(Token::Operation(cur), input)
}
}
4. Vulnerability Existed: not sure
[Incomplete Operator Handling] [third_party/rust/naga/src/front/wgsl/lexer.rs] [Lines 374-380]
[Old Code]
'=' | '&' | '|' => {
input = chars.as_str();
if chars.next() == Some(cur) {
(Token::LogicalOperation(cur), chars.as_str())
} else {
(Token::Operation(cur), input)
}
}
[Fixed Code]
'=' | '&' | '|' => {
input = chars.as_str();
let next = chars.next();
if next == Some(cur) {
(Token::LogicalOperation(cur), chars.as_str())
} else if next == Some('=') {
(Token::AssignmentOperation(cur), chars.as_str())
} else {
(Token::Operation(cur), input)
}
}
Note: While I can't identify specific named vulnerabilities, the changes appear to be implementing more complete operator handling in the WGSL lexer, particularly for assignment operations (like +=, -=, etc.). These changes prevent potential parsing ambiguities that could lead to security issues, though I can't confirm if these were actually exploitable vulnerabilities.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/python/requirements.txt+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/python/requirements.txt@@ -50,9 +50,9 @@ # via # aiohttp # taskcluster-attrs==19.1.0 \- --hash=sha256:69c0dbf2ed392de1cb5ec704444b08a5ef81680a61cb899dc08127123af36a79 \- --hash=sha256:f0b870f674851ecbfbbbd364d6b5cbdff9dcedbc7f3f5e18a6891057f21fe399+attrs==19.2.0 \+ --hash=sha256:ec20e7a4825331c1b5ebf261d111e16fa9612c1f7a5e1f884f12bd53a664dfd2 \+ --hash=sha256:f913492e1663d3c36f502e5e9ba6cd13cf19d7fab50aa13239e420fef95e1396 # via # -r requirements-mach-vendor-python.in # aiohttp@@ -90,9 +90,9 @@ --hash=sha256:5941b2b48a20143d2267e95b1c2a7603ce057ee39fd88e7329b0c292aa16869b \ --hash=sha256:9f47eda37229f68eee03b24b9748937c7dc3868f906e8ba69fbcbdd3bc5dc3e2 # via -r requirements-mach-vendor-python.in-compare-locales==8.1.0 \- --hash=sha256:286270797ce64f7a2f25e734bb437870661409884a4f0971c0bb94fdad6c1f35 \- --hash=sha256:3d374ff959d5de2cfd5b94caf6b0fa61445f1d8ede5af384002cb3542aacad3a+compare-locales==8.2.1 \+ --hash=sha256:470d50d96c68f8e147daa3d70f29a7b750adefea450c5fa07e0f666c8083d854 \+ --hash=sha256:e6a1610151d357e74ee6c1f5e944f1868e449f83e478c84d92f7b86132f721d7 # via # -r requirements-mach-vendor-python.in # fluent.migrate@@ -162,9 +162,9 @@ # -r requirements-mach-vendor-python.in # compare-locales # fluent.migrate-glean_parser==4.3.1 \- --hash=sha256:a8924a3a4aca7fba35dc69d93031993d6481c6ec9cd43362c068eb3e18ea43e8 \- --hash=sha256:c194aba35a57ff9d139527c5321ef526599794994e355bad4c314bd3ab64c3eb+glean_parser==4.4.0 \+ --hash=sha256:3ae1435b183936a49368806421df27ab944f1802e86a02b38b8e08e53ff0aac5 \+ --hash=sha256:948a2b3c81270564a33251fc8ecbfe48bf0549f74bc2d5a8027f6d7b1abae828 # via -r requirements-mach-vendor-python.in idna-ssl==1.1.0 \ --hash=sha256:a933e3bb13da54383f9e8f35dc4f9cb9eb9b3b78c6b36f311254d6d0d92c6c7c@@ -418,9 +418,9 @@ # -r requirements-mach-vendor-python.in # taskcluster # taskcluster-taskgraph-taskcluster-taskgraph==1.1.0 \- --hash=sha256:d3991c71484dfdf102e5479ce71a4e6d43a1889a33bec4aae634c70150cd3f28 \- --hash=sha256:eee145dedd2c12b6404d100ceb6e15a30820b75c8fed587a5cb804d254947153+taskcluster-taskgraph==1.1.5 \+ --hash=sha256:d55564691d211c550319fae5964d67400b4c1ebd5e8423b2548d48240b8498ad \+ --hash=sha256:e162cbefb765fd500166ede24172f4520c0662589b6218586b9eab4cbfeed0da # via -r requirements-mach-vendor-python.in taskcluster-urls==13.0.1 \ --hash=sha256:5e25e7e6818e8877178b175ff43d2e6548afad72694aa125f404a7329ece0973 \
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: not sure Dependency Update [File] third_party/python/requirements.txt [Lines] 50-52 [Old Code] attrs==19.1.0 \ --hash=sha256:69c0dbf2ed392de1cb5ec704444b08a5ef81680a61cb899dc08127123af36a79 \ --hash=sha256:f0b870f674851ecbfbbbd364d6b5cbdff9dcedbc7f3f5e18a6891057f21fe399 [Fixed Code] attrs==19.2.0 \ --hash=sha256:ec20e7a4825331c1b5ebf261d111e16fa9612c1f7a5e1f884f12bd53a664dfd2 \ --hash=sha256:f913492e1663d3c36f502e5e9ba6cd13cf19d7fab50aa13239e420fef95e1396 2. Vulnerability Existed: not sure Dependency Update [File] third_party/python/requirements.txt [Lines] 90-92 [Old Code] compare-locales==8.1.0 \ --hash=sha256:286270797ce64f7a2f25e734bb437870661409884a4f0971c0bb94fdad6c1f35 \ --hash=sha256:3d374ff959d5de2cfd5b94caf6b0fa61445f1d8ede5af384002cb3542aacad3a [Fixed Code] compare-locales==8.2.1 \ --hash=sha256:470d50d96c68f8e147daa3d70f29a7b750adefea450c5fa07e0f666c8083d854 \ --hash=sha256:e6a1610151d357e74ee6c1f5e944f1868e449f83e478c84d92f7b86132f721d7 3. Vulnerability Existed: not sure Dependency Update [File] third_party/python/requirements.txt [Lines] 162-164 [Old Code] glean_parser==4.3.1 \ --hash=sha256:a8924a3a4aca7fba35dc69d93031993d6481c6ec9cd43362c068eb3e18ea43e8 \ --hash=sha256:c194aba35a57ff9d139527c5321ef526599794994e355bad4c314bd3ab64c3eb [Fixed Code] glean_parser==4.4.0 \ --hash=sha256:3ae1435b183936a49368806421df27ab944f1802e86a02b38b8e08e53ff0aac5 \ --hash=sha256:948a2b3c81270564a33251fc8ecbfe48bf0549f74bc2d5a8027f6d7b1abae828 4. Vulnerability Existed: not sure Dependency Update [File] third_party/python/requirements.txt [Lines] 418-420 [Old Code] taskcluster-taskgraph==1.1.0 \ --hash=sha256:d3991c71484dfdf102e5479ce71a4e6d43a1889a33bec4aae634c70150cd3f28 \ --hash=sha256:eee145dedd2c12b6404d100ceb6e15a30820b75c8fed587a5cb804d254947153 [Fixed Code] taskcluster-taskgraph==1.1.5 \ --hash=sha256:d55564691d211c550319fae5964d67400b4c1ebd5e8423b2548d48240b8498ad \ --hash=sha256:e162cbefb765fd500166ede24172f4520c0662589b6218586b9eab4cbfeed0da Note: While these are all dependency version updates, I couldn't find specific vulnerability information associated with the old versions being replaced. The updates could be for security fixes, bug fixes, or feature improvements. Without access to the changelogs or security bulletins for these specific packages, I can't confirm if these were security-related updates.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.alpha.1.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.alpha.1.worker.js@@ -13,15 +13,15 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#0f0'; ctx.fillRect(0, 0, 100, 50); ctx.shadowColor = 'rgba(255, 0, 0, 0.01)'; ctx.shadowOffsetY = 50; ctx.fillRect(0, -50, 100, 50);-_assertPixelApprox(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 4);+_assertPixelApprox(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 4); t.done(); });
After analyzing the provided code diff, here's the security analysis:
Vulnerability Existed: no
[Variable Renaming] [testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.alpha.1.worker.js] [Lines 13-21]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixelApprox(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 4);
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixelApprox(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 4);
Additional Details:
The changes in this diff appear to be purely cosmetic, renaming the variable `offscreenCanvas` to `canvas`. There are no security-related changes or vulnerabilities being addressed in this modification. The functionality remains exactly the same, only the variable name has been changed for consistency or readability purposes.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/browser/themes/shared/downloads/allDownloadsView.inc.css+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/themes/shared/downloads/allDownloadsView.inc.css@@ -2,14 +2,9 @@ * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at http://mozilla.org/MPL/2.0/. */-%filter substitution--%define item #downloadsRichListBox > richlistitem-%define itemFocused @item@[selected]- /*** View and outer controls ***/-#downloadsRichListBox {+#downloadsListBox { /** The default listbox appearance comes with an unwanted margin. **/ appearance: none; margin: 0;@@ -17,7 +12,7 @@ /*** List items ***/-@item@ {+#downloadsListBox > richlistitem { height: var(--downloads-item-height); }
Based on the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely stylistic/structural CSS modifications. Here's the analysis:
1. Vulnerability Existed: no
No security vulnerability [browser/themes/shared/downloads/allDownloadsView.inc.css] [Lines 2-12]
Old Code:
```css
%filter substitution
%define item #downloadsRichListBox > richlistitem
%define itemFocused @item@[selected]
#downloadsRichListBox {
```
Fixed Code:
```css
#downloadsListBox {
```
2. Vulnerability Existed: no
No security vulnerability [browser/themes/shared/downloads/allDownloadsView.inc.css] [Lines 17-19]
Old Code:
```css
@item@ {
```
Fixed Code:
```css
#downloadsListBox > richlistitem {
```
The changes involve:
1. Removing substitution variables and macros
2. Renaming the listbox ID from `downloadsRichListBox` to `downloadsListBox`
3. Changing the item selector to be more direct
These appear to be refactoring changes rather than security fixes. No known vulnerabilities are addressed in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/selectors/old-tests/css3-modsel-184d.xml+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/selectors/old-tests/css3-modsel-184d.xml@@ -9,7 +9,6 @@ <link rel="author" title="Lachlan Hunt" href="http://lachy.id.au/about/contact"/> <link rel="help" href="https://www.w3.org/TR/css3-selectors/#selectors"/> <!-- bogus link to make sure it gets found --> <link rel="match" href="css3-modsel-184-ref.xht"/>- <meta name="flags" content="" /> </head> <body> <p class="">This text should be green.</p>
Based on the provided diff, I'll analyze it for security vulnerabilities: Vulnerability Existed: no No Vulnerability Found [File] [Lines 9] [Old Code] <meta name="flags" content="" /> [Fixed Code] (removed line) Additional Details: - This appears to be a simple test file modification removing an empty meta tag - The change doesn't relate to any known security vulnerability - The "flags" meta tag was likely used for test configuration and its removal doesn't impact security - No sensitive data, input handling, or security-relevant functionality was modified No security vulnerabilities were identified in this diff. The change is purely cosmetic/structural, removing an unused meta tag from a test file.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.transparent.source-in.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.transparent.source-in.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = 'rgba(0, 255, 0, 0.5)';@@ -22,7 +22,7 @@ ctx.globalCompositeOperation = 'source-in'; ctx.fillStyle = 'rgba(0, 0, 255, 0.75)'; ctx.fillRect(0, 0, 100, 50);-_assertPixelApprox(offscreenCanvas, 50,25, 0,0,255,96, "50,25", "0,0,255,96", 5);+_assertPixelApprox(canvas, 50,25, 0,0,255,96, "50,25", "0,0,255,96", 5); t.done(); });
Based on the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming for better code clarity. Here's the analysis:
1. Vulnerability Existed: no
No Vulnerability Found [File] [Lines 13-14, 22]
Old Code:
```javascript
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
```
Fixed Code:
```javascript
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
```
2. Vulnerability Existed: no
No Vulnerability Found [File] [Line 22]
Old Code:
```javascript
_assertPixelApprox(offscreenCanvas, 50,25, 0,0,255,96, "50,25", "0,0,255,96", 5);
```
Fixed Code:
```javascript
_assertPixelApprox(canvas, 50,25, 0,0,255,96, "50,25", "0,0,255,96", 5);
```
The changes simply rename the variable `offscreenCanvas` to `canvas` for consistency or readability, without any security implications. The functionality remains exactly the same.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.css-color-4-hsl-8.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.css-color-4-hsl-8.html@@ -17,14 +17,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillStyle = 'hsl(2.0943951024rad, 100.0%, 50.0%)'; ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });
Based on the provided code diff, here's the analysis:
1. Vulnerability Existed: no
No security vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.css-color-4-hsl-8.html [Lines] 17-25
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes appear to be purely variable name refactoring (renaming 'offscreenCanvas' to 'canvas') with no security implications. The functionality remains the same, and there are no security-related patterns being modified in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/thiserror/README.md+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/thiserror/README.md@@ -137,6 +137,20 @@ } ```+- If a field is both a source (named `source`, or has `#[source]` or `#[from]`+ attribute) *and* is marked `#[backtrace]`, then the Error trait's+ `backtrace()` method is forwarded to the source's backtrace.++ ```rust+ #[derive(Error, Debug)]+ pub enum MyError {+ Io {+ #[backtrace]+ source: io::Error,+ },+ }+ ```+ - Errors may use `error(transparent)` to forward the source and Display methods straight through to an underlying error without adding an additional message. This would be appropriate for enums that need an "anything else" variant.
Based on the provided diff, this appears to be documentation changes for the `thiserror` crate in Rust, showing new features rather than security fixes. Here's the analysis: Vulnerability Existed: no [No security vulnerability found] [third_party/rust/thiserror/README.md] [Lines 137-151] [Old Code: Documentation about error forwarding] [Fixed Code: Added documentation about backtrace forwarding and transparent errors] The changes are purely documentation improvements explaining new functionality: 1. How backtrace forwarding works when a field is both a source and marked with `#[backtrace]` 2. Clarification about `error(transparent)` usage No actual code changes or security fixes are present in this diff - it's just documentation updates for new features in the library.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.offset.negativeY.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.offset.negativeY.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -26,8 +26,8 @@ ctx.shadowColor = '#0f0'; ctx.shadowOffsetY = -25; ctx.fillRect(0, 25, 100, 25);-_assertPixel(offscreenCanvas, 50,12, 0,255,0,255, "50,12", "0,255,0,255");-_assertPixel(offscreenCanvas, 50,37, 0,255,0,255, "50,37", "0,255,0,255");+_assertPixel(canvas, 50,12, 0,255,0,255, "50,12", "0,255,0,255");+_assertPixel(canvas, 50,37, 0,255,0,255, "50,37", "0,255,0,255"); t.done(); });
After analyzing the provided code diff, here's the security assessment:
Vulnerability Existed: no
[No vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.offset.negativeY.html] [Lines 17-26]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 50,12, 0,255,0,255, "50,12", "0,255,0,255");
_assertPixel(offscreenCanvas, 50,37, 0,255,0,255, "50,37", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 50,12, 0,255,0,255, "50,12", "0,255,0,255");
_assertPixel(canvas, 50,37, 0,255,0,255, "50,37", "0,255,0,255");
The changes appear to be purely cosmetic/refactoring in nature, simply renaming a variable from `offscreenCanvas` to `canvas`. There are no security-related changes in this diff, no vulnerability fixes, and no changes to the actual functionality or security properties of the code. The changes are limited to variable naming consistency.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/accessible/generic/DocAccessible.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/accessible/generic/DocAccessible.cpp@@ -131,6 +131,7 @@ NS_IMPL_CYCLE_COLLECTION_TRAVERSE(mAccessibleCache) NS_IMPL_CYCLE_COLLECTION_TRAVERSE(mAnchorJumpElm) NS_IMPL_CYCLE_COLLECTION_TRAVERSE(mInvalidationList)+ NS_IMPL_CYCLE_COLLECTION_TRAVERSE(mPendingUpdates) for (const auto& ar : tmp->mARIAOwnsHash.Values()) { for (uint32_t i = 0; i < ar->Length(); i++) { NS_CYCLE_COLLECTION_NOTE_EDGE_NAME(cb, "mARIAOwnsHash entry item");@@ -148,6 +149,7 @@ NS_IMPL_CYCLE_COLLECTION_UNLINK(mAccessibleCache) NS_IMPL_CYCLE_COLLECTION_UNLINK(mAnchorJumpElm) NS_IMPL_CYCLE_COLLECTION_UNLINK(mInvalidationList)+ NS_IMPL_CYCLE_COLLECTION_UNLINK(mPendingUpdates) NS_IMPL_CYCLE_COLLECTION_UNLINK_WEAK_REFERENCE tmp->mARIAOwnsHash.Clear(); NS_IMPL_CYCLE_COLLECTION_UNLINK_END@@ -353,6 +355,14 @@ void DocAccessible::DocType(nsAString& aType) const { dom::DocumentType* docType = mDocumentNode->GetDoctype(); if (docType) docType->GetPublicId(aType);+}++void DocAccessible::QueueCacheUpdate(LocalAccessible* aAcc,+ uint64_t aNewDomain) {+ uint64_t& domain = mQueuedCacheUpdates.LookupOrInsert(aAcc, 0);+ domain |= aNewDomain;++ Controller()->ScheduleProcessing(); } ////////////////////////////////////////////////////////////////////////////////@@ -457,6 +467,7 @@ mAnchorJumpElm = nullptr; mInvalidationList.Clear();+ mPendingUpdates.Clear(); for (auto iter = mAccessibleCache.Iter(); !iter.Done(); iter.Next()) { LocalAccessible* accessible = iter.Data();@@ -930,10 +941,6 @@ ContentRemoved(aChildNode); }-void DocAccessible::MarkForBoundsProcessing(LocalAccessible* aAcc) {- mMaybeBoundsChanged.EnsureInserted(aAcc);-}- void DocAccessible::ParentChainChanged(nsIContent* aContent) {} ////////////////////////////////////////////////////////////////////////////////@@ -1091,7 +1098,7 @@ } }- if (StaticPrefs::accessibility_cache_enabled_AtStartup()) {+ if (mIPCDoc) { mInsertedAccessibles.EnsureInserted(aAccessible); } }@@ -1164,6 +1171,25 @@ mNotificationController->ScheduleContentInsertion(container, list); }+void DocAccessible::ScheduleTreeUpdate(nsIContent* aContent) {+ if (mPendingUpdates.Contains(aContent)) {+ return;+ }+ mPendingUpdates.AppendElement(aContent);+ mNotificationController->ScheduleProcessing();+}++void DocAccessible::ProcessPendingUpdates() {+ auto updates = std::move(mPendingUpdates);+ for (auto update : updates) {+ if (update->GetComposedDoc() != mDocumentNode) {+ continue;+ }+ // The pruning logic will take care of avoiding unnecessary notifications.+ ContentInserted(update, update->GetNextSibling());+ }+}+ bool DocAccessible::PruneOrInsertSubtree(nsIContent* aRoot) { bool insert = false;@@ -1178,7 +1204,7 @@ // then remove their accessibles and subtrees. while (nsIContent* childNode = iter.GetNextChild()) { if (!childNode->GetPrimaryFrame() &&- !nsCoreUtils::IsDisplayContents(childNode)) {+ !nsCoreUtils::CanCreateAccessibleWithoutFrame(childNode)) { ContentRemoved(childNode); } }@@ -1189,7 +1215,7 @@ for (nsIContent* childNode = aRoot->GetFirstChild(); childNode; childNode = childNode->GetNextSibling()) { if (!childNode->GetPrimaryFrame() &&- !nsCoreUtils::IsDisplayContents(childNode)) {+ !nsCoreUtils::CanCreateAccessibleWithoutFrame(childNode)) { ContentRemoved(childNode); } }@@ -1218,7 +1244,7 @@ // As well as removing the a11y subtree, we must also remove Accessibles // for DOM descendants, since some of these might be relocated Accessibles // and their DOM nodes are now hidden as well.- if (!frame && !nsCoreUtils::IsDisplayContents(aRoot)) {+ if (!frame && !nsCoreUtils::CanCreateAccessibleWithoutFrame(aRoot)) { ContentRemoved(aRoot); return false; }@@ -1280,7 +1306,8 @@ } else { // If there is no current accessible, and the node has a frame, or is // display:contents, schedule it for insertion.- if (aRoot->GetPrimaryFrame() || nsCoreUtils::IsDisplayContents(aRoot)) {+ if (aRoot->GetPrimaryFrame() ||+ nsCoreUtils::CanCreateAccessibleWithoutFrame(aRoot)) { // This may be a new subtree, the insertion process will recurse through // its descendants. if (!GetAccessibleOrDescendant(aRoot)) {@@ -1365,16 +1392,19 @@ mInvalidationList.Clear(); }-void DocAccessible::ProcessBoundsChanged() {+void DocAccessible::ProcessQueuedCacheUpdates() { if (!StaticPrefs::accessibility_cache_enabled_AtStartup()) { return; } nsTArray<CacheData> data;- for (auto* acc : mMaybeBoundsChanged) {+ for (auto iter = mQueuedCacheUpdates.Iter(); !iter.Done(); iter.Next()) {+ LocalAccessible* acc = iter.Key();+ uint64_t domain = iter.UserData(); if (!acc->IsDefunct()) {- RefPtr<AccAttributes> fields = acc->BundleFieldsForCache(- CacheDomain::Bounds, CacheUpdateType::Update);+ RefPtr<AccAttributes> fields =+ acc->BundleFieldsForCache(domain, CacheUpdateType::Update);+ if (fields->Count()) { data.AppendElement(CacheData( acc->IsDoc() ? 0 : reinterpret_cast<uint64_t>(acc->UniqueID()),@@ -1383,7 +1413,7 @@ } }- mMaybeBoundsChanged.Clear();+ mQueuedCacheUpdates.Clear(); if (data.Length()) { IPCDoc()->SendCache(CacheUpdateType::Update, data, true);@@ -1391,7 +1421,7 @@ } void DocAccessible::SendAccessiblesWillMove() {- if (!mIPCDoc || !StaticPrefs::accessibility_cache_enabled_AtStartup()) {+ if (!mIPCDoc) { return; } nsTArray<uint64_t> ids;@@ -2322,7 +2352,7 @@ if (curParent == aNewParent) { MOZ_ASSERT(aChild->IndexInParent() != aIdxInParent, "No move case"); curParent->RelocateChild(aIdxInParent, aChild);- if (StaticPrefs::accessibility_cache_enabled_AtStartup()) {+ if (mIPCDoc) { TrackMovedAccessible(aChild); }@@ -2351,7 +2381,7 @@ TreeMutation imut(aNewParent); aNewParent->InsertChildAt(aIdxInParent, aChild);- if (StaticPrefs::accessibility_cache_enabled_AtStartup()) {+ if (mIPCDoc) { TrackMovedAccessible(aChild); } imut.AfterInsertion(aChild);
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: not sure [Memory Leak] [accessible/generic/DocAccessible.cpp] [Lines 131, 148] [Old Code] Missing cycle collection for mPendingUpdates [Fixed Code] Added NS_IMPL_CYCLE_COLLECTION_TRAVERSE(mPendingUpdates) and NS_IMPL_CYCLE_COLLECTION_UNLINK(mPendingUpdates) 2. Vulnerability Existed: not sure [Memory Leak] [accessible/generic/DocAccessible.cpp] [Lines 457] [Old Code] Missing cleanup of mPendingUpdates in ShutdownChildren() [Fixed Code] Added mPendingUpdates.Clear() 3. Vulnerability Existed: not sure [Inconsistent State] [accessible/generic/DocAccessible.cpp] [Lines 1091, 2322, 2351] [Old Code] Checking StaticPrefs::accessibility_cache_enabled_AtStartup() for IPC operations [Fixed Code] Changed to check mIPCDoc instead for IPC operations 4. Vulnerability Existed: not sure [Improper Input Validation] [accessible/generic/DocAccessible.cpp] [Lines 1171-1187] [Old Code] No existing functionality for pending updates processing [Fixed Code] Added ScheduleTreeUpdate() and ProcessPendingUpdates() with proper content validation 5. Vulnerability Existed: not sure [Improper Frame Handling] [accessible/generic/DocAccessible.cpp] [Multiple locations] [Old Code] Using IsDisplayContents() for frame checks [Fixed Code] Changed to use CanCreateAccessibleWithoutFrame() for more comprehensive frame handling Note: While these changes appear to be security-related improvements (memory management, input validation, and state consistency), without more context about the specific threat models and attack vectors, I can't definitively classify them as fixing known vulnerabilities. The changes do improve code robustness and could prevent potential security issues.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/wgpu-hal/src/vulkan/conv.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/wgpu-hal/src/vulkan/conv.rs@@ -698,14 +698,18 @@ } }-pub fn map_stencil_face(face: &wgt::StencilFaceState) -> vk::StencilOpState {+pub fn map_stencil_face(+ face: &wgt::StencilFaceState,+ compare_mask: u32,+ write_mask: u32,+) -> vk::StencilOpState { vk::StencilOpState { fail_op: map_stencil_op(face.fail_op), pass_op: map_stencil_op(face.pass_op), depth_fail_op: map_stencil_op(face.depth_fail_op), compare_op: map_comparison(face.compare),- compare_mask: !0,- write_mask: !0,+ compare_mask,+ write_mask, reference: 0, } }
Here's the analysis of the provided code diff:
Vulnerability Existed: yes
Incorrect Stencil Mask Handling [third_party/rust/wgpu-hal/src/vulkan/conv.rs] [Lines 698-712]
[Old Code]
```rust
pub fn map_stencil_face(face: &wgt::StencilFaceState) -> vk::StencilOpState {
vk::StencilOpState {
fail_op: map_stencil_op(face.fail_op),
pass_op: map_stencil_op(face.pass_op),
depth_fail_op: map_stencil_op(face.depth_fail_op),
compare_op: map_comparison(face.compare),
compare_mask: !0,
write_mask: !0,
reference: 0,
}
}
```
[Fixed Code]
```rust
pub fn map_stencil_face(
face: &wgt::StencilFaceState,
compare_mask: u32,
write_mask: u32,
) -> vk::StencilOpState {
vk::StencilOpState {
fail_op: map_stencil_op(face.fail_op),
pass_op: map_stencil_op(face.pass_op),
depth_fail_op: map_stencil_op(face.depth_fail_op),
compare_op: map_comparison(face.compare),
compare_mask,
write_mask,
reference: 0,
}
}
```
The vulnerability appears to be related to improper stencil buffer handling. The original code was using hardcoded mask values (`!0` which is all bits set) for both compare_mask and write_mask, which could lead to potential security issues in graphics rendering by allowing unrestricted access to stencil buffer operations. The fix introduces proper mask parameters that can be controlled by the caller, allowing for proper access control to stencil buffer operations.
This could potentially be related to:
- Improper Access Control
- Graphics Memory Corruption
- Stencil Buffer Overwrite Vulnerability
However, without more context about the specific security implications in the Vulkan rendering pipeline, I can't provide a more precise vulnerability name. The fix clearly addresses a security concern by making the mask values configurable rather than using a universal full-access pattern.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.lineTo.nonfinite.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.lineTo.nonfinite.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.moveTo(0, 0); ctx.lineTo(100, 0);@@ -29,8 +29,8 @@ ctx.lineTo(0, 50); ctx.fillStyle = '#0f0'; ctx.fill();-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");-_assertPixel(offscreenCanvas, 90,45, 0,255,0,255, "90,45", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 90,45, 0,255,0,255, "90,45", "0,255,0,255"); t.done(); });
Based on the provided diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and corresponding updates to the variable name in the assertions. Here's the analysis following your requested format:
Vulnerability Existed: no
[No security vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.lineTo.nonfinite.worker.js] [Lines 13-29]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
_assertPixel(offscreenCanvas, 90,45, 0,255,0,255, "90,45", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
_assertPixel(canvas, 90,45, 0,255,0,255, "90,45", "0,255,0,255");
The changes are purely cosmetic/refactoring in nature and don't appear to address any security issues. The functionality remains exactly the same, just with a different variable name.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/css-color-adjust/inheritance.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-color-adjust/inheritance.html@@ -10,4 +10,7 @@ </div> <script> assert_inherited('color-scheme', 'normal', 'light dark');+ assert_inherited('color-adjust', 'economy', 'exact');+ assert_inherited('forced-color-adjust', 'auto', 'preserve-parent-color');+ assert_inherited('print-color-adjust', 'economy', 'exact'); </script>
Based on the provided diff, I'll analyze it for potential security vulnerabilities:
1. Vulnerability Existed: no
No specific vulnerability found [File] testing/web-platform/tests/css/css-color-adjust/inheritance.html [Lines 10-13]
[Old Code]
assert_inherited('color-scheme', 'normal', 'light dark');
[Fixed Code]
assert_inherited('color-scheme', 'normal', 'light dark');
assert_inherited('color-adjust', 'economy', 'exact');
assert_inherited('forced-color-adjust', 'auto', 'preserve-parent-color');
assert_inherited('print-color-adjust', 'economy', 'exact');
Analysis: The changes appear to be test case additions for CSS property inheritance testing. There's no indication of security vulnerabilities being fixed - this seems to be adding more test coverage for CSS color adjustment properties. The changes are purely related to testing functionality rather than addressing security issues.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.