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/devtools/client/debugger/src/reducers/tests/quick-open.spec.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/debugger/src/reducers/tests/quick-open.spec.js@@ -2,12 +2,12 @@ * 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/>. */-import update, {- initialQuickOpenState,+import update, { initialQuickOpenState } from "../quick-open";+import { getQuickOpenEnabled, getQuickOpenQuery, getQuickOpenType,-} from "../quick-open";+} from "../../selectors/quick-open"; import { setQuickOpenQuery, openQuickOpen,
Based on the provided code diff, I'll analyze it for security fixes:
Vulnerability Existed: no
No security vulnerability found [File] devtools/client/debugger/src/reducers/tests/quick-open.spec.js [Lines] 2-12
[Old Code]
import update, {
initialQuickOpenState,
getQuickOpenEnabled,
getQuickOpenQuery,
getQuickOpenType,
} from "../quick-open";
[Fixed Code]
import update, { initialQuickOpenState } from "../quick-open";
import {
getQuickOpenEnabled,
getQuickOpenQuery,
getQuickOpenType,
} from "../../selectors/quick-open";
Additional Details:
This appears to be a code organization change rather than a security fix. The modification separates the imports between the reducer functions (update and initialQuickOpenState) and selector functions (getQuickOpenEnabled, etc.), moving the selectors to their proper location in the selectors directory. There's no indication of any security vulnerability being addressed in this change.
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.arcTo.ensuresubpath.2.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.arcTo.ensuresubpath.2.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 = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -24,7 +24,7 @@ ctx.arcTo(0, 25, 50, 250, 0.1); // adds (x1,y1), draws nothing ctx.lineTo(100, 25); ctx.stroke();-_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 diff, I'll analyze it for security vulnerabilities:
1. Vulnerability Existed: no
Variable Renaming [File] [Lines 13-14, 24]
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
Variable Renaming [File] [Line 24]
Old Code:
```javascript
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
```
Fixed Code:
```javascript
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
```
The changes appear to be purely cosmetic, renaming the variable `offscreenCanvas` to `canvas` for consistency or clarity. There are no apparent security vulnerabilities being fixed in this diff. The functionality remains exactly the same, only the variable name has changed.
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-contain/contain-paint-clip-017.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-contain/contain-paint-clip-017.html@@ -30,7 +30,6 @@ -->- <meta content="" name="flags"> <style> div
Let me analyze the code diff for potential security vulnerabilities. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/css/css-contain/contain-paint-clip-017.html [Lines] 30 [Old Code] <meta content="" name="flags"> [Fixed Code] (removed) Additional Details: 1. The change simply removes an empty meta tag with a 'flags' attribute, which appears to be test-related metadata. 2. This doesn't appear to be a security fix but rather a cleanup of test configuration. 3. No known vulnerability patterns (XSS, injection, etc.) are present in this change. 4. The 'flags' meta tag doesn't appear to have any security implications in this context.
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.invalid.hsl-2.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.invalid.hsl-2.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 = '#0f0'; try { ctx.fillStyle = 'hsl(z, 100%, 50%)'; } catch (e) { } // this shouldn't throw, but it shouldn't matter here if it does 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:
Vulnerability Existed: no
No specific vulnerability [File] [Lines 17-25]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
ctx.fillStyle = '#0f0';
try { ctx.fillStyle = 'hsl(z, 100%, 50%)'; } catch (e) { }
ctx.fillRect(0, 0, 100, 50);
_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');
ctx.fillStyle = '#0f0';
try { ctx.fillStyle = 'hsl(z, 100%, 50%)'; } catch (e) { }
ctx.fillRect(0, 0, 100, 50);
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes appear to be purely cosmetic/refactoring (variable name change from `offscreenCanvas` to `canvas` and corresponding updates to references). There's no indication of any security vulnerability being fixed in this diff. The test's functionality remains the same, just with a renamed variable.
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/gfx/webrender_bindings/RenderThread.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/gfx/webrender_bindings/RenderThread.cpp@@ -35,6 +35,7 @@ # include "GLLibraryEGL.h" # include "mozilla/widget/WinCompositorWindowThread.h" # include "mozilla/gfx/DeviceManagerDx.h"+# include "mozilla/webrender/DCLayerTree.h" //# include "nsWindowsHelpers.h" //# include <d3d11.h> #endif@@ -156,6 +157,15 @@ MOZ_ASSERT(IsInRenderThread()); LOG("RenderThread::ShutDownTask()");+ {+ // Clear RenderTextureHosts+ MutexAutoLock lock(mRenderTextureMapLock);+ mRenderTexturesDeferred.clear();+ mRenderTextures.clear();+ mSyncObjectNeededRenderTextures.clear();+ mRenderTextureOps.clear();+ }+ // Let go of our handle to the (internally ref-counted) thread pool. mThreadPool.Release(); mThreadPoolLP.Release();@@ -163,6 +173,10 @@ // Releasing on the render thread will allow us to avoid dispatching to remove // remaining textures from the texture map. layers::SharedSurfacesParent::ShutdownRenderThread();++#ifdef XP_WIN+ DCLayerTree::Shutdown();+#endif ClearAllBlobImageResources(); ClearSingletonGL();@@ -858,7 +872,22 @@ void RenderThread::HandleDeviceReset(const char* aWhere, GLenum aReason) { MOZ_ASSERT(IsInRenderThread());+ // This happens only on simulate device reset. if (aReason == LOCAL_GL_NO_ERROR) {+ MOZ_ASSERT(XRE_IsGPUProcess());++ if (!mHandlingDeviceReset) {+ mHandlingDeviceReset = true;++ MutexAutoLock lock(mRenderTextureMapLock);+ mRenderTexturesDeferred.clear();+ for (const auto& entry : mRenderTextures) {+ entry.second->ClearCachedResources();+ }+ // Simulate DeviceReset does not need to notify the device reset to+ // GPUProcessManager. It is already done by+ // GPUProcessManager::SimulateDeviceReset().+ } return; }
Here's the analysis of the provided code diff for security fixes:
1. Vulnerability Existed: not sure
Resource Cleanup on Shutdown [File] gfx/webrender_bindings/RenderThread.cpp [Lines 156-173]
[Old Code]
```cpp
// No explicit cleanup of render textures before
```
[Fixed Code]
```cpp
{
// Clear RenderTextureHosts
MutexAutoLock lock(mRenderTextureMapLock);
mRenderTexturesDeferred.clear();
mRenderTextures.clear();
mSyncObjectNeededRenderTextures.clear();
mRenderTextureOps.clear();
}
```
2. Vulnerability Existed: not sure
Windows-specific Resource Cleanup [File] gfx/webrender_bindings/RenderThread.cpp [Lines 173-176]
[Old Code]
```cpp
// No DCLayerTree shutdown
```
[Fixed Code]
```cpp
#ifdef XP_WIN
DCLayerTree::Shutdown();
#endif
```
3. Vulnerability Existed: not sure
Device Reset Handling Improvement [File] gfx/webrender_bindings/RenderThread.cpp [Lines 858-872]
[Old Code]
```cpp
if (aReason == LOCAL_GL_NO_ERROR) {
return;
}
```
[Fixed Code]
```cpp
if (aReason == LOCAL_GL_NO_ERROR) {
MOZ_ASSERT(XRE_IsGPUProcess());
if (!mHandlingDeviceReset) {
mHandlingDeviceReset = true;
MutexAutoLock lock(mRenderTextureMapLock);
mRenderTexturesDeferred.clear();
for (const auto& entry : mRenderTextures) {
entry.second->ClearCachedResources();
}
}
return;
}
```
Note: While these changes appear to be resource management improvements that could potentially prevent memory leaks or resource exhaustion, I cannot definitively identify specific named vulnerabilities being fixed. The changes seem focused on proper cleanup during shutdown and device reset scenarios, which could be security-relevant but don't clearly map to known vulnerability types.
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/pixel-manipulation/2d.imageData.put.dirty.zero.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/pixel-manipulation/2d.imageData.put.dirty.zero.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,7 +26,7 @@ ctx.fillStyle = '#0f0'; ctx.fillRect(0, 0, 100, 50) ctx.putImageData(imgdata, 0, 0, 0, 0, 0, 0);-_assertPixelApprox(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2);+_assertPixelApprox(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2); t.done(); });
Based on the provided diff, I'll analyze it for security vulnerabilities:
1. Vulnerability Existed: no
Variable Renaming [File: testing/web-platform/tests/html/canvas/offscreen/pixel-manipulation/2d.imageData.put.dirty.zero.html] [Lines: 17-18, 26]
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", 2);
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", 2);
Additional Details:
- This appears to be a simple variable renaming from `offscreenCanvas` to `canvas` for consistency or readability.
- No security vulnerabilities are addressed in this change.
- The functionality remains exactly the same, only the variable name is changed.
- The test assertion and all other operations remain identical in their effect.
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.worker.js+++ /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.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 = '#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(); });
Based on the provided code diff, I'll analyze it for potential security vulnerabilities:
1. Vulnerability Existed: no
No specific vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.clearRect.transform.worker.js [Lines] 13-24
[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 appear to be purely cosmetic, renaming the variable from `offscreenCanvas` to `canvas` for consistency or readability. There are no security-related changes or vulnerability fixes in this diff. 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/CSS2/visudet/line-height-201.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/CSS2/visudet/line-height-201.html@@ -4,7 +4,6 @@ <link rel="author" title="Florian Rivoal" href="https://florian.rivoal.net"> <link rel="help" href="https://drafts.csswg.org/css2/visudet.html#line-height"> <link rel="match" href="reference/line-height-201-ref.html">-<meta name="flags" content=""> <meta name="assert" content="non-normal values of line-height result in the height of the inline-level box to be exactly the specified dimention, even when fallback fonts with metrics different from the first available font one are used."> <style>
Analysis of the provided code diff: 1. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/css/CSS2/visudet/line-height-201.html [Lines] 4 [Old Code] <meta name="flags" content=""> [Fixed Code] (removed line) Additional Details: This appears to be a simple removal of an empty meta tag that wasn't serving any purpose. There's no security implication to this change, just a cleanup of unnecessary code. 2. Vulnerability Existed: not sure Potential HTML Meta Tag Issue [File] testing/web-platform/tests/css/CSS2/visudet/line-height-201.html [Lines] 4 [Old Code] <meta name="flags" content=""> [Fixed Code] (removed line) Additional Details: While this doesn't appear to be a security fix, there's a slight possibility that removing an empty meta tag could affect how the page is processed by some parsers or tools. However, this is unlikely to have any security impact. The change is more likely related to test standardization.
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.rect.zero.6.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.rect.zero.6.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 = '#0f0'; ctx.fillRect(0, 0, 100, 50);@@ -25,7 +25,7 @@ ctx.beginPath(); ctx.rect(100, 25, 1000, 0); ctx.stroke();-_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 diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming and don't involve any security-sensitive operations. Here's the analysis:
1. Vulnerability Existed: no
Variable Renaming [testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.rect.zero.6.worker.js] [Lines 13-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 simply rename the variable `offscreenCanvas` to `canvas` and update all references to it. There are no security implications to these changes. The functionality remains exactly the same, only the variable name has been made more concise.
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.fill.maxWidth.zero.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.fill.maxWidth.zero.worker.js@@ -14,8 +14,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 = '#0f0'; ctx.fillRect(0, 0, 100, 50);
Analyzing the provided code diff:
1. Vulnerability Existed: no
No security vulnerability found [File] [Lines 14-15]
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`. This doesn't appear to be a security-related fix but rather a code style/consistency change. No security 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/html/canvas/offscreen/compositing/2d.composite.uncovered.image.source-out.html+++ /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.uncovered.image.source-out.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 = 'rgba(0, 255, 255, 0.5)';@@ -36,8 +36,8 @@ promise.then(function(response) { createImageBitmap(response).then(bitmap => { ctx.drawImage(bitmap, 40, 40, 10, 10, 40, 50, 10, 10);- _assertPixelApprox(offscreenCanvas, 15,15, 0,0,0,0, "15,15", "0,0,0,0", 5);- _assertPixelApprox(offscreenCanvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0", 5);+ _assertPixelApprox(canvas, 15,15, 0,0,0,0, "15,15", "0,0,0,0", 5);+ _assertPixelApprox(canvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0", 5); }, t_fail); }).then(t_pass, t_fail);
After analyzing the provided code diff, here's the security assessment:
1. Vulnerability Existed: no
No specific vulnerability found [File] [Lines 17-18, 36-37]
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: This appears to be a simple variable renaming from 'offscreenCanvas' to 'canvas' with no security implications.
2. Vulnerability Existed: no
No specific vulnerability found [File] [Lines 38-39]
Old Code:
_assertPixelApprox(offscreenCanvas, 15,15, 0,0,0,0, "15,15", "0,0,0,0", 5);
_assertPixelApprox(offscreenCanvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0", 5);
Fixed Code:
_assertPixelApprox(canvas, 15,15, 0,0,0,0, "15,15", "0,0,0,0", 5);
_assertPixelApprox(canvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0", 5);
Additional Details: These changes are simply updates to reflect the variable name change and don't indicate any security fixes.
The changes in this diff appear to be purely cosmetic (variable renaming) with no security-related fixes. The functionality remains the same, just with a different variable name. No vulnerabilities were identified in these changes.
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.stroke.join.2.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.stroke.join.2.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, 50, 50);@@ -34,10 +34,10 @@ ctx.lineTo(-150, -50); ctx.lineTo(-151, -100); ctx.stroke();-_assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 48,48, 0,255,0,255, "48,48", "0,255,0,255");-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");-_assertPixel(offscreenCanvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255");+_assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");+_assertPixel(canvas, 48,48, 0,255,0,255, "48,48", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255"); t.done(); });
After analyzing the provided code diff, here are the findings:
1. Vulnerability Existed: no
No security vulnerability found
File: testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.stroke.join.2.html
Lines: 17-18, 34-37
Old Code:
```javascript
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");
_assertPixel(offscreenCanvas, 48,48, 0,255,0,255, "48,48", "0,255,0,255");
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
_assertPixel(offscreenCanvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255");
```
Fixed Code:
```javascript
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");
_assertPixel(canvas, 48,48, 0,255,0,255, "48,48", "0,255,0,255");
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
_assertPixel(canvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255");
```
The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) with no security implications. The functionality remains exactly the same, just with a different variable name. No security vulnerabilities were identified 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/tools/lint/eslint/eslint-plugin-mozilla/lib/processors/xul.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/tools/lint/eslint/eslint-plugin-mozilla/lib/processors/xul.js@@ -140,10 +140,6 @@ function recursiveExpand(node) { for (let [attr, value] of Object.entries(node.attributes)) { if (attr.startsWith("on")) {- if (attr == "oncommand" && value == ";") {- // Ignore these, see bug 371900 for why people might do this.- continue;- } // Ignore dashes in the tag name let nodeDesc = node.local.replace(/-/g, ""); if (node.attributes.id) {
Analyzing the provided code diff, here's the security assessment:
Vulnerability Existed: not sure
[Potential Event Handler Validation Bypass] [tools/lint/eslint/eslint-plugin-mozilla/lib/processors/xul.js] [Lines 140-143]
[Old Code]
if (attr == "oncommand" && value == ";") {
// Ignore these, see bug 371900 for why people might do this.
continue;
}
[Fixed Code]
[Removed entirely]
Additional Details:
1. The removed code was previously ignoring empty oncommand handlers (value == ";")
2. The removal suggests stricter validation of event handlers in XUL processing
3. Without more context about bug 371900, it's unclear if this was a security fix or just a code cleanup
4. The change could potentially prevent bypassing event handler validation, but we can't be certain without knowing the original bug's details
Note: This appears to be part of Firefox's internal linting rules for XUL, so the security impact would be on developer workflows rather than direct runtime 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/services/settings/dumps/blocklists/addons-bloomfilters.json+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/services/settings/dumps/blocklists/addons-bloomfilters.json@@ -1,5 +1,229 @@ { "data": [+ {+ "stash": {+ "blocked": [+ "sp@FindingFormsPro:2.0.0",+ "sp@SpeedCheckerPlus:3.0.0",+ "sp@FindingFormsPro:1.0.7",+ "sp@FindingFormsPro:1.0.3",+ "sp@FindingFormsPro:1.0.6",+ "sp@QuickEmailAccess:2.0.1",+ "sp@FindingFormsPro:2.0.1",+ "sp@FindingFormsPro:1.0.5",+ "sp@SpeedCheckerPlus:1.0.1",+ "sp@FindingFormsPro:1.0.0",+ "sp@QuickEmailAccess:2.0.0",+ "sp@QuickEmailAccess:3.0.0",+ "sp@FindingFormsPro:1.0.2",+ "sp@QuickEmailAccess:1.0.0",+ "sp@SpeedCheckerPlus:1.0.0",+ "sp@FindingFormsPro:1.0.4",+ "sp@FindingFormsPro:3.0.0"+ ],+ "unblocked": []+ },+ "schema": 1647974297042,+ "key_format": "{guid}:{version}",+ "stash_time": 1648060508100,+ "id": "91ab65c0-df4a-4cb0-a9a8-d8dd072733ba",+ "last_modified": 1648060697453+ },+ {+ "stash": {+ "blocked": [+ "{5071465d-c5af-4d4a-acc9-219299efc0f1}:1.2.0"+ ],+ "unblocked": []+ },+ "schema": 1647867559284,+ "key_format": "{guid}:{version}",+ "stash_time": 1647974107196,+ "id": "be326ebf-52dc-424c-80ce-6d0101bb368f",+ "last_modified": 1647974296987+ },+ {+ "stash": {+ "blocked": [+ "[email protected]:2.218.7700",+ "[email protected]:2.210.7353",+ "[email protected]:2.236.8012",+ "[email protected]:2.237.8018",+ "[email protected]:2.216.7560",+ "[email protected]:2.220.7818",+ "[email protected]:2.234.7980",+ "[email protected]:3.0.32",+ "[email protected]:2.218.7669",+ "[email protected]:3.0.2",+ "[email protected]:2.235.7991",+ "[email protected]:2.200.6884",+ "[email protected]:2.198.6718",+ "[email protected]:2.208.7282",+ "[email protected]:2.211.7392",+ "[email protected]:3.0.27",+ "[email protected]:2.225.7869",+ "[email protected]:2.202.7041",+ "[email protected]:2.232.7959",+ "[email protected]:2.208.7289",+ "[email protected]:4.0.52",+ "[email protected]:2.215.7447",+ "[email protected]:3.0.16",+ "[email protected]:2.204.7103",+ "[email protected]:2.220.7791",+ "[email protected]:2.216.7581",+ "[email protected]:2.208.7298",+ "[email protected]:2.201.6961",+ "[email protected]:2.198.6588",+ "[email protected]:2.216.7528",+ "[email protected]:2.229.7912",+ "[email protected]:2.216.7574",+ "[email protected]:2.216.7455",+ "[email protected]:2.203.7079",+ "[email protected]:3.0.7",+ "[email protected]:2.235.7986",+ "[email protected]:2.209.7319",+ "[email protected]:3.0.22",+ "[email protected]:2.206.7237",+ "[email protected]:3.0.8",+ "[email protected]:2.214.7440",+ "[email protected]:3.0.3",+ "[email protected]:2.213.7420",+ "[email protected]:2.199.6780",+ "[email protected]:2.210.7376",+ "[email protected]:2.225.7888",+ "[email protected]:2.210.7362",+ "[email protected]:2.220.7741",+ "[email protected]:2.209.7351"+ ],+ "unblocked": []+ },+ "schema": 1647603683249,+ "key_format": "{guid}:{version}",+ "stash_time": 1647606908120,+ "id": "448ec411-adff-458d-9e00-a31dd423e410",+ "last_modified": 1647607093105+ },+ {+ "stash": {+ "blocked": [+ "[email protected]:2.13.1",+ "[email protected]:2.7.0",+ "[email protected]:2.7.3",+ "[email protected]:2.8.0",+ "{78db226a-5912-4e93-9131-9451cf39e549}:0.0.1",+ "[email protected]:2.14.2",+ "[email protected]:2.7.1"+ ],+ "unblocked": []+ },+ "schema": 1647434307680,+ "key_format": "{guid}:{version}",+ "stash_time": 1647455708203,+ "id": "882bdc6e-d8ea-42d8-8c8c-17e13cff2341",+ "last_modified": 1647455905378+ },+ {+ "stash": {+ "blocked": [],+ "unblocked": []+ },+ "schema": 1647348483409,+ "key_format": "{guid}:{version}",+ "stash_time": 1647434108889,+ "id": "ec2716c4-9649-4782-93b5-4e66d0793e0e",+ "last_modified": 1647434307625+ },+ {+ "stash": {+ "blocked": [+ "{cdef9c8a-fa00-4334-91c8-54a7d2424765}:1.0",+ "{d2c01590-0add-481e-a2e2-673339d62fd3}:0.4",+ "{07971367-aaa1-47e7-bff1-d80c6c8ce8ba}:0.6",+ "{972f4d17-e8c7-44da-bffa-abe57b238a69}:0.2",+ "{ee4fecd3-2e71-4517-bf26-500446b09d20}:1.0.2"+ ],+ "unblocked": []+ },+ "schema": 1647281954531,+ "key_format": "{guid}:{version}",+ "stash_time": 1647347707957,+ "id": "db2685c9-b525-460a-931b-78d95acc843e",+ "last_modified": 1647347904463+ },+ {+ "stash": {+ "blocked": [+ "{45bd75b9-f91d-439c-a265-f18a23fdcc23}:1.1",+ "{45bd75b9-f91d-439c-a265-f18a23fdcc23}:0.1",+ "{9eb47e6e-8134-4b2a-afcf-cefd687c5078}:0.1",+ "{a53eff1b-c95c-4297-8ac1-66d60268f391}:1.6",+ "{1ec030d6-8456-475d-98af-4e88a4a993c1}:1.5",+ "{45bd75b9-f91d-439c-a265-f18a23fdcc23}:1.4.3",+ "{9eb47e6e-8134-4b2a-afcf-cefd687c5078}:1.4.2",+ "{9eb47e6e-8134-4b2a-afcf-cefd687c5078}:1.0",+ "{a53eff1b-c95c-4297-8ac1-66d60268f391}:1.4.3",+ "{45bd75b9-f91d-439c-a265-f18a23fdcc23}:1.4.2",+ "{6a3ca6be-f683-4a0f-920f-6308f194fb77}:1.4",+ "{a53eff1b-c95c-4297-8ac1-66d60268f391}:0.1",+ "{1ec030d6-8456-475d-98af-4e88a4a993c1}:1.3",+ "{1ec030d6-8456-475d-98af-4e88a4a993c1}:1.4.3",+ "{426e96a3-12d2-4c45-8b26-3f3a0b5ffe2e}:0.1",+ "{426e96a3-12d2-4c45-8b26-3f3a0b5ffe2e}:1.5",+ "{45bd75b9-f91d-439c-a265-f18a23fdcc23}:1.3",+ "{9eb47e6e-8134-4b2a-afcf-cefd687c5078}:1.4",+ "{a53eff1b-c95c-4297-8ac1-66d60268f391}:1.4",+ "{9eb47e6e-8134-4b2a-afcf-cefd687c5078}:1.3",+ "{6a3ca6be-f683-4a0f-920f-6308f194fb77}:0.1",+ "{426e96a3-12d2-4c45-8b26-3f3a0b5ffe2e}:1.0",+ "{a53eff1b-c95c-4297-8ac1-66d60268f391}:1.7",+ "{a53eff1b-c95c-4297-8ac1-66d60268f391}:1.3",+ "{9eb47e6e-8134-4b2a-afcf-cefd687c5078}:1.5",+ "{6a3ca6be-f683-4a0f-920f-6308f194fb77}:1.4.3",+ "{426e96a3-12d2-4c45-8b26-3f3a0b5ffe2e}:1.3",+ "{6a3ca6be-f683-4a0f-920f-6308f194fb77}:1.5",+ "{a53eff1b-c95c-4297-8ac1-66d60268f391}:1.0",+ "{426e96a3-12d2-4c45-8b26-3f3a0b5ffe2e}:1.4.3",+ "{45bd75b9-f91d-439c-a265-f18a23fdcc23}:1.5",+ "{a53eff1b-c95c-4297-8ac1-66d60268f391}:1.4.2",+ "{6a3ca6be-f683-4a0f-920f-6308f194fb77}:1.4.2",+ "{426e96a3-12d2-4c45-8b26-3f3a0b5ffe2e}:1.4",+ "{1ec030d6-8456-475d-98af-4e88a4a993c1}:1.4.2",+ "{1ec030d6-8456-475d-98af-4e88a4a993c1}:1.4",+ "{a53eff1b-c95c-4297-8ac1-66d60268f391}:1.5",+ "{6a3ca6be-f683-4a0f-920f-6308f194fb77}:1.3",+ "{9eb47e6e-8134-4b2a-afcf-cefd687c5078}:1.4.1",+ "{6a3ca6be-f683-4a0f-920f-6308f194fb77}:1.6",+ "{9eb47e6e-8134-4b2a-afcf-cefd687c5078}:1.4.3",+ "{45bd75b9-f91d-439c-a265-f18a23fdcc23}:1.4",+ "{1ec030d6-8456-475d-98af-4e88a4a993c1}:0.1",+ "{426e96a3-12d2-4c45-8b26-3f3a0b5ffe2e}:1.4.2",+ "{1ec030d6-8456-475d-98af-4e88a4a993c1}:1.0",+ "{6a3ca6be-f683-4a0f-920f-6308f194fb77}:1.0"+ ],+ "unblocked": []+ },+ "schema": 1646159885182,+ "key_format": "{guid}:{version}",+ "stash_time": 1646699708531,+ "id": "80195a0a-8483-4d69-a90c-9a5c6fc0a1e5",+ "last_modified": 1646699899029+ },+ {+ "stash": {+ "blocked": [+ "{44a402f4-c627-4ecb-87c4-5fe5d0599047}:10.0.1",+ "{83e2015a-e472-4351-a409-eab977a62bb6}:4.0.0",+ "{bdd06799-956a-4228-9688-6a6bb3969d04}:1.0.0",+ "{6111770a-21eb-40a1-8022-39d7acedb2f0}:0.5.0"+ ],+ "unblocked": []+ },+ "schema": 1646152603459,+ "key_format": "{guid}:{version}",+ "stash_time": 1646159708703,+ "id": "2efbeab7-0e69-4aeb-b0c1-e51a962487b3",+ "last_modified": 1646159885129+ }, { "stash": { "blocked": [
Looking at the diff, this appears to be an update to Firefox's add-on blocklist. The changes show numerous malicious or vulnerable add-ons being added to the blocklist, but I don't see any actual security vulnerabilities in the code itself - this is security-related configuration rather than vulnerable code.
Here's my analysis:
Vulnerability Existed: no
Add-on Blocklist Update [File] [Lines 1-229]
[Old Code]
{
"data": [
{
"stash": {
"blocked": [],
[Fixed Code]
{
"data": [
{
"stash": {
"blocked": [
"sp@FindingFormsPro:2.0.0",
"sp@SpeedCheckerPlus:3.0.0",
... (many more blocked add-ons)
Additional Details:
This is not a vulnerability fix but rather a security enhancement where Mozilla has updated their blocklist to protect users from known malicious or vulnerable browser extensions. The diff shows hundreds of new extensions being added to the blocklist across multiple categories. This is standard security maintenance rather than fixing a specific vulnerability in the code.
No actual code vulnerabilities were fixed in this diff - it's purely a blocklist update to protect users from bad extensions.
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.roundrect.4.radii.3.double.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.roundrect.4.radii.3.double.worker.js@@ -13,18 +13,18 @@ }); 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.roundRect(0, 0, 100, 50, [0, 0, 20, 0]); ctx.fillStyle = '#0f0'; ctx.fill();-_assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 98,48, 255,0,0,255, "98,48", "255,0,0,255");-_assertPixel(offscreenCanvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");+_assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");+_assertPixel(canvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");+_assertPixel(canvas, 98,48, 255,0,0,255, "98,48", "255,0,0,255");+_assertPixel(canvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255"); t.done(); });
Analyzing the provided code diff, here's the security assessment: 1. Vulnerability Existed: no The diff shows only a variable name change from `offscreenCanvas` to `canvas` and updates to the corresponding variable references in the `_assertPixel` calls. There are no security vulnerabilities being fixed here - this appears to be purely a code style/readability change. No security vulnerabilities were identified in this diff. The changes are: - Variable renamed from `offscreenCanvas` to `canvas` - All references to the variable updated accordingly - No functional changes to the actual canvas operations or assertions The modification doesn't address any security issues but rather improves code consistency. The test continues to perform the same canvas operations and pixel validations as before.
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/crossbeam-utils/src/atomic/atomic_cell.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/crossbeam-utils/src/atomic/atomic_cell.rs@@ -295,7 +295,7 @@ } macro_rules! impl_arithmetic {- ($t:ty, $example:tt) => {+ ($t:ty, fallback, $example:tt) => { impl AtomicCell<$t> { /// Increments the current value by `val` and returns the previous value. ///@@ -313,10 +313,13 @@ /// ``` #[inline] pub fn fetch_add(&self, val: $t) -> $t {- if can_transmute::<$t, atomic::AtomicUsize>() {- let a = unsafe { &*(self.value.get() as *const atomic::AtomicUsize) };- a.fetch_add(val as usize, Ordering::AcqRel) as $t- } else {+ #[cfg(crossbeam_loom)]+ {+ let _ = val;+ unimplemented!("loom does not support non-atomic atomic ops");+ }+ #[cfg(not(crossbeam_loom))]+ { let _guard = lock(self.value.get() as usize).write(); let value = unsafe { &mut *(self.value.get()) }; let old = *value;@@ -341,10 +344,13 @@ /// ``` #[inline] pub fn fetch_sub(&self, val: $t) -> $t {- if can_transmute::<$t, atomic::AtomicUsize>() {- let a = unsafe { &*(self.value.get() as *const atomic::AtomicUsize) };- a.fetch_sub(val as usize, Ordering::AcqRel) as $t- } else {+ #[cfg(crossbeam_loom)]+ {+ let _ = val;+ unimplemented!("loom does not support non-atomic atomic ops");+ }+ #[cfg(not(crossbeam_loom))]+ { let _guard = lock(self.value.get() as usize).write(); let value = unsafe { &mut *(self.value.get()) }; let old = *value;@@ -367,10 +373,13 @@ /// ``` #[inline] pub fn fetch_and(&self, val: $t) -> $t {- if can_transmute::<$t, atomic::AtomicUsize>() {- let a = unsafe { &*(self.value.get() as *const atomic::AtomicUsize) };- a.fetch_and(val as usize, Ordering::AcqRel) as $t- } else {+ #[cfg(crossbeam_loom)]+ {+ let _ = val;+ unimplemented!("loom does not support non-atomic atomic ops");+ }+ #[cfg(not(crossbeam_loom))]+ { let _guard = lock(self.value.get() as usize).write(); let value = unsafe { &mut *(self.value.get()) }; let old = *value;@@ -393,10 +402,13 @@ /// ``` #[inline] pub fn fetch_or(&self, val: $t) -> $t {- if can_transmute::<$t, atomic::AtomicUsize>() {- let a = unsafe { &*(self.value.get() as *const atomic::AtomicUsize) };- a.fetch_or(val as usize, Ordering::AcqRel) as $t- } else {+ #[cfg(crossbeam_loom)]+ {+ let _ = val;+ unimplemented!("loom does not support non-atomic atomic ops");+ }+ #[cfg(not(crossbeam_loom))]+ { let _guard = lock(self.value.get() as usize).write(); let value = unsafe { &mut *(self.value.get()) }; let old = *value;@@ -419,10 +431,13 @@ /// ``` #[inline] pub fn fetch_xor(&self, val: $t) -> $t {- if can_transmute::<$t, atomic::AtomicUsize>() {- let a = unsafe { &*(self.value.get() as *const atomic::AtomicUsize) };- a.fetch_xor(val as usize, Ordering::AcqRel) as $t- } else {+ #[cfg(crossbeam_loom)]+ {+ let _ = val;+ unimplemented!("loom does not support non-atomic atomic ops");+ }+ #[cfg(not(crossbeam_loom))]+ { let _guard = lock(self.value.get() as usize).write(); let value = unsafe { &mut *(self.value.get()) }; let old = *value;@@ -541,9 +556,15 @@ impl_arithmetic!(u64, atomic::AtomicU64, "let a = AtomicCell::new(7u64);"); #[cfg(not(crossbeam_no_atomic_64))] impl_arithmetic!(i64, atomic::AtomicI64, "let a = AtomicCell::new(7i64);");+#[cfg(crossbeam_no_atomic_64)]+impl_arithmetic!(u64, fallback, "let a = AtomicCell::new(7u64);");+#[cfg(crossbeam_no_atomic_64)]+impl_arithmetic!(i64, fallback, "let a = AtomicCell::new(7i64);"); // TODO: AtomicU128 is unstable // impl_arithmetic!(u128, atomic::AtomicU128, "let a = AtomicCell::new(7u128);"); // impl_arithmetic!(i128, atomic::AtomicI128, "let a = AtomicCell::new(7i128);");+impl_arithmetic!(u128, fallback, "let a = AtomicCell::new(7u128);");+impl_arithmetic!(i128, fallback, "let a = AtomicCell::new(7i128);"); impl_arithmetic!( usize,@@ -683,105 +704,13 @@ // stored at addresses that are multiples of 3. It'd be too bad if `LEN` was divisible by 3. // In order to protect from such cases, we simply choose a large prime number for `LEN`. const LEN: usize = 97;-+ #[allow(clippy::declare_interior_mutable_const)]+ const L: SeqLock = SeqLock::new(); static LOCKS: [SeqLock; LEN] = [- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),- SeqLock::new(),+ L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L,+ L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L,+ L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L, L,+ L, L, L, L, L, L, L, ]; // If the modulus is a constant number, the compiler will use crazy math to transform this into@@ -833,7 +762,6 @@ ($t:ty, $a:ident, $atomic_op:expr, $fallback_op:expr) => { loop { atomic!(@check, $t, AtomicUnit, $a, $atomic_op);- atomic!(@check, $t, atomic::AtomicUsize, $a, $atomic_op); atomic!(@check, $t, atomic::AtomicU8, $a, $atomic_op); atomic!(@check, $t, atomic::AtomicU16, $a, $atomic_op);@@ -855,7 +783,6 @@ const fn atomic_is_lock_free<T>() -> bool { // HACK(taiki-e): This is equivalent to `atomic! { T, _a, true, false }`, but can be used in const fn even in Rust 1.36. let is_lock_free = can_transmute::<T, AtomicUnit>()- | can_transmute::<T, atomic::AtomicUsize>() | can_transmute::<T, atomic::AtomicU8>() | can_transmute::<T, atomic::AtomicU16>() | can_transmute::<T, atomic::AtomicU32>();
Here's the analysis of the provided code diff for security fixes:
1. Vulnerability Existed: yes
Race Condition in Atomic Operations [third_party/rust/crossbeam-utils/src/atomic/atomic_cell.rs] [295-431]
[Old Code]
```rust
if can_transmute::<$t, atomic::AtomicUsize>() {
let a = unsafe { &*(self.value.get() as *const atomic::AtomicUsize) };
a.fetch_add(val as usize, Ordering::AcqRel) as $t
} else {
let _guard = lock(self.value.get() as usize).write();
let value = unsafe { &mut *(self.value.get()) };
let old = *value;
*value = value.wrapping_add(val);
old
}
```
[Fixed Code]
```rust
#[cfg(crossbeam_loom)]
{
let _ = val;
unimplemented!("loom does not support non-atomic atomic ops");
}
#[cfg(not(crossbeam_loom))]
{
let _guard = lock(self.value.get() as usize).write();
let value = unsafe { &mut *(self.value.get()) };
let old = *value;
*value = value.wrapping_add(val);
old
}
```
The old code had potential race conditions when transmuting to AtomicUsize, which could lead to undefined behavior. The new code removes this unsafe transmutation and consistently uses locking mechanisms.
2. Vulnerability Existed: yes
Inconsistent Atomic Operations for 64-bit Types [third_party/rust/crossbeam-utils/src/atomic/atomic_cell.rs] [541-559]
[Old Code]
```rust
impl_arithmetic!(u64, atomic::AtomicU64, "let a = AtomicCell::new(7u64);");
#[cfg(not(crossbeam_no_atomic_64))]
impl_arithmetic!(i64, atomic::AtomicI64, "let a = AtomicCell::new(7i64);");
```
[Fixed Code]
```rust
#[cfg(crossbeam_no_atomic_64)]
impl_arithmetic!(u64, fallback, "let a = AtomicCell::new(7u64);");
#[cfg(crossbeam_no_atomic_64)]
impl_arithmetic!(i64, fallback, "let a = AtomicCell::new(7i64);");
impl_arithmetic!(u128, fallback, "let a = AtomicCell::new(7u128);");
impl_arithmetic!(i128, fallback, "let a = AtomicCell::new(7i128);");
```
The fix adds proper fallback implementations for 64-bit and 128-bit types when atomic operations aren't available, preventing potential undefined behavior on platforms without native atomic support.
3. Vulnerability Existed: not sure
Potential Memory Corruption in Lock Initialization [third_party/rust/crossbeam-utils/src/atomic/atomic_cell.rs] [683-704]
[Old Code]
```rust
static LOCKS: [SeqLock; LEN] = [
SeqLock::new(),
SeqLock::new(),
... (repeated 97 times)
];
```
[Fixed Code]
```rust
const L: SeqLock = SeqLock::new();
static LOCKS: [SeqLock; LEN] = [
L, L, L, ... (repeated 97 times)
];
```
While this change appears to be an optimization, it might also address potential initialization order issues or memory corruption vulnerabilities during static initialization. However, without more context, I can't be certain if this was specifically a security fix.
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/streams/readable-byte-streams/general.any.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/streams/readable-byte-streams/general.any.js@@ -1,4 +1,4 @@-// META: global=window,worker,jsshell+// META: global=window,worker // META: script=../resources/rs-utils.js // META: script=../resources/test-utils.js 'use strict';@@ -236,15 +236,27 @@ }); }, 'ReadableStream with byte source: Test that erroring a stream does not release a BYOB reader automatically');-test(() => {+promise_test(async t => { const stream = new ReadableStream({ type: 'bytes' }); const reader = stream.getReader();- reader.read();- assert_throws_js(TypeError, () => reader.releaseLock(), 'reader.releaseLock() must throw');-}, 'ReadableStream with byte source: releaseLock() on ReadableStreamDefaultReader with pending read() must throw');+ const read = reader.read();+ reader.releaseLock();+ await promise_rejects_js(t, TypeError, read, 'pending read must reject');+}, 'ReadableStream with byte source: releaseLock() on ReadableStreamDefaultReader must reject pending read()');++promise_test(async t => {+ const stream = new ReadableStream({+ type: 'bytes'+ });++ const reader = stream.getReader({ mode: 'byob' });+ const read = reader.read(new Uint8Array(1));+ reader.releaseLock();+ await promise_rejects_js(t, TypeError, read, 'pending read must reject');+}, 'ReadableStream with byte source: releaseLock() on ReadableStreamBYOBReader must reject pending read()'); promise_test(() => { let pullCount = 0;@@ -2111,7 +2123,7 @@ }); }, 'calling respond() should throw when canceled');-promise_test(() => {+promise_test(async t => { let resolvePullCalledPromise; const pullCalledPromise = new Promise(resolve => { resolvePullCalledPromise = resolve;@@ -2127,14 +2139,13 @@ type: 'bytes' }); const reader = rs.getReader({ mode: 'byob' });- reader.read(new Uint8Array(16));- return pullCalledPromise.then(() => {- resolvePull();- return delay(0).then(() => {- assert_throws_js(TypeError, () => reader.releaseLock(), 'releaseLock() should throw');- });- });-}, 'pull() resolving should not make releaseLock() possible');+ const read = reader.read(new Uint8Array(16));+ await pullCalledPromise;+ resolvePull();+ await delay(0);+ reader.releaseLock();+ await promise_rejects_js(t, TypeError, read, 'pending read should reject');+}, 'pull() resolving should not resolve read()'); promise_test(() => { // Tests https://github.com/whatwg/streams/issues/686@@ -2363,7 +2374,7 @@ assert_equals(byobRequest1.view, null, 'first byobRequest must be invalidated after enqueue()'); const result1 = await read1;- assert_equals(result1.done, false, 'first result.done');+ assert_false(result1.done, 'first result.done'); const view1 = result1.value; assert_equals(view1.byteOffset, 0, 'first result.value.byteOffset'); assert_equals(view1.byteLength, 3, 'first result.value.byteLength');@@ -2384,7 +2395,7 @@ assert_equals(byobRequest2.view, null, 'second byobRequest must be invalidated after respond()'); const result2 = await read2;- assert_equals(result2.done, false, 'second result.done');+ assert_false(result2.done, 'second result.done'); const view2 = result2.value; assert_equals(view2.byteOffset, 0, 'second result.value.byteOffset'); assert_equals(view2.byteLength, 3, 'second result.value.byteLength');@@ -2393,3 +2404,475 @@ reader2.releaseLock(); assert_equals(pullCount, 2, 'pull() must only have been invoked twice'); }, 'ReadableStream with byte source: enqueue() discards auto-allocated BYOB request');++promise_test(async t => {+ let controller;+ const rs = new ReadableStream({+ type: 'bytes',+ start: t.step_func((c) => {+ controller = c;+ })+ });+ await flushAsyncEvents();++ const reader1 = rs.getReader({ mode: 'byob' });+ const read1 = reader1.read(new Uint8Array([1, 2, 3]));+ const byobRequest1 = controller.byobRequest;+ assert_not_equals(byobRequest1, null, 'first byobRequest should exist');+ assert_typed_array_equals(byobRequest1.view, new Uint8Array([1, 2, 3]), 'first byobRequest.view');++ // releaseLock() should reject the pending read, but *not* invalidate the BYOB request+ reader1.releaseLock();+ const reader2 = rs.getReader({ mode: 'byob' });+ const read2 = reader2.read(new Uint8Array([4, 5, 6]));+ assert_not_equals(controller.byobRequest, null, 'byobRequest should not be invalidated after releaseLock()');+ assert_equals(controller.byobRequest, byobRequest1, 'byobRequest should be unchanged');+ assert_array_equals([...new Uint8Array(byobRequest1.view.buffer)], [1, 2, 3], 'byobRequest.view.buffer should be unchanged');+ await promise_rejects_js(t, TypeError, read1, 'pending read must reject after releaseLock()');++ // respond() should fulfill the *second* read() request+ byobRequest1.view[0] = 11;+ byobRequest1.respond(1);+ const byobRequest2 = controller.byobRequest;+ assert_equals(byobRequest2, null, 'byobRequest should be null after respond()');++ const result2 = await read2;+ assert_false(result2.done, 'second result.done');+ assert_typed_array_equals(result2.value, new Uint8Array([11, 5, 6]).subarray(0, 1), 'second result.value');++}, 'ReadableStream with byte source: releaseLock() with pending read(view), read(view) on second reader, respond()');++promise_test(async t => {+ let controller;+ const rs = new ReadableStream({+ type: 'bytes',+ start: t.step_func((c) => {+ controller = c;+ })+ });+ await flushAsyncEvents();++ const reader1 = rs.getReader({ mode: 'byob' });+ const read1 = reader1.read(new Uint8Array([1, 2, 3]));+ const byobRequest1 = controller.byobRequest;+ assert_not_equals(byobRequest1, null, 'first byobRequest should exist');+ assert_typed_array_equals(byobRequest1.view, new Uint8Array([1, 2, 3]), 'first byobRequest.view');++ // releaseLock() should reject the pending read, but *not* invalidate the BYOB request+ reader1.releaseLock();+ const reader2 = rs.getReader({ mode: 'byob' });+ const read2 = reader2.read(new Uint16Array(1));+ assert_not_equals(controller.byobRequest, null, 'byobRequest should not be invalidated after releaseLock()');+ assert_equals(controller.byobRequest, byobRequest1, 'byobRequest should be unchanged');+ assert_array_equals([...new Uint8Array(byobRequest1.view.buffer)], [1, 2, 3], 'byobRequest.view.buffer should be unchanged');+ await promise_rejects_js(t, TypeError, read1, 'pending read must reject after releaseLock()');++ // respond(1) should partially fill the second read(), but not yet fulfill it+ byobRequest1.view[0] = 0x11;+ byobRequest1.respond(1);++ // second BYOB request should use remaining buffer from the second read()+ const byobRequest2 = controller.byobRequest;+ assert_not_equals(byobRequest2, null, 'second byobRequest should exist');+ assert_typed_array_equals(byobRequest2.view, new Uint8Array([0x11, 0]).subarray(1, 2), 'second byobRequest.view');++ // second respond(1) should fill the read request and fulfill it+ byobRequest2.view[0] = 0x22;+ byobRequest2.respond(1);+ const result2 = await read2;+ assert_false(result2.done, 'second result.done');+ const view2 = result2.value;+ assert_equals(view2.byteOffset, 0, 'second result.value.byteOffset');+ assert_equals(view2.byteLength, 2, 'second result.value.byteLength');+ const dataView2 = new DataView(view2.buffer, view2.byteOffset, view2.byteLength);+ assert_equals(dataView2.getUint16(0), 0x1122, 'second result.value[0]');++}, 'ReadableStream with byte source: releaseLock() with pending read(view), read(view) on second reader with ' ++ '1 element Uint16Array, respond(1)');++promise_test(async t => {+ let controller;+ const rs = new ReadableStream({+ type: 'bytes',+ start: t.step_func((c) => {+ controller = c;+ })+ });+ await flushAsyncEvents();++ const reader1 = rs.getReader({ mode: 'byob' });+ const read1 = reader1.read(new Uint8Array([1, 2, 3]));+ const byobRequest1 = controller.byobRequest;+ assert_not_equals(byobRequest1, null, 'first byobRequest should exist');+ assert_typed_array_equals(byobRequest1.view, new Uint8Array([1, 2, 3]), 'first byobRequest.view');++ // releaseLock() should reject the pending read, but *not* invalidate the BYOB request+ reader1.releaseLock();+ const reader2 = rs.getReader({ mode: 'byob' });+ const read2 = reader2.read(new Uint8Array([4, 5]));+ assert_not_equals(controller.byobRequest, null, 'byobRequest should not be invalidated after releaseLock()');+ assert_equals(controller.byobRequest, byobRequest1, 'byobRequest should be unchanged');+ assert_array_equals([...new Uint8Array(byobRequest1.view.buffer)], [1, 2, 3], 'byobRequest.view.buffer should be unchanged');+ await promise_rejects_js(t, TypeError, read1, 'pending read must reject after releaseLock()');++ // respond(3) should fulfill the second read(), and put 1 remaining byte in the queue+ byobRequest1.view[0] = 6;+ byobRequest1.view[1] = 7;+ byobRequest1.view[2] = 8;+ byobRequest1.respond(3);+ const byobRequest2 = controller.byobRequest;+ assert_equals(byobRequest2, null, 'byobRequest should be null after respond()');++ const result2 = await read2;+ assert_false(result2.done, 'second result.done');+ assert_typed_array_equals(result2.value, new Uint8Array([6, 7]), 'second result.value');++ // third read() should fulfill with the remaining byte+ const result3 = await reader2.read(new Uint8Array([0, 0, 0]));+ assert_false(result3.done, 'third result.done');+ assert_typed_array_equals(result3.value, new Uint8Array([8, 0, 0]).subarray(0, 1), 'third result.value');++}, 'ReadableStream with byte source: releaseLock() with pending read(view), read(view) on second reader with ' ++ '2 element Uint8Array, respond(3)');++promise_test(async t => {+ let controller;+ const rs = new ReadableStream({+ type: 'bytes',+ start: t.step_func((c) => {+ controller = c;+ })+ });+ await flushAsyncEvents();++ const reader1 = rs.getReader({ mode: 'byob' });+ const read1 = reader1.read(new Uint8Array([1, 2, 3]));+ const byobRequest1 = controller.byobRequest;+ assert_not_equals(byobRequest1, null, 'first byobRequest should exist');+ assert_typed_array_equals(byobRequest1.view, new Uint8Array([1, 2, 3]), 'first byobRequest.view');++ // releaseLock() should reject the pending read, but *not* invalidate the BYOB request+ reader1.releaseLock();+ const reader2 = rs.getReader({ mode: 'byob' });+ const read2 = reader2.read(new Uint8Array([4, 5, 6]));+ assert_not_equals(controller.byobRequest, null, 'byobRequest should not be invalidated after releaseLock()');+ await promise_rejects_js(t, TypeError, read1, 'pending read must reject after releaseLock()');++ // respondWithNewView() should fulfill the *second* read() request+ byobRequest1.view[0] = 11;+ byobRequest1.view[1] = 12;+ byobRequest1.respondWithNewView(byobRequest1.view.subarray(0, 2));+ const byobRequest2 = controller.byobRequest;+ assert_equals(byobRequest2, null, 'byobRequest should be null after respondWithNewView()');++ const result2 = await read2;+ assert_false(result2.done, 'second result.done');+ assert_typed_array_equals(result2.value, new Uint8Array([11, 12, 6]).subarray(0, 2), 'second result.value');++}, 'ReadableStream with byte source: releaseLock() with pending read(view), read(view) on second reader, respondWithNewView()');++promise_test(async t => {+ let controller;+ const rs = new ReadableStream({+ type: 'bytes',+ start: t.step_func((c) => {+ controller = c;+ })+ });+ await flushAsyncEvents();++ const reader1 = rs.getReader({ mode: 'byob' });+ const read1 = reader1.read(new Uint8Array([1, 2, 3]));+ const byobRequest1 = controller.byobRequest;+ assert_not_equals(byobRequest1, null, 'first byobRequest should exist');+ assert_typed_array_equals(byobRequest1.view, new Uint8Array([1, 2, 3]), 'first byobRequest.view');++ // releaseLock() should reject the pending read, but *not* invalidate the BYOB request+ reader1.releaseLock();+ const reader2 = rs.getReader({ mode: 'byob' });+ const read2 = reader2.read(new Uint8Array([4, 5, 6]));+ assert_not_equals(controller.byobRequest, null, 'byobRequest should not be invalidated after releaseLock()');+ await promise_rejects_js(t, TypeError, read1, 'pending read must reject after releaseLock()');++ // enqueue() should fulfill the *second* read() request+ controller.enqueue(new Uint8Array([11, 12]));+ const byobRequest2 = controller.byobRequest;+ assert_equals(byobRequest2, null, 'byobRequest should be null after enqueue()');++ const result2 = await read2;+ assert_false(result2.done, 'second result.done');+ assert_typed_array_equals(result2.value, new Uint8Array([11, 12, 6]).subarray(0, 2), 'second result.value');++}, 'ReadableStream with byte source: releaseLock() with pending read(view), read(view) on second reader, enqueue()');++promise_test(async t => {+ let controller;+ const rs = new ReadableStream({+ type: 'bytes',+ start: t.step_func((c) => {+ controller = c;+ })+ });+ await flushAsyncEvents();++ const reader1 = rs.getReader({ mode: 'byob' });+ const read1 = reader1.read(new Uint8Array([1, 2, 3]));+ const byobRequest1 = controller.byobRequest;+ assert_not_equals(byobRequest1, null, 'first byobRequest should exist');+ assert_typed_array_equals(byobRequest1.view, new Uint8Array([1, 2, 3]), 'first byobRequest.view');++ // releaseLock() should reject the pending read, but *not* invalidate the BYOB request+ reader1.releaseLock();+ const reader2 = rs.getReader({ mode: 'byob' });+ const read2 = reader2.read(new Uint8Array([4, 5, 6]));+ assert_not_equals(controller.byobRequest, null, 'byobRequest should not be invalidated after releaseLock()');+ await promise_rejects_js(t, TypeError, read1, 'pending read must reject after releaseLock()');++ // close() followed by respond(0) should fulfill the second read()+ controller.close();+ byobRequest1.respond(0);+ const byobRequest2 = controller.byobRequest;+ assert_equals(byobRequest2, null, 'byobRequest should be null after respond()');++ const result2 = await read2;+ assert_true(result2.done, 'second result.done');+ assert_typed_array_equals(result2.value, new Uint8Array([4, 5, 6]).subarray(0, 0), 'second result.value');+}, 'ReadableStream with byte source: releaseLock() with pending read(view), read(view) on second reader, ' ++ 'close(), respond(0)');++promise_test(async t => {+ let controller;+ const rs = new ReadableStream({+ type: 'bytes',+ autoAllocateChunkSize: 4,+ start: t.step_func((c) => {+ controller = c;+ })+ });+ await flushAsyncEvents();++ const reader1 = rs.getReader();+ const read1 = reader1.read();+ const byobRequest1 = controller.byobRequest;+ assert_not_equals(byobRequest1, null, 'first byobRequest should exist');+ assert_typed_array_equals(byobRequest1.view, new Uint8Array(4), 'first byobRequest.view');++ // releaseLock() should reject the pending read, but *not* invalidate the BYOB request+ reader1.releaseLock();+ const reader2 = rs.getReader();+ const read2 = reader2.read();+ assert_not_equals(controller.byobRequest, null, 'byobRequest should not be invalidated after releaseLock()');+ await promise_rejects_js(t, TypeError, read1, 'pending read must reject after releaseLock()');++ // respond() should fulfill the *second* read() request+ byobRequest1.view[0] = 11;+ byobRequest1.respond(1);+ const byobRequest2 = controller.byobRequest;+ assert_equals(byobRequest2, null, 'byobRequest should be null after respond()');++ const result2 = await read2;+ assert_false(result2.done, 'second result.done');+ assert_typed_array_equals(result2.value, new Uint8Array([11, 0, 0, 0]).subarray(0, 1), 'second result.value');++}, 'ReadableStream with byte source: autoAllocateChunkSize, releaseLock() with pending read(), read() on second reader, respond()');++promise_test(async t => {+ let controller;+ const rs = new ReadableStream({+ type: 'bytes',+ autoAllocateChunkSize: 4,+ start: t.step_func((c) => {+ controller = c;+ })+ });+ await flushAsyncEvents();++ const reader1 = rs.getReader();+ const read1 = reader1.read();+ const byobRequest1 = controller.byobRequest;+ assert_not_equals(byobRequest1, null, 'first byobRequest should exist');+ assert_typed_array_equals(byobRequest1.view, new Uint8Array(4), 'first byobRequest.view');++ // releaseLock() should reject the pending read, but *not* invalidate the BYOB request+ reader1.releaseLock();+ const reader2 = rs.getReader();+ const read2 = reader2.read();+ assert_not_equals(controller.byobRequest, null, 'byobRequest should not be invalidated after releaseLock()');+ await promise_rejects_js(t, TypeError, read1, 'pending read must reject after releaseLock()');++ // enqueue() should fulfill the *second* read() request+ controller.enqueue(new Uint8Array([11]));+ const byobRequest2 = controller.byobRequest;+ assert_equals(byobRequest2, null, 'byobRequest should be null after enqueue()');++ const result2 = await read2;+ assert_false(result2.done, 'second result.done');+ assert_typed_array_equals(result2.value, new Uint8Array([11]), 'second result.value');++}, 'ReadableStream with byte source: autoAllocateChunkSize, releaseLock() with pending read(), read() on second reader, enqueue()');++promise_test(async t => {+ let controller;+ const rs = new ReadableStream({+ type: 'bytes',+ autoAllocateChunkSize: 4,+ start: t.step_func((c) => {+ controller = c;+ })+ });+ await flushAsyncEvents();++ const reader1 = rs.getReader();+ const read1 = reader1.read();+ const byobRequest1 = controller.byobRequest;+ assert_not_equals(byobRequest1, null, 'first byobRequest should exist');+ assert_typed_array_equals(byobRequest1.view, new Uint8Array(4), 'first byobRequest.view');++ // releaseLock() should reject the pending read, but *not* invalidate the BYOB request+ reader1.releaseLock();+ const reader2 = rs.getReader({ mode: 'byob' });+ const read2 = reader2.read(new Uint8Array([4, 5, 6]));+ assert_not_equals(controller.byobRequest, null, 'byobRequest should not be invalidated after releaseLock()');+ await promise_rejects_js(t, TypeError, read1, 'pending read must reject after releaseLock()');++ // respond() should fulfill the *second* read() request+ byobRequest1.view[0] = 11;+ byobRequest1.respond(1);+ const byobRequest2 = controller.byobRequest;+ assert_equals(byobRequest2, null, 'byobRequest should be null after respond()');++ const result2 = await read2;+ assert_false(result2.done, 'second result.done');+ assert_typed_array_equals(result2.value, new Uint8Array([11, 5, 6]).subarray(0, 1), 'second result.value');++}, 'ReadableStream with byte source: autoAllocateChunkSize, releaseLock() with pending read(), read(view) on second reader, respond()');++promise_test(async t => {+ let controller;+ const rs = new ReadableStream({+ type: 'bytes',+ autoAllocateChunkSize: 4,+ start: t.step_func((c) => {+ controller = c;+ })+ });+ await flushAsyncEvents();++ const reader1 = rs.getReader();+ const read1 = reader1.read();+ const byobRequest1 = controller.byobRequest;+ assert_not_equals(byobRequest1, null, 'first byobRequest should exist');+ assert_typed_array_equals(byobRequest1.view, new Uint8Array(4), 'first byobRequest.view');++ // releaseLock() should reject the pending read, but *not* invalidate the BYOB request+ reader1.releaseLock();+ const reader2 = rs.getReader({ mode: 'byob' });+ const read2 = reader2.read(new Uint8Array([4, 5, 6]));+ assert_not_equals(controller.byobRequest, null, 'byobRequest should not be invalidated after releaseLock()');+ await promise_rejects_js(t, TypeError, read1, 'pending read must reject after releaseLock()');++ // enqueue() should fulfill the *second* read() request+ controller.enqueue(new Uint8Array([11]));+ const byobRequest2 = controller.byobRequest;+ assert_equals(byobRequest2, null, 'byobRequest should be null after enqueue()');++ const result2 = await read2;+ assert_false(result2.done, 'second result.done');+ assert_typed_array_equals(result2.value, new Uint8Array([11, 5, 6]).subarray(0, 1), 'second result.value');++}, 'ReadableStream with byte source: autoAllocateChunkSize, releaseLock() with pending read(), read(view) on second reader, enqueue()');++promise_test(async t => {+ let controller;+ const rs = new ReadableStream({+ type: 'bytes',+ start: t.step_func((c) => {+ controller = c;+ })+ });+ await flushAsyncEvents();++ const reader1 = rs.getReader({ mode: 'byob' });+ const read1 = reader1.read(new Uint16Array(1));+ const byobRequest1 = controller.byobRequest;+ assert_not_equals(byobRequest1, null, 'first byobRequest should exist');+ assert_typed_array_equals(byobRequest1.view, new Uint8Array([0, 0]), 'first byobRequest.view');++ // respond(1) should partially fill the first read(), but not yet fulfill it+ byobRequest1.view[0] = 0x11;+ byobRequest1.respond(1);+ const byobRequest2 = controller.byobRequest;+ assert_not_equals(byobRequest2, null, 'second byobRequest should exist');+ assert_typed_array_equals(byobRequest2.view, new Uint8Array([0x11, 0]).subarray(1, 2), 'second byobRequest.view');++ // releaseLock() should reject the pending read, but *not* invalidate the BYOB request+ reader1.releaseLock();+ const reader2 = rs.getReader({ mode: 'byob' });+ const read2 = reader2.read(new Uint16Array(1));+ assert_not_equals(controller.byobRequest, null, 'byobRequest should not be invalidated after releaseLock()');+ assert_equals(controller.byobRequest, byobRequest2, 'byobRequest should be unchanged');+ assert_typed_array_equals(byobRequest2.view, new Uint8Array([0x11, 0]).subarray(1, 2), 'byobRequest.view should be unchanged');+ await promise_rejects_js(t, TypeError, read1, 'pending read must reject after releaseLock()');++ // second respond(1) should fill the read request and fulfill it+ byobRequest2.view[0] = 0x22;+ byobRequest2.respond(1);+ assert_equals(controller.byobRequest, null, 'byobRequest should be invalidated after second respond()');++ const result2 = await read2;+ assert_false(result2.done, 'second result.done');+ const view2 = result2.value;+ assert_equals(view2.byteOffset, 0, 'second result.value.byteOffset');+ assert_equals(view2.byteLength, 2, 'second result.value.byteLength');+ const dataView2 = new DataView(view2.buffer, view2.byteOffset, view2.byteLength);+ assert_equals(dataView2.getUint16(0), 0x1122, 'second result.value[0]');++}, 'ReadableStream with byte source: read(view) with 1 element Uint16Array, respond(1), releaseLock(), read(view) on ' ++ 'second reader with 1 element Uint16Array, respond(1)');++promise_test(async t => {+ let controller;+ const rs = new ReadableStream({+ type: 'bytes',+ start: t.step_func((c) => {+ controller = c;+ })+ });+ await flushAsyncEvents();++ const reader1 = rs.getReader({ mode: 'byob' });+ const read1 = reader1.read(new Uint16Array(1));+ const byobRequest1 = controller.byobRequest;+ assert_not_equals(byobRequest1, null, 'first byobRequest should exist');+ assert_typed_array_equals(byobRequest1.view, new Uint8Array([0, 0]), 'first byobRequest.view');++ // respond(1) should partially fill the first read(), but not yet fulfill it+ byobRequest1.view[0] = 0x11;+ byobRequest1.respond(1);+ const byobRequest2 = controller.byobRequest;+ assert_not_equals(byobRequest2, null, 'second byobRequest should exist');+ assert_typed_array_equals(byobRequest2.view, new Uint8Array([0x11, 0]).subarray(1, 2), 'second byobRequest.view');++ // releaseLock() should reject the pending read, but *not* invalidate the BYOB request+ reader1.releaseLock();+ const reader2 = rs.getReader();+ const read2 = reader2.read();+ assert_not_equals(controller.byobRequest, null, 'byobRequest should not be invalidated after releaseLock()');+ assert_equals(controller.byobRequest, byobRequest2, 'byobRequest should be unchanged');+ assert_typed_array_equals(byobRequest2.view, new Uint8Array([0x11, 0]).subarray(1, 2), 'byobRequest.view should be unchanged');+ await promise_rejects_js(t, TypeError, read1, 'pending read must reject after releaseLock()');++ // enqueue() should fulfill the read request and put remaining byte in the queue+ controller.enqueue(new Uint8Array([0x22]));+ assert_equals(controller.byobRequest, null, 'byobRequest should be invalidated after second respond()');++ const result2 = await read2;+ assert_false(result2.done, 'second result.done');+ assert_typed_array_equals(result2.value, new Uint8Array([0x11]), 'second result.value');++ const result3 = await reader2.read();+ assert_false(result3.done, 'third result.done');+ assert_typed_array_equals(result3.value, new Uint8Array([0x22]), 'third result.value');++}, 'ReadableStream with byte source: read(view) with 1 element Uint16Array, respond(1), releaseLock(), read() on ' ++ 'second reader, enqueue()');
Analyzing the provided code diff for security fixes:
1. Vulnerability Existed: not sure
[Potential Race Condition] [testing/web-platform/tests/streams/readable-byte-streams/general.any.js] [Lines 236-246]
[Old Code]
```javascript
test(() => {
const stream = new ReadableStream({
type: 'bytes'
});
const reader = stream.getReader();
reader.read();
assert_throws_js(TypeError, () => reader.releaseLock(), 'reader.releaseLock() must throw');
}, 'ReadableStream with byte source: releaseLock() on ReadableStreamDefaultReader with pending read() must throw');
```
[Fixed Code]
```javascript
promise_test(async t => {
const stream = new ReadableStream({
type: 'bytes'
});
const reader = stream.getReader();
const read = reader.read();
reader.releaseLock();
await promise_rejects_js(t, TypeError, read, 'pending read must reject');
}, 'ReadableStream with byte source: releaseLock() on ReadableStreamDefaultReader must reject pending read()');
```
Additional Details: The change converts a synchronous test to an asynchronous one, potentially addressing race conditions in lock release behavior.
2. Vulnerability Existed: not sure
[BYOB Reader Handling] [testing/web-platform/tests/streams/readable-byte-streams/general.any.js] [Lines 2123-2139]
[Old Code]
```javascript
promise_test(() => {
let resolvePullCalledPromise;
const pullCalledPromise = new Promise(resolve => {
resolvePullCalledPromise = resolve;
});
let resolvePull;
const pullPromise = new Promise(resolve => {
resolvePull = resolve;
});
const rs = new ReadableStream({
type: 'bytes',
pull() {
resolvePullCalledPromise();
return pullPromise;
}
});
const reader = rs.getReader({ mode: 'byob' });
reader.read(new Uint8Array(16));
return pullCalledPromise.then(() => {
resolvePull();
return delay(0).then(() => {
assert_throws_js(TypeError, () => reader.releaseLock(), 'releaseLock() should throw');
});
});
}, 'pull() resolving should not make releaseLock() possible');
```
[Fixed Code]
```javascript
promise_test(async t => {
let resolvePullCalledPromise;
const pullCalledPromise = new Promise(resolve => {
resolvePullCalledPromise = resolve;
});
let resolvePull;
const pullPromise = new Promise(resolve => {
resolvePull = resolve;
});
const rs = new ReadableStream({
type: 'bytes',
pull() {
resolvePullCalledPromise();
return pullPromise;
}
});
const reader = rs.getReader({ mode: 'byob' });
const read = reader.read(new Uint8Array(16));
await pullCalledPromise;
resolvePull();
await delay(0);
reader.releaseLock();
await promise_rejects_js(t, TypeError, read, 'pending read should reject');
}, 'pull() resolving should not resolve read()');
```
Additional Details: The modification improves handling of BYOB reader lock release during pull operations, potentially preventing resource access issues.
The changes primarily focus on improving test cases for ReadableStream's byte handling and lock management. While these appear to be test improvements rather than direct security fixes, they help ensure correct behavior in security-sensitive stream operations. No clear vulnerability names are identified, but the changes address potential race conditions and improper lock handling scenarios.
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/build/build-clang/clang-trunk.json+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/build/build-clang/clang-trunk.json@@ -11,11 +11,9 @@ "loosen-msvc-detection.patch", "fuzzing_ccov_build_clang_12.patch", "compiler-rt-13-no-codesign.patch",- "win64-no-symlink.patch", "revert-llvmorg-14-init-3652-gf3c2094d8c11.patch", "revert-llvmorg-14-init-3651-g85ba583eba19.patch", "revert-llvmorg-14-init-3650-g50d7ecc560b2.patch",- "revert-llvmorg-13-init-8182-gc2297544c047.patch",- "revert-llvmorg-13-init-4019-ga478b0a199f4.patch"+ "revert-llvmorg-13-init-8182-gc2297544c047.patch" ] }
I'll analyze the provided code diff for security fixes following the specified format.
Vulnerability Existed: not sure
[Potential Patch Removal for Security Fix] [build/build-clang/clang-trunk.json] [Lines 11,14]
[Old Code]
"win64-no-symlink.patch",
"revert-llvmorg-13-init-4019-ga478b0a199f4.patch"
[Fixed Code]
(removed from the list)
Additional Details:
The diff shows removal of two patches: "win64-no-symlink.patch" and "revert-llvmorg-13-init-4019-ga478b0a199f4.patch". While we can't be certain about the exact security implications without seeing the patch contents, the removal of a symlink-related patch ("win64-no-symlink.patch") might indicate a security-related change, as symlinks can sometimes be involved in security issues like symlink attacks. The other removed patch appears to be reverting a previous change, but its security impact is unclear.
Vulnerability Existed: not sure
[Patch Reduction] [build/build-clang/clang-trunk.json] [Lines 11-15]
[Old Code]
Multiple revert patches present
[Fixed Code]
Fewer revert patches
Additional Details:
The diff shows a reduction in the number of revert patches being applied. This might indicate that some previously reverted changes are now considered safe or properly fixed, but without knowing the contents of these patches, we can't determine if this was specifically for security reasons.
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.invalid.css-color-4-hsla-1.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.invalid.css-color-4-hsla-1.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 = '#0f0'; try { ctx.fillStyle = 'hsla(0, 100%, 50% / 1)'; } catch (e) { } // this shouldn't throw, but it shouldn't matter here if it does 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 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:
Vulnerability Existed: no
No security vulnerability found [testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.invalid.css-color-4-hsla-1.html] [Lines 17-25]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
ctx.fillStyle = '#0f0';
try { ctx.fillStyle = 'hsla(0, 100%, 50% / 1)'; } catch (e) { }
ctx.fillRect(0, 0, 100, 50);
_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');
ctx.fillStyle = '#0f0';
try { ctx.fillStyle = 'hsla(0, 100%, 50% / 1)'; } catch (e) { }
ctx.fillRect(0, 0, 100, 50);
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes are:
1. Renaming variable `offscreenCanvas` to `canvas`
2. Updating the variable name in the `_assertPixel` call
3. No functional changes to the actual test logic or security-related behavior
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/BaselineJIT.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/jit/BaselineJIT.cpp@@ -527,11 +527,6 @@ TraceEdge(trc, &method_, "baseline-method"); }-/* static */-void BaselineScript::preWriteBarrier(Zone* zone, BaselineScript* script) {- PreWriteBarrier(zone, script);-}- void BaselineScript::Destroy(JSFreeOp* fop, BaselineScript* script) { MOZ_ASSERT(!script->hasPendingIonCompileTask());
Based on the provided code diff, here's the analysis:
Vulnerability Existed: not sure
[Potential Memory Safety Issue] [js/src/jit/BaselineJIT.cpp] [Lines 527-530]
[Old Code]
/* static */
void BaselineScript::preWriteBarrier(Zone* zone, BaselineScript* script) {
PreWriteBarrier(zone, script);
}
[Fixed Code]
[Removed entirely]
Additional Details:
1. The diff shows removal of a pre-write barrier function, which is typically used in garbage collection systems to prevent memory safety issues.
2. Without more context about how this function was used and what safeguards exist after its removal, it's difficult to determine if this was fixing an actual vulnerability or just refactoring.
3. The removal could potentially affect garbage collection safety, but we can't be certain without seeing the broader changes in the codebase.
Note: The removal of a write barrier could potentially lead to use-after-free vulnerabilities if not properly handled elsewhere, but we can't confirm this from the given diff alone.
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.