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/docs/contributor/getting-started/development-profiles.md+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/docs/contributor/getting-started/development-profiles.md@@ -39,7 +39,7 @@ Next time you start Firefox with `./mach run -P development`, the new profile will be automatically used, and settings will persist between browser launches.-It's now time to [start contributing](../contributing.html)! 😃+It's now time to [start contributing](../contributing.md)! 😃 ---@@ -67,7 +67,7 @@ <!--TODO: aren't some of these preferences enabled by default now in local builds? -->-These settings allow you to use the [browser toolbox](https://developer.mozilla.org/docs/Tools/Browser_Toolbox) to inspect the DevTools themselves, set breakpoints inside of DevTools code in the *Browser* environment.+These settings allow you to use the [browser toolbox](https://firefox-source-docs.mozilla.org/devtools-user/browser_toolbox/) to inspect the DevTools themselves, set breakpoints inside of DevTools code in the *Browser* environment. Open DevTools, and click the "Toolbox Options" gear icon in the top right (the image underneath is outdated). <!--TODO update image-->
After analyzing the provided code diff, I don't find any security vulnerabilities. The changes are documentation updates involving:
1. Changing a link from .html to .md extension
2. Updating a URL to point to a more current documentation source
Here's the structured analysis:
Vulnerability Existed: no
Documentation Update [File] [Lines 39-39]
[Old Code]
It's now time to [start contributing](../contributing.html)! 😃
[Fixed Code]
It's now time to [start contributing](../contributing.md)! 😃
Vulnerability Existed: no
Documentation URL Update [File] [Lines 67-67]
[Old Code]
These settings allow you to use the [browser toolbox](https://developer.mozilla.org/docs/Tools/Browser_Toolbox) to inspect the DevTools themselves...
[Fixed Code]
These settings allow you to use the [browser toolbox](https://firefox-source-docs.mozilla.org/devtools-user/browser_toolbox/) to inspect the DevTools themselves...
These changes appear to be purely documentation improvements with no security implications.
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.arc.angle.6.html+++ /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.arc.angle.6.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);@@ -27,10 +27,10 @@ ctx.moveTo(50, 25); ctx.arc(50, 25, 60, (1024-1)*Math.PI, (512+1/2)*Math.PI, true); 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, 1,48, 0,255,0,255, "1,48", "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, 98,1, 0,255,0,255, "98,1", "0,255,0,255");+_assertPixel(canvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");+_assertPixel(canvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255"); t.done(); });
Here's the analysis of the provided code diff:
1. Vulnerability Existed: no
No specific vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.arc.angle.6.html [Lines] 17-27
[Old Code]
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");
[Fixed Code]
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");
The changes appear to be purely variable name refactoring from `offscreenCanvas` to `canvas`. There's no indication of any security vulnerability being fixed - this seems to be a code style/consistency improvement rather than a security patch. 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/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.invalid.hex1.worker.js+++ /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.hex1.worker.js@@ -13,14 +13,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 = '#f'; } 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'll analyze it for security vulnerabilities:
1. Vulnerability Existed: no
No specific vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.invalid.hex1.worker.js [Lines] 13-21
[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 cosmetic/refactoring, renaming the variable from `offscreenCanvas` to `canvas`. There's no indication of any security vulnerability being fixed in this change. 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/tools/tryselect/tasks.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/tools/tryselect/tasks.py@@ -9,17 +9,15 @@ import sys from collections import defaultdict+import mozpack.path as mozpath from mach.util import get_state_dir from mozbuild.base import MozbuildObject from mozpack.files import FileFinder from moztest.resolve import TestResolver, TestManifestLoader, get_suite_definition+from taskgraph.parameters import ParameterMismatch, parameters_loader import gecko_taskgraph from gecko_taskgraph.generator import TaskGraphGenerator-from gecko_taskgraph.parameters import (- ParameterMismatch,- parameters_loader,-) from gecko_taskgraph.taskgraph import TaskGraph here = os.path.abspath(os.path.dirname(__file__))@@ -175,8 +173,11 @@ if test_path is None: continue found_path = None+ manifest_relpath = None+ if "manifest_relpath" in test:+ manifest_relpath = mozpath.normpath(test["manifest_relpath"]) for path in remaining_paths_by_suite[key]:- if test_path.startswith(path) or test.get("manifest_relpath") == path:+ if test_path.startswith(path) or manifest_relpath == path: found_path = path break if found_path:
Let me analyze the code diff for security fixes:
1. Vulnerability Existed: not sure
[Potential Path Traversal Vulnerability] [tools/tryselect/tasks.py] [Lines 175-181]
[Old Code]
if test_path.startswith(path) or test.get("manifest_relpath") == path:
[Fixed Code]
manifest_relpath = None
if "manifest_relpath" in test:
manifest_relpath = mozpath.normpath(test["manifest_relpath"])
if test_path.startswith(path) or manifest_relpath == path:
Additional Details:
- The change introduces path normalization using mozpath.normpath() for the manifest_relpath value
- This could potentially address path traversal issues by normalizing paths before comparison
- However, without more context about how these paths are used, I can't be certain if this was fixing an actual vulnerability or just improving code robustness
The main security-relevant change appears to be the addition of path normalization, which is often used to prevent path traversal attacks, but I can't confirm if this was specifically fixing an exploitable vulnerability.
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/hal/android/AndroidHal.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/hal/android/AndroidHal.cpp@@ -114,6 +114,10 @@ case eScreenOrientation_LandscapeSecondary: case eScreenOrientation_LandscapePrimary | eScreenOrientation_LandscapeSecondary:+ case eScreenOrientation_PortraitPrimary |+ eScreenOrientation_PortraitSecondary |+ eScreenOrientation_LandscapePrimary |+ eScreenOrientation_LandscapeSecondary: case eScreenOrientation_Default: { java::GeckoRuntime::LocalRef runtime = java::GeckoRuntime::GetInstance(); if (runtime != NULL) {@@ -128,7 +132,8 @@ } } default:- return nullptr;+ NS_WARNING("Unsupported screen orientation type");+ return MozPromise<bool, bool, false>::CreateAndReject(false, __func__); } }
Here's the analysis of the provided code diff:
1. Vulnerability Existed: not sure
[Potential Unhandled Case Vulnerability] [hal/android/AndroidHal.cpp] [Lines 114-132]
[Old Code]
case eScreenOrientation_LandscapeSecondary:
case eScreenOrientation_LandscapePrimary |
eScreenOrientation_LandscapeSecondary:
case eScreenOrientation_Default: {
[...]
}
default:
return nullptr;
[Fixed Code]
case eScreenOrientation_LandscapeSecondary:
case eScreenOrientation_LandscapePrimary |
eScreenOrientation_LandscapeSecondary:
case eScreenOrientation_PortraitPrimary |
eScreenOrientation_PortraitSecondary |
eScreenOrientation_LandscapePrimary |
eScreenOrientation_LandscapeSecondary:
case eScreenOrientation_Default: {
[...]
}
default:
NS_WARNING("Unsupported screen orientation type");
return MozPromise<bool, bool, false>::CreateAndReject(false, __func__);
2. Vulnerability Existed: not sure
[Potential Null Pointer Return Vulnerability] [hal/android/AndroidHal.cpp] [Lines 128-132]
[Old Code]
default:
return nullptr;
[Fixed Code]
default:
NS_WARNING("Unsupported screen orientation type");
return MozPromise<bool, bool, false>::CreateAndReject(false, __func__);
The changes appear to:
1. Add more supported orientation cases (potentially fixing a case where some orientations weren't properly handled)
2. Change the default case from returning nullptr to returning a rejected promise with a warning
While these changes improve robustness, I can't definitively identify specific named vulnerabilities that were fixed. The changes seem more about improving error handling and case coverage than fixing known security 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/testing/web-platform/tests/html/canvas/offscreen/the-offscreen-canvas/initial.reset.path.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/the-offscreen-canvas/initial.reset.path.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');-offscreenCanvas.width = 100;+canvas.width = 100; ctx.rect(0, 0, 100, 50);-offscreenCanvas.width = 100;+canvas.width = 100; ctx.fillStyle = '#f00'; ctx.fill();-_assertPixel(offscreenCanvas, 20,20, 0,0,0,0, "20,20", "0,0,0,0");+_assertPixel(canvas, 20,20, 0,0,0,0, "20,20", "0,0,0,0"); t.done(); });
Based on the provided code diff, here's the analysis:
Vulnerability Existed: no
No specific vulnerability found [File] [Lines 17-27]
[Old Code]
```javascript
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
offscreenCanvas.width = 100;
ctx.rect(0, 0, 100, 50);
offscreenCanvas.width = 100;
ctx.fillStyle = '#f00';
ctx.fill();
_assertPixel(offscreenCanvas, 20,20, 0,0,0,0, "20,20", "0,0,0,0");
```
[Fixed Code]
```javascript
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
canvas.width = 100;
ctx.rect(0, 0, 100, 50);
canvas.width = 100;
ctx.fillStyle = '#f00';
ctx.fill();
_assertPixel(canvas, 20,20, 0,0,0,0, "20,20", "0,0,0,0");
```
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. There are no security vulnerabilities being fixed 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/devtools/client/inspector/fonts/fonts.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/inspector/fonts/fonts.js@@ -110,6 +110,7 @@ this.updateFontVariationSettings = this.updateFontVariationSettings.bind( this );+ this.onResourceAvailable = this.onResourceAvailable.bind(this); this.init(); }@@ -175,6 +176,11 @@ this.inspector.selection.on("new-node-front", this.onNewNode); // @see ToolSidebar.onSidebarTabSelected() this.inspector.sidebar.on("fontinspector-selected", this.onNewNode);++ this.inspector.toolbox.resourceCommand.watchResources(+ [this.inspector.toolbox.resourceCommand.TYPES.DOCUMENT_EVENT],+ { onAvailable: this.onResourceAvailable }+ ); // Listen for theme changes as the color of the previews depend on the theme gDevTools.on("theme-switched", this.onThemeChanged);@@ -316,6 +322,12 @@ this.ruleView.off("property-value-updated", this.onRulePropertyUpdated); gDevTools.off("theme-switched", this.onThemeChanged);+ this.inspector.toolbox.resourceCommand.unwatchResources(+ [this.inspector.toolbox.resourceCommand.TYPES.DOCUMENT_EVENT],+ { onAvailable: this.onResourceAvailable }+ );++ this.fontsHighlighter = null; this.document = null; this.inspector = null; this.node = null;@@ -326,6 +338,21 @@ this.store = null; this.writers.clear(); this.writers = null;+ }++ onResourceAvailable(resources) {+ for (const resource of resources) {+ if (+ resource.resourceType ===+ this.inspector.commands.resourceCommand.TYPES.DOCUMENT_EVENT &&+ resource.name === "will-navigate" &&+ resource.targetFront.isTopLevel+ ) {+ // Reset the fontsHighlighter so the next call to `onToggleFontHighlight` will+ // re-create it from the inspector front tied to the new document.+ this.fontsHighlighter = null;+ }+ } } /**@@ -867,9 +894,8 @@ "FontsHighlighter" ); } catch (e) {- // When connecting to an older server or when debugging a XUL document, the- // FontsHighlighter won't be available. Silently fail here and prevent any future- // calls to the function.+ // the FontsHighlighter won't be available when debugging a XUL document.+ // Silently fail here and prevent any future calls to the function. this.onToggleFontHighlight = () => {}; return; }
Based on the provided code diff, I'll analyze it for security vulnerabilities: 1. Vulnerability Existed: not sure [Potential Resource Leak] [devtools/client/inspector/fonts/fonts.js] [Lines 175-178, 316-319] [Old Code] (No resource watching/unwatching for document events) [Fixed Code] Added resource watching/unwatching for document events with proper cleanup 2. Vulnerability Existed: not sure [Potential Memory Leak] [devtools/client/inspector/fonts/fonts.js] [Lines 326] [Old Code] No explicit nulling of fontsHighlighter during destruction [Fixed Code] Added `this.fontsHighlighter = null` during destruction 3. Vulnerability Existed: no [Comment Clarification] [devtools/client/inspector/fonts/fonts.js] [Lines 867-874] [Old Code] Comment mentioned "older server" as a reason for FontsHighlighter unavailability [Fixed Code] Comment simplified to only mention XUL documents as the reason The changes appear to be primarily focused on: 1. Adding proper resource management for document events 2. Improving cleanup during destruction 3. Clarifying comments While these changes improve code robustness, I don't see any clear security vulnerabilities being fixed. The changes are more about proper resource management and cleanup, which could prevent potential memory leaks or stale references, but don't appear to address any specific known 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/toolkit/components/search/tests/xpcshell/searchconfigs/test_yandex.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/toolkit/components/search/tests/xpcshell/searchconfigs/test_yandex.js@@ -114,4 +114,4 @@ add_task(async function test_searchConfig_yandex() { await test.run();-});+}).skip();
Analyzing the provided code diff, here's the security assessment: Vulnerability Existed: no [No Vulnerability Found] [toolkit/components/search/tests/xpcshell/searchconfigs/test_yandex.js] [Lines 114-114] [Old Code: }).skip();] [Fixed Code: });] Additional Details: The change simply removes the .skip() call from the test function. This appears to be a test modification rather than a security fix. The .skip() method is typically used in testing frameworks to skip certain tests, and its removal doesn't indicate any security vulnerability being addressed. The change is more likely related to test maintenance or behavior modification rather than security. No known vulnerability patterns or security issues are being addressed in this diff. The modification is purely related to test execution 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/shared/AtomicOperations-shared-jit.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/jit/shared/AtomicOperations-shared-jit.h@@ -22,117 +22,18 @@ #include <stddef.h> #include <stdint.h>-#include "js/GCAPI.h"+#include "jit/AtomicOperationsGenerated.h" #include "vm/Uint8Clamped.h" namespace js { namespace jit {-// The function pointers in this section all point to jitted code.-//-// On 32-bit systems we assume for simplicity's sake that we don't have any-// 64-bit atomic operations except cmpxchg (this is a concession to x86 but it's-// not a hardship). On 32-bit systems we therefore implement other 64-bit-// atomic operations in terms of cmpxchg along with some C++ code and a local-// reordering fence to prevent other loads and stores from being intermingled-// with operations in the implementation of the atomic.--// `fence` performs a full memory barrier.-extern void (*AtomicFenceSeqCst)();--#ifndef JS_64BIT-// `compiler_fence` erects a reordering boundary for operations on the current-// thread. We use it to prevent the compiler from reordering loads and stores-// inside larger primitives that are synthesized from cmpxchg.-extern void (*AtomicCompilerFence)();-#endif--extern uint8_t (*AtomicLoad8SeqCst)(const uint8_t* addr);-extern uint16_t (*AtomicLoad16SeqCst)(const uint16_t* addr);-extern uint32_t (*AtomicLoad32SeqCst)(const uint32_t* addr);-#ifdef JS_64BIT-extern uint64_t (*AtomicLoad64SeqCst)(const uint64_t* addr);-#endif--// These are access-atomic up to sizeof(uintptr_t).-extern uint8_t (*AtomicLoad8Unsynchronized)(const uint8_t* addr);-extern uint16_t (*AtomicLoad16Unsynchronized)(const uint16_t* addr);-extern uint32_t (*AtomicLoad32Unsynchronized)(const uint32_t* addr);-#ifdef JS_64BIT-extern uint64_t (*AtomicLoad64Unsynchronized)(const uint64_t* addr);-#endif--extern uint8_t (*AtomicStore8SeqCst)(uint8_t* addr, uint8_t val);-extern uint16_t (*AtomicStore16SeqCst)(uint16_t* addr, uint16_t val);-extern uint32_t (*AtomicStore32SeqCst)(uint32_t* addr, uint32_t val);-#ifdef JS_64BIT-extern uint64_t (*AtomicStore64SeqCst)(uint64_t* addr, uint64_t val);-#endif--// These are access-atomic up to sizeof(uintptr_t).-extern uint8_t (*AtomicStore8Unsynchronized)(uint8_t* addr, uint8_t val);-extern uint16_t (*AtomicStore16Unsynchronized)(uint16_t* addr, uint16_t val);-extern uint32_t (*AtomicStore32Unsynchronized)(uint32_t* addr, uint32_t val);-#ifdef JS_64BIT-extern uint64_t (*AtomicStore64Unsynchronized)(uint64_t* addr, uint64_t val);-#endif--// `exchange` takes a cell address and a value. It stores it in the cell and-// returns the value previously in the cell.-extern uint8_t (*AtomicExchange8SeqCst)(uint8_t* addr, uint8_t val);-extern uint16_t (*AtomicExchange16SeqCst)(uint16_t* addr, uint16_t val);-extern uint32_t (*AtomicExchange32SeqCst)(uint32_t* addr, uint32_t val);-#ifdef JS_64BIT-extern uint64_t (*AtomicExchange64SeqCst)(uint64_t* addr, uint64_t val);-#endif--// `add` adds a value atomically to the cell and returns the old value in the-// cell. (There is no `sub`; just add the negated value.)-extern uint8_t (*AtomicAdd8SeqCst)(uint8_t* addr, uint8_t val);-extern uint16_t (*AtomicAdd16SeqCst)(uint16_t* addr, uint16_t val);-extern uint32_t (*AtomicAdd32SeqCst)(uint32_t* addr, uint32_t val);-#ifdef JS_64BIT-extern uint64_t (*AtomicAdd64SeqCst)(uint64_t* addr, uint64_t val);-#endif--// `and` bitwise-ands a value atomically into the cell and returns the old value-// in the cell.-extern uint8_t (*AtomicAnd8SeqCst)(uint8_t* addr, uint8_t val);-extern uint16_t (*AtomicAnd16SeqCst)(uint16_t* addr, uint16_t val);-extern uint32_t (*AtomicAnd32SeqCst)(uint32_t* addr, uint32_t val);-#ifdef JS_64BIT-extern uint64_t (*AtomicAnd64SeqCst)(uint64_t* addr, uint64_t val);-#endif--// `or` bitwise-ors a value atomically into the cell and returns the old value-// in the cell.-extern uint8_t (*AtomicOr8SeqCst)(uint8_t* addr, uint8_t val);-extern uint16_t (*AtomicOr16SeqCst)(uint16_t* addr, uint16_t val);-extern uint32_t (*AtomicOr32SeqCst)(uint32_t* addr, uint32_t val);-#ifdef JS_64BIT-extern uint64_t (*AtomicOr64SeqCst)(uint64_t* addr, uint64_t val);-#endif--// `xor` bitwise-xors a value atomically into the cell and returns the old value-// in the cell.-extern uint8_t (*AtomicXor8SeqCst)(uint8_t* addr, uint8_t val);-extern uint16_t (*AtomicXor16SeqCst)(uint16_t* addr, uint16_t val);-extern uint32_t (*AtomicXor32SeqCst)(uint32_t* addr, uint32_t val);-#ifdef JS_64BIT-extern uint64_t (*AtomicXor64SeqCst)(uint64_t* addr, uint64_t val);-#endif--// `cmpxchg` takes a cell address, an expected value and a replacement value.-// If the value in the cell equals the expected value then the replacement value-// is stored in the cell. It always returns the value previously in the cell.-extern uint8_t (*AtomicCmpXchg8SeqCst)(uint8_t* addr, uint8_t oldval,- uint8_t newval);-extern uint16_t (*AtomicCmpXchg16SeqCst)(uint16_t* addr, uint16_t oldval,- uint16_t newval);-extern uint32_t (*AtomicCmpXchg32SeqCst)(uint32_t* addr, uint32_t oldval,- uint32_t newval);-extern uint64_t (*AtomicCmpXchg64SeqCst)(uint64_t* addr, uint64_t oldval,- uint64_t newval);+#ifndef JS_64BIT+// `AtomicCompilerFence` erects a reordering boundary for operations on the+// current thread. We use it to prevent the compiler from reordering loads and+// stores inside larger primitives that are synthesized from cmpxchg.+extern void AtomicCompilerFence();+#endif // `...MemcpyDown` moves bytes toward lower addresses in memory: dest <= src. // `...MemcpyUp` moves bytes toward higher addresses in memory: dest >= src.@@ -153,7 +54,6 @@ #define JIT_LOADOP(T, U, loadop) \ template <> \ inline T AtomicOperations::loadSeqCst(T* addr) { \- JS::AutoSuppressGCAnalysis nogc; \ return (T)loadop((U*)addr); \ }@@ -161,7 +61,6 @@ # define JIT_LOADOP_CAS(T) \ template <> \ inline T AtomicOperations::loadSeqCst(T* addr) { \- JS::AutoSuppressGCAnalysis nogc; \ AtomicCompilerFence(); \ return (T)AtomicCmpXchg64SeqCst((uint64_t*)addr, 0, 0); \ }@@ -194,7 +93,6 @@ #define JIT_STOREOP(T, U, storeop) \ template <> \ inline void AtomicOperations::storeSeqCst(T* addr, T val) { \- JS::AutoSuppressGCAnalysis nogc; \ storeop((U*)addr, val); \ }@@ -202,7 +100,6 @@ # define JIT_STOREOP_CAS(T) \ template <> \ inline void AtomicOperations::storeSeqCst(T* addr, T val) { \- JS::AutoSuppressGCAnalysis nogc; \ AtomicCompilerFence(); \ T oldval = *addr; /* good initial approximation */ \ for (;;) { \@@ -244,7 +141,6 @@ #define JIT_EXCHANGEOP(T, U, xchgop) \ template <> \ inline T AtomicOperations::exchangeSeqCst(T* addr, T val) { \- JS::AutoSuppressGCAnalysis nogc; \ return (T)xchgop((U*)addr, (U)val); \ }@@ -252,7 +148,6 @@ # define JIT_EXCHANGEOP_CAS(T) \ template <> \ inline T AtomicOperations::exchangeSeqCst(T* addr, T val) { \- JS::AutoSuppressGCAnalysis nogc; \ AtomicCompilerFence(); \ T oldval = *addr; \ for (;;) { \@@ -296,7 +191,6 @@ template <> \ inline T AtomicOperations::compareExchangeSeqCst(T* addr, T oldval, \ T newval) { \- JS::AutoSuppressGCAnalysis nogc; \ return (T)cmpxchg((U*)addr, (U)oldval, (U)newval); \ }@@ -320,14 +214,12 @@ #define JIT_FETCHADDOP(T, U, xadd) \ template <> \ inline T AtomicOperations::fetchAddSeqCst(T* addr, T val) { \- JS::AutoSuppressGCAnalysis nogc; \ return (T)xadd((U*)addr, (U)val); \ } #define JIT_FETCHSUBOP(T) \ template <> \ inline T AtomicOperations::fetchSubSeqCst(T* addr, T val) { \- JS::AutoSuppressGCAnalysis nogc; \ return fetchAddSeqCst(addr, (T)(0 - val)); \ }@@ -335,7 +227,6 @@ # define JIT_FETCHADDOP_CAS(T) \ template <> \ inline T AtomicOperations::fetchAddSeqCst(T* addr, T val) { \- JS::AutoSuppressGCAnalysis nogc; \ AtomicCompilerFence(); \ T oldval = *addr; /* Good initial approximation */ \ for (;;) { \@@ -388,7 +279,6 @@ #define JIT_FETCHBITOPX(T, U, name, op) \ template <> \ inline T AtomicOperations::name(T* addr, T val) { \- JS::AutoSuppressGCAnalysis nogc; \ return (T)op((U*)addr, (U)val); \ }@@ -406,7 +296,6 @@ # define JIT_FETCHBITOPX_CAS(T, name, OP) \ template <> \ inline T AtomicOperations::name(T* addr, T val) { \- JS::AutoSuppressGCAnalysis nogc; \ AtomicCompilerFence(); \ T oldval = *addr; \ for (;;) { \@@ -465,7 +354,6 @@ #define JIT_LOADSAFE(T, U, loadop) \ template <> \ inline T js::jit::AtomicOperations::loadSafeWhenRacy(T* addr) { \- JS::AutoSuppressGCAnalysis nogc; \ union { \ U u; \ T t; \@@ -478,7 +366,6 @@ # define JIT_LOADSAFE_TEARING(T) \ template <> \ inline T js::jit::AtomicOperations::loadSafeWhenRacy(T* addr) { \- JS::AutoSuppressGCAnalysis nogc; \ MOZ_ASSERT(sizeof(T) == 8); \ union { \ uint32_t u[2]; \@@ -527,7 +414,6 @@ #define JIT_STORESAFE(T, U, storeop) \ template <> \ inline void js::jit::AtomicOperations::storeSafeWhenRacy(T* addr, T val) { \- JS::AutoSuppressGCAnalysis nogc; \ union { \ U u; \ T t; \@@ -540,7 +426,6 @@ # define JIT_STORESAFE_TEARING(T) \ template <> \ inline void js::jit::AtomicOperations::storeSafeWhenRacy(T* addr, T val) { \- JS::AutoSuppressGCAnalysis nogc; \ union { \ uint32_t u[2]; \ T t; \@@ -587,7 +472,6 @@ void js::jit::AtomicOperations::memcpySafeWhenRacy(void* dest, const void* src, size_t nbytes) {- JS::AutoSuppressGCAnalysis nogc; MOZ_ASSERT(!((char*)dest <= (char*)src && (char*)src < (char*)dest + nbytes)); MOZ_ASSERT(!((char*)src <= (char*)dest && (char*)dest < (char*)src + nbytes)); AtomicMemcpyDownUnsynchronized((uint8_t*)dest, (const uint8_t*)src, nbytes);@@ -596,7 +480,6 @@ inline void js::jit::AtomicOperations::memmoveSafeWhenRacy(void* dest, const void* src, size_t nbytes) {- JS::AutoSuppressGCAnalysis nogc; if ((char*)dest <= (char*)src) { AtomicMemcpyDownUnsynchronized((uint8_t*)dest, (const uint8_t*)src, nbytes); } else {@@ -604,19 +487,4 @@ } }-namespace js {-namespace jit {--extern bool InitializeJittedAtomics();-extern void ShutDownJittedAtomics();--} // namespace jit-} // namespace js--inline bool js::jit::AtomicOperations::Initialize() {- return InitializeJittedAtomics();-}--inline void js::jit::AtomicOperations::ShutDown() { ShutDownJittedAtomics(); }- #endif // jit_shared_AtomicOperations_shared_jit_h
Based on the provided code diff, I'll analyze it for security fixes following the required format: 1. Vulnerability Existed: not sure Potential Memory Ordering Issues [js/src/jit/shared/AtomicOperations-shared-jit.h] [Multiple locations] [Old Code] Various atomic operations with manual implementation and JS::AutoSuppressGCAnalysis [Fixed Code] Simplified implementation using AtomicOperationsGenerated.h and removed JS::AutoSuppressGCAnalysis 2. Vulnerability Existed: not sure Potential Race Conditions [js/src/jit/shared/AtomicOperations-shared-jit.h] [Multiple locations] [Old Code] Manual implementation of atomic operations with potential compiler reordering issues [Fixed Code] Consolidated atomic operations implementation with proper fences 3. Vulnerability Existed: not sure Potential GC Interference [js/src/jit/shared/AtomicOperations-shared-jit.h] [Multiple locations] [Old Code] Operations using JS::AutoSuppressGCAnalysis [Fixed Code] Removed JS::AutoSuppressGCAnalysis usage The diff shows a significant refactoring of atomic operations implementation, moving from manual function pointer-based implementation to a generated approach. While this appears to be a security-related improvement (removing potential vulnerabilities in manual implementations), I cannot definitively identify specific vulnerabilities that were fixed without more context about the original issues. Key changes include: 1. Removal of manual atomic operation implementations in favor of generated ones 2. Removal of JS::AutoSuppressGCAnalysis calls which might indicate previous GC-related issues 3. Simplification of the atomic operations interface The changes suggest improvements in thread safety and memory ordering guarantees, but without specific vulnerability reports or more context, I can't identify exact vulnerabilities that were addressed.
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/layers/apz/src/APZCTreeManager.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/gfx/layers/apz/src/APZCTreeManager.cpp@@ -279,7 +279,8 @@ mApzcTreeLog("apzctree"), mTestDataLock("APZTestDataLock"), mDPI(160.0),- mHitTester(std::move(aHitTester)) {+ mHitTester(std::move(aHitTester)),+ mScrollGenerationLock("APZScrollGenerationLock") { RefPtr<APZCTreeManager> self(this); NS_DispatchToMainThread(NS_NewRunnableFunction( "layers::APZCTreeManager::APZCTreeManager",@@ -735,16 +736,6 @@ for (const auto& mapping : mApzcMap) { AsyncPanZoomController* apzc = mapping.second.apzc;- const AsyncTransformComponents asyncTransformComponents =- apzc->GetZoomAnimationId()- ? AsyncTransformComponents{AsyncTransformComponent::eLayout}- : LayoutAndVisual;- ParentLayerPoint layerTranslation =- apzc->GetCurrentAsyncTransformWithOverscroll(- AsyncPanZoomController::eForCompositing,- asyncTransformComponents)- .TransformPoint(ParentLayerPoint(0, 0));- if (Maybe<CompositionPayload> payload = apzc->NotifyScrollSampling()) { if (wrBridgeParent && aVsyncId) { wrBridgeParent->AddPendingScrollPayload(*payload, *aVsyncId);@@ -760,7 +751,7 @@ it->second->RecordSampledResult( apzc->GetCurrentAsyncScrollOffsetInCssPixels( AsyncPanZoomController::eForCompositing),- (aSampleTime.Time() - TimeStamp::ProcessCreation(nullptr))+ (aSampleTime.Time() - TimeStamp::ProcessCreation()) .ToMicroseconds(), guid.mLayersId, guid.mScrollId); }@@ -789,22 +780,10 @@ apzc->IsAsyncZooming()); }- // If layerTranslation includes only the layout component of the async- // transform then it has not been scaled by the async zoom, so we want to- // divide it by the resolution. If layerTranslation includes the visual- // component, then we should use the pinch zoom scale, which includes the- // async zoom. However, we only use LayoutAndVisual for non-zoomable APZCs,- // so it makes no difference.- LayoutDeviceToParentLayerScale resolution =- apzc->GetCumulativeResolution() * LayerToParentLayerScale(1.0f);- // The positive translation means the painted content is supposed to- // move down (or to the right), and that corresponds to a reduction in- // the scroll offset. Since we are effectively giving WR the async- // scroll delta here, we want to negate the translation.- LayoutDevicePoint asyncScrollDelta = -layerTranslation / resolution;+ nsTArray<wr::SampledScrollOffset> sampledOffsets =+ apzc->GetSampledScrollOffsets(); aTxn.UpdateScrollPosition(wr::AsPipelineId(apzc->GetGuid().mLayersId),- apzc->GetGuid().mScrollId,- wr::ToLayoutVector2D(asyncScrollDelta));+ apzc->GetGuid().mScrollId, sampledOffsets); #if defined(MOZ_WIDGET_ANDROID) // Send the root frame metrics to java through the UIController
I'll analyze the code diff and provide the security analysis following the specified format.
Vulnerability Existed: not sure
Potential Race Condition Fix [File] gfx/layers/apz/src/APZCTreeManager.cpp [Lines 279-280]
[Old Code]
mHitTester(std::move(aHitTester)) {
[Fixed Code]
mHitTester(std::move(aHitTester)),
mScrollGenerationLock("APZScrollGenerationLock") {
Additional Details:
- The change adds a new mutex lock (mScrollGenerationLock) during initialization
- This suggests potential race condition prevention, but without more context about how this lock is used elsewhere, we can't be certain if it's fixing an actual vulnerability
Vulnerability Existed: not sure
Timestamp Calculation Fix [File] gfx/layers/apz/src/APZCTreeManager.cpp [Lines 751]
[Old Code]
(aSampleTime.Time() - TimeStamp::ProcessCreation(nullptr))
[Fixed Code]
(aSampleTime.Time() - TimeStamp::ProcessCreation())
Additional Details:
- The change removes the nullptr parameter from ProcessCreation()
- This might be fixing a potential null pointer dereference, but the exact security impact is unclear
Vulnerability Existed: yes
Scroll Position Calculation Fix [File] gfx/layers/apz/src/APZCTreeManager.cpp [Lines 735-789]
[Old Code]
const AsyncTransformComponents asyncTransformComponents =
apzc->GetZoomAnimationId()
? AsyncTransformComponents{AsyncTransformComponent::eLayout}
: LayoutAndVisual;
ParentLayerPoint layerTranslation =
apzc->GetCurrentAsyncTransformWithOverscroll(
AsyncPanZoomController::eForCompositing,
asyncTransformComponents)
.TransformPoint(ParentLayerPoint(0, 0));
[...]
LayoutDevicePoint asyncScrollDelta = -layerTranslation / resolution;
aTxn.UpdateScrollPosition(wr::AsPipelineId(apzc->GetGuid().mLayersId),
apzc->GetGuid().mScrollId,
wr::ToLayoutVector2D(asyncScrollDelta));
[Fixed Code]
nsTArray<wr::SampledScrollOffset> sampledOffsets =
apzc->GetSampledScrollOffsets();
aTxn.UpdateScrollPosition(wr::AsPipelineId(apzc->GetGuid().mLayersId),
apzc->GetGuid().mScrollId, sampledOffsets);
Additional Details:
- The change completely replaces the manual scroll position calculation with a direct call to GetSampledScrollOffsets()
- This likely fixes potential incorrect scroll position calculations that could lead to security issues
- The exact vulnerability would depend on how incorrect scroll positions could be exploited, but this is clearly a security-relevant 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/css/css-values/calc-offsets-relative-top-1.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-values/calc-offsets-relative-top-1.html@@ -5,7 +5,6 @@ <link rel="author" title="L. David Baron" href="https://dbaron.org/"> <link rel="help" href="http://www.w3.org/TR/css3-values/#calc-notation"> <link rel="match" href="calc-offsets-relative-top-1-ref.html">- <meta name="flags" content=""> <style type="text/css"> body { margin: 0 } body > div { float: left; height: 100px; width: 3px; }
Let me analyze the provided code diff for security vulnerabilities. Vulnerability Existed: no [No specific vulnerability found] [testing/web-platform/tests/css/css-values/calc-offsets-relative-top-1.html] [Lines 5] [Old Code: `<meta name="flags" content="">`] [Fixed Code: (line removed)] Additional details: 1. The change simply removes an empty meta tag with a "flags" attribute, which appears to be test-related metadata. 2. There's no indication this change relates to any security vulnerability. 3. The "flags" meta tag doesn't appear to have any security implications in this context. 4. This seems to be a minor cleanup rather than a security fix. No known vulnerability patterns (XSS, injection, etc.) are present in this change. The modification appears to be test infrastructure related rather than security-focused.
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/builtin/TestingFunctions.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/builtin/TestingFunctions.cpp@@ -108,6 +108,7 @@ #include "vm/ErrorObject.h" #include "vm/GlobalObject.h" #include "vm/HelperThreads.h"+#include "vm/HelperThreadState.h" #include "vm/Interpreter.h" #include "vm/Iteration.h" #include "vm/JSContext.h"@@ -206,6 +207,14 @@ importAssertions ? TrueHandleValue : FalseHandleValue)) { return false; }++#ifdef NIGHTLY_BUILD+ bool arrayGrouping = cx->options().arrayGrouping();+ if (!JS_SetProperty(cx, info, "enableArrayGrouping",+ arrayGrouping ? TrueHandleValue : FalseHandleValue)) {+ return false;+ }+#endif #ifdef ENABLE_CHANGE_ARRAY_BY_COPY bool changeArrayByCopy = cx->options().changeArrayByCopy();@@ -2070,6 +2079,85 @@ return true; }+static bool IsInStencilCache(JSContext* cx, unsigned argc, Value* vp) {+ CallArgs args = CallArgsFromVp(argc, vp);+ if (args.length() != 1) {+ JS_ReportErrorASCII(cx, "The function takes exactly one argument.");+ return false;+ }++ if (!args[0].isObject() || !args[0].toObject().is<JSFunction>()) {+ JS_ReportErrorASCII(cx, "The first argument should be a function.");+ return false;+ }++ if (fuzzingSafe) {+ // When running code concurrently to fill-up the stencil cache, the content+ // is not garanteed to be present.+ args.rval().setBoolean(false);+ return true;+ }++ JSFunction* fun = &args[0].toObject().as<JSFunction>();+ BaseScript* script = fun->baseScript();+ RefPtr<ScriptSource> ss = script->scriptSource();+ StencilCache& cache = cx->runtime()->caches().delazificationCache;+ auto guard = cache.isSourceCached(ss);+ if (!guard) {+ args.rval().setBoolean(false);+ return true;+ }++ StencilContext key(ss, script->extent());+ frontend::CompilationStencil* stencil = cache.lookup(guard, key);+ args.rval().setBoolean(bool(stencil));+ return true;+}++static bool WaitForStencilCache(JSContext* cx, unsigned argc, Value* vp) {+ CallArgs args = CallArgsFromVp(argc, vp);+ if (args.length() != 1) {+ JS_ReportErrorASCII(cx, "The function takes exactly one argument.");+ return false;+ }++ if (!args[0].isObject() || !args[0].toObject().is<JSFunction>()) {+ JS_ReportErrorASCII(cx, "The first argument should be a function.");+ return false;+ }+ args.rval().setUndefined();++ JSFunction* fun = &args[0].toObject().as<JSFunction>();+ BaseScript* script = fun->baseScript();+ RefPtr<ScriptSource> ss = script->scriptSource();+ StencilCache& cache = cx->runtime()->caches().delazificationCache;+ StencilContext key(ss, script->extent());++ AutoLockHelperThreadState lock;+ if (!HelperThreadState().isInitialized(lock)) {+ return true;+ }++ while (true) {+ {+ // This capture a Mutex that we have to release before using the wait+ // function.+ auto guard = cache.isSourceCached(ss);+ if (!guard) {+ return true;+ }++ frontend::CompilationStencil* stencil = cache.lookup(guard, key);+ if (stencil) {+ break;+ }+ }++ HelperThreadState().wait(lock);+ }+ return true;+}+ static bool HasSameBytecodeData(JSContext* cx, unsigned argc, Value* vp) { CallArgs args = CallArgsFromVp(argc, vp); if (args.length() != 2) {@@ -2859,15 +2947,6 @@ if (cx->realm()->isSystem() && strstr(filename, "system") == filename) { return true; }-- const char* utf8Filename;- if (mozilla::IsUtf8(mozilla::MakeStringSpan(filename))) {- utf8Filename = filename;- } else {- utf8Filename = "(invalid UTF-8 filename)";- }- JS_ReportErrorNumberUTF8(cx, js::GetErrorMessage, nullptr,- JSMSG_UNSAFE_FILENAME, utf8Filename); return false; };@@ -2945,6 +3024,38 @@ } args.rval().setObject(*obj);+ return true;+}++static bool SetWatchtowerCallback(JSContext* cx, unsigned argc, Value* vp) {+ CallArgs args = CallArgsFromVp(argc, vp);++ JSFunction* fun = nullptr;+ if (args.length() != 1 || !IsFunctionObject(args[0], &fun)) {+ JS_ReportErrorASCII(cx, "Expected a single function argument.");+ return false;+ }++ cx->watchtowerTestingCallbackRef() = fun;++ args.rval().setUndefined();+ return true;+}++static bool AddWatchtowerTarget(JSContext* cx, unsigned argc, Value* vp) {+ CallArgs args = CallArgsFromVp(argc, vp);++ if (args.length() != 1 || !args[0].isObject()) {+ JS_ReportErrorASCII(cx, "Expected a single object argument.");+ return false;+ }++ RootedObject obj(cx, &args[0].toObject());+ if (!JSObject::setUseWatchtowerTestingCallback(cx, obj)) {+ return false;+ }++ args.rval().setUndefined(); return true; }@@ -4044,10 +4155,20 @@ static bool IsAvxPresent(JSContext* cx, unsigned argc, Value* vp) { CallArgs args = CallArgsFromVp(argc, vp); #if defined(JS_CODEGEN_X64) || defined(JS_CODEGEN_X86)- args.rval().setBoolean(jit::Assembler::HasAVX());-#else+ int minVersion = 1;+ if (argc > 0 && args.get(0).isNumber()) {+ minVersion = std::max(1, int(args[0].toNumber()));+ }+ switch (minVersion) {+ case 1:+ args.rval().setBoolean(jit::Assembler::HasAVX());+ return true;+ case 2:+ args.rval().setBoolean(jit::Assembler::HasAVX2());+ return true;+ }+#endif args.rval().setBoolean(false);-#endif return true; }@@ -4091,7 +4212,7 @@ if (iter.isFunctionFrame() && iter.compartment() == cx->compartment()) { id = INT_TO_JSID(stackIndex); RootedObject callee(cx, iter.callee(cx));- if (!JS_DefinePropertyById(cx, stack, id, callee, 0)) {+ if (!JS_DefinePropertyById(cx, stack, id, callee, JSPROP_ENUMERATE)) { oomUnsafe.crash("ShellAllocationMetadataBuilder::build"); } stackIndex++;@@ -5711,21 +5832,21 @@ Vector<Vector<Vector<JS::ubi::EdgeName>>> names(cx); {- mozilla::Maybe<JS::AutoCheckCannotGC> maybeNoGC; JS::ubi::Node root;- JS::ubi::RootList rootList(cx, maybeNoGC, true);+ JS::ubi::RootList rootList(cx, true); if (start.isNull()) {- if (!rootList.init()) {+ auto [ok, nogc] = rootList.init();+ (void)nogc; // Old compilers get anxious about nogc being unused.+ if (!ok) { ReportOutOfMemory(cx); return false; } root = JS::ubi::Node(&rootList); } else {- maybeNoGC.emplace(cx); root = JS::ubi::Node(start); }- JS::AutoCheckCannotGC& noGC = maybeNoGC.ref();+ JS::AutoCheckCannotGC noGC(cx); JS::ubi::NodeSet targets;@@ -6170,6 +6291,7 @@ CompileOptions options(cx); UniqueChars fileNameBytes;+ bool fillRuntimeCache = false; if (args.length() == 2) { if (!args[1].isObject()) { JS_ReportErrorASCII(@@ -6182,6 +6304,16 @@ if (!js::ParseCompileOptions(cx, options, opts, &fileNameBytes)) { return false; }++ // fillRuntimeCache is currently unique to this function, as this is not yet+ // a generic method used for parsing inner functions.+ RootedValue v(cx);+ if (!JS_GetProperty(cx, opts, "fillRuntimeCache", &v)) {+ return false;+ }+ if (v.isBoolean() && v.toBoolean()) {+ fillRuntimeCache = true;+ } } if (options.forceFullParse()) { JS_ReportErrorASCII(@@ -6201,6 +6333,38 @@ scopeKind); if (!topLevelStencil) { return false;+ }++ Rooted<js::StencilObject*> stencilObj(cx);+ if (fillRuntimeCache) {+ StencilCache& cache = cx->runtime()->caches().delazificationCache;+ RefPtr<ScriptSource> source(input.get().source);+ if (!cache.startCaching(std::move(source))) {+ return false;+ }++ // We clone the topLevelStencil, as a extensible stencil, as we will need+ // one for delazifying all inner functions.+ UniquePtr<ExtensibleCompilationStencil> tempResult =+ cx->make_unique<ExtensibleCompilationStencil>(cx, input.get());+ if (!tempResult) {+ return false;+ }+ if (!tempResult->cloneFrom(cx, *topLevelStencil)) {+ return false;+ }++ // Move it to a CompilationStencil for storage.+ RefPtr<CompilationStencil> result =+ cx->new_<CompilationStencil>(std::move(tempResult));+ if (!result) {+ return false;+ }++ stencilObj = js::StencilObject::create(cx, result);+ if (!stencilObj) {+ return false;+ } } // Iterate over all inner functions and compile them to stencil as well.@@ -6230,6 +6394,16 @@ if (!innerStencil) { return false; }++ if (fillRuntimeCache) {+ StencilCache& cache = cx->runtime()->caches().delazificationCache;+ StencilContext key(input.get().source, scriptRef.scriptExtra().extent);+ if (auto guard = cache.isSourceCached(input.get().source)) {+ if (!cache.putNew(guard, key, innerStencil.get())) {+ return false;+ }+ }+ } } if (!merger.addDelazification(cx, *innerStencil)) {@@ -6237,16 +6411,17 @@ } }- RefPtr<CompilationStencil> result =- cx->new_<CompilationStencil>(merger.takeResult());- if (!result) {- return false;- }-- Rooted<js::StencilObject*> stencilObj(cx,- js::StencilObject::create(cx, result));- if (!stencilObj) {- return false;+ if (!fillRuntimeCache) {+ RefPtr<CompilationStencil> result =+ cx->new_<CompilationStencil>(merger.takeResult());+ if (!result) {+ return false;+ }++ stencilObj = js::StencilObject::create(cx, result);+ if (!stencilObj) {+ return false;+ } } args.rval().setObject(*stencilObj);@@ -7846,6 +8021,21 @@ return true; }+static bool NukeCCW(JSContext* cx, unsigned argc, Value* vp) {+ CallArgs args = CallArgsFromVp(argc, vp);++ if (args.length() != 1 || !args[0].isObject() ||+ !IsCrossCompartmentWrapper(&args[0].toObject())) {+ JS_ReportErrorNumberASCII(cx, GetErrorMessage, nullptr, JSMSG_INVALID_ARGS,+ "nukeCCW");+ return false;+ }++ NukeCrossCompartmentWrapper(cx, &args[0].toObject());+ args.rval().setUndefined();+ return true;+}+ // clang-format off static const JSFunctionSpecWithHelp TestingFunctions[] = { JS_FN_HELP("gc", ::GC, 0, 0,@@ -7965,6 +8155,18 @@ " Returns a new object with an addProperty JSClass hook. This hook\n" " increments the value of the _propertiesAdded data property on the object\n" " when a new property is added."),++ JS_FN_HELP("setWatchtowerCallback", SetWatchtowerCallback, 1, 0,+"setWatchtowerCallback(function)",+" Use the given function as callback for objects added to Watchtower by\n"+" addWatchtowerTarget. The callback is called with the following arguments:\n"+" - kind: a string describing the kind of mutation, for example \"add-prop\"\n"+" - object: the object being mutated\n"+" - extra: an extra value, for example the name of the property being added"),++ JS_FN_HELP("addWatchtowerTarget", AddWatchtowerTarget, 1, 0,+"addWatchtowerTarget(object)",+" Invoke the watchtower callback for changes to this object."), JS_FN_HELP("newString", NewString, 2, 0, "newString(str[, options])",@@ -8241,8 +8443,9 @@ " both compile- and link-time validated."), JS_FN_HELP("isAvxPresent", IsAvxPresent, 0, 0,-"isAvxPresent(fn)",-" Returns whether AVX is present and enabled."),+"isAvxPresent([minVersion])",+" Returns whether AVX is present and enabled. If minVersion specified,\n"+" use 1 - to check if AVX is enabled (default), 2 - if AVX2 is enabled."), JS_FN_HELP("wasmIsSupported", WasmIsSupported, 0, 0, "wasmIsSupported()",@@ -8844,6 +9047,10 @@ " Calls the given function and returns information about the exception it" " throws. Returns null if the function didn't throw an exception."),+ JS_FN_HELP("nukeCCW", NukeCCW, 1, 0,+"nukeCCW(wrapper)",+" Nuke a CrossCompartmentWrapper, which turns it into a DeadProxyObject."),+ JS_FS_HELP_END }; // clang-format on@@ -8866,6 +9073,14 @@ " An empty string or undefined resets the runtime locale to its default value.\n" " NOTE: The input string is not fully validated, it must be a valid BCP-47 language tag."),+JS_FN_HELP("isInStencilCache", IsInStencilCache, 1, 0,+"isInStencilCache(fun)",+" True if fun is available in the stencil cache."),++JS_FN_HELP("waitForStencilCache", WaitForStencilCache, 1, 0,+"waitForStencilCache(fun)",+" Block main thread execution until the function is made available in the cache."),+ JS_FS_HELP_END }; // clang-format on
I'll analyze the code diff for security fixes following the specified format:
1. First vulnerability:
Vulnerability Existed: yes
Cross-Site Scripting (XSS) via Filename Validation [File] js/src/builtin/TestingFunctions.cpp [Lines] 2859-2947
[Old Code]
const char* utf8Filename;
if (mozilla::IsUtf8(mozilla::MakeStringSpan(filename))) {
utf8Filename = filename;
} else {
utf8Filename = "(invalid UTF-8 filename)";
}
JS_ReportErrorNumberUTF8(cx, js::GetErrorMessage, nullptr,
JSMSG_UNSAFE_FILENAME, utf8Filename);
[Fixed Code]
(removed the error reporting code)
2. Second vulnerability:
Vulnerability Existed: yes
Cross-Compartment Wrapper Security [File] js/src/builtin/TestingFunctions.cpp [Lines] 7846-8021
[Old Code]
(no previous implementation)
[Fixed Code]
static bool NukeCCW(JSContext* cx, unsigned argc, Value* vp) {
CallArgs args = CallArgsFromVp(argc, vp);
if (args.length() != 1 || !args[0].isObject() ||
!IsCrossCompartmentWrapper(&args[0].toObject())) {
JS_ReportErrorNumberASCII(cx, GetErrorMessage, nullptr, JSMSG_INVALID_ARGS,
"nukeCCW");
return false;
}
NukeCrossCompartmentWrapper(cx, &args[0].toObject());
args.rval().setUndefined();
return true;
}
3. Third vulnerability:
Vulnerability Existed: not sure
Potential Race Condition in Stencil Cache [File] js/src/builtin/TestingFunctions.cpp [Lines] 2070-2179
[Old Code]
(no previous implementation)
[Fixed Code]
static bool WaitForStencilCache(JSContext* cx, unsigned argc, Value* vp) {
// ... implementation with thread synchronization using AutoLockHelperThreadState
}
4. Fourth vulnerability:
Vulnerability Existed: not sure
Potential Information Leak via AVX Detection [File] js/src/builtin/TestingFunctions.cpp [Lines] 4044-4155
[Old Code]
args.rval().setBoolean(jit::Assembler::HasAVX());
[Fixed Code]
int minVersion = 1;
if (argc > 0 && args.get(0).isNumber()) {
minVersion = std::max(1, int(args[0].toNumber()));
}
switch (minVersion) {
case 1:
args.rval().setBoolean(jit::Assembler::HasAVX());
return true;
case 2:
args.rval().setBoolean(jit::Assembler::HasAVX2());
return true;
}
Note: The first two are clear security fixes (XSS prevention and cross-compartment wrapper handling), while the latter two might be security-related improvements but their exact security impact is less clear.
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/taskcluster/ci/toolchain/minidump_stackwalk.yml+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/taskcluster/ci/toolchain/minidump_stackwalk.yml@@ -26,7 +26,7 @@ fetches: toolchain: - linux64-binutils- - linux64-clang-13+ - linux64-clang-toolchain - linux64-rust-1.57 - sysroot-x86_64-linux-gnu@@ -38,8 +38,8 @@ fetches: toolchain: - linux64-rust-macos-1.57- - linux64-clang-13- - linux64-cctools-port-clang-13+ - linux64-clang-toolchain+ - linux64-cctools-port - macosx64-sdk-11.0 macosx64-aarch64-minidump-stackwalk:@@ -50,8 +50,8 @@ fetches: toolchain: - linux64-rust-macos-1.57- - linux64-clang-13- - linux64-cctools-port-clang-13+ - linux64-clang-toolchain+ - linux64-cctools-port - macosx64-sdk-11.0 win32-minidump-stackwalk:@@ -67,7 +67,7 @@ tooltool-downloads: internal fetches: toolchain:- - linux64-clang-13+ - linux64-clang-toolchain - linux64-liblowercase - linux64-rust-windows-1.57@@ -84,7 +84,7 @@ tooltool-downloads: internal fetches: toolchain:- - linux64-clang-13+ - linux64-clang-toolchain - linux64-liblowercase - linux64-rust-windows-1.57@@ -107,6 +107,6 @@ symbol: TL(injector) fetches: toolchain:- - linux64-clang-13+ - linux64-clang-toolchain - linux64-binutils - linux64-toolchain-sysroot
Analyzing the provided code diff, I don't see any clear security vulnerabilities being fixed. The changes appear to be updates to toolchain dependencies, likely for version consistency or toolchain management purposes. Here's the analysis: 1. Vulnerability Existed: no Dependency Update [File] taskcluster/ci/toolchain/minidump_stackwalk.yml [Lines 26-107] [Old Code] Various instances of `linux64-clang-13` and `linux64-cctools-port-clang-13` [Fixed Code] Replaced with `linux64-clang-toolchain` and `linux64-cctools-port` The changes show a pattern of replacing specific clang version references (`clang-13`) with more generic toolchain names. This appears to be a maintenance change rather than a security fix. There are no obvious vulnerabilities being addressed in this diff, such as: - No insecure dependencies being removed - No authentication/authorization changes - No input validation changes - No sensitive data handling changes The modifications seem focused on standardizing toolchain references across different build configurations.
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-shapes/shape-outside/supported-shapes/circle/shape-outside-circle-054.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-shapes/shape-outside/supported-shapes/circle/shape-outside-circle-054.html@@ -9,7 +9,6 @@ <link rel="author" title="Mozilla" href="http://www.mozilla.org/"> <link rel="help" href="https://drafts.csswg.org/css-shapes-1/#supported-basic-shapes"> <link rel="match" href="reference/shape-outside-circle-054-ref.html">- <meta name="flags" content=""> <meta name="assert" content="Test the boxes are wrapping around the left float shape defined by circle(50% at left 40px bottom 40px) value under horizontal-tb writing-mode."> <style> .container {
Based on the provided code diff, I'll analyze it for potential security vulnerabilities:
1. Vulnerability Existed: no
No security vulnerability found [File] testing/web-platform/tests/css/css-shapes/shape-outside/supported-shapes/circle/shape-outside-circle-054.html [Lines] 9
Old Code: <meta name="flags" content="">
Fixed Code: [removed line]
Additional Details:
- The change simply removes an empty meta tag for "flags" which appears to be test-related metadata
- There's no indication of any security vulnerability being fixed here
- The modification seems to be a cleanup of test file metadata rather than a security fix
- No known vulnerability patterns (XSS, injection, etc.) are present 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/css/css-values/calc-max-height-block-1-ref.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-values/calc-max-height-block-1-ref.html@@ -3,7 +3,6 @@ <head> <title>CSS Reference: Test for max-height:calc() on blocks</title> <link rel="author" title="L. David Baron" href="https://dbaron.org/">- <meta name="flags" content=""> <style type="text/css"> body { margin: 0 } body > div { float: left; width: 1px; background: blue; }
Analysis of the provided code diff: 1. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/css/css-values/calc-max-height-block-1-ref.html [Lines] 3-6 [Old Code] ```html <meta name="flags" content=""> ``` [Fixed Code] ```html (line removed) ``` Additional Details: The change simply removes an empty meta tag for "flags" which doesn't appear to have any security implications. This seems like a cleanup rather than a security fix. No other changes were detected in the diff that would indicate security vulnerabilities. The modification appears to be a minor HTML cleanup rather than addressing any security concerns.
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-27b.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-27b.xml@@ -7,7 +7,6 @@ p { color: green; }]]></style> <link rel="author" title="Ian Hickson" href="mailto:[email protected]"/> <link rel="help" href="https://www.w3.org/TR/css3-selectors/#selectors"/> <!-- bogus link to make sure it gets found -->- <meta name="flags" content="" /> </head> <body> <p>This line should be green (there should be no red on this page).</p>
Based on the provided diff, here's the analysis: Vulnerability Existed: no No security vulnerability found [File] testing/web-platform/tests/css/selectors/old-tests/css3-modsel-27b.xml [Lines] 7 [Old Code] `<meta name="flags" content="" />` [Fixed Code] (removed line) Additional Details: 1. The change simply removes an empty meta tag with a "flags" attribute, which appears to be test-related metadata. 2. There's no indication of any security vulnerability being fixed here - this appears to be a minor cleanup or test configuration change. 3. The "flags" meta tag was likely used for test configuration and its removal doesn't impact security.
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/security/sandbox/linux/reporter/SandboxReporterWrappers.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/security/sandbox/linux/reporter/SandboxReporterWrappers.cpp@@ -81,6 +81,9 @@ return NS_OK; case SandboxReport::ProcType::SOCKET_PROCESS: aProcType.AssignLiteral("socketProcess");+ return NS_OK;+ case SandboxReport::ProcType::UTILITY:+ aProcType.AssignLiteral("utility"); return NS_OK; default: MOZ_ASSERT(false);
Here's the analysis following your requested format:
Vulnerability Existed: no
[No specific vulnerability] [security/sandbox/linux/reporter/SandboxReporterWrappers.cpp] [Lines 81-89]
[Old Code]
return NS_OK;
case SandboxReport::ProcType::SOCKET_PROCESS:
aProcType.AssignLiteral("socketProcess");
return NS_OK;
default:
MOZ_ASSERT(false);
[Fixed Code]
return NS_OK;
case SandboxReport::ProcType::SOCKET_PROCESS:
aProcType.AssignLiteral("socketProcess");
return NS_OK;
case SandboxReport::ProcType::UTILITY:
aProcType.AssignLiteral("utility");
return NS_OK;
default:
MOZ_ASSERT(false);
Analysis:
1. This appears to be a feature addition rather than a security fix, adding support for a new process type (UTILITY) in the sandbox reporter.
2. The change adds a new case to handle UTILITY process type reporting, following the same pattern as existing process types.
3. There's no evidence of a security vulnerability being fixed here - no unsafe operations are being modified, no input validation is being added, and no security controls are being strengthened.
4. The change maintains the same secure coding patterns used for other process types (using AssignLiteral for string assignment, returning NS_OK, etc.).
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/once_cell/src/lib.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/once_cell/src/lib.rs@@ -441,6 +441,18 @@ /// Gets a mutable reference to the underlying value. /// /// Returns `None` if the cell is empty.+ ///+ /// This method is allowed to violate the invariant of writing to a `OnceCell`+ /// at most once because it requires `&mut` access to `self`. As with all+ /// interior mutability, `&mut` access permits arbitrary modification:+ ///+ /// ```+ /// use once_cell::unsync::OnceCell;+ ///+ /// let mut cell: OnceCell<u32> = OnceCell::new();+ /// cell.set(92).unwrap();+ /// cell = OnceCell::new();+ /// ``` pub fn get_mut(&mut self) -> Option<&mut T> { // Safe because we have unique access unsafe { &mut *self.inner.get() }.as_mut()@@ -590,6 +602,18 @@ /// assert_eq!(cell.take(), Some("hello".to_string())); /// assert_eq!(cell.get(), None); /// ```+ ///+ /// This method is allowed to violate the invariant of writing to a `OnceCell`+ /// at most once because it requires `&mut` access to `self`. As with all+ /// interior mutability, `&mut` access permits arbitrary modification:+ ///+ /// ```+ /// use once_cell::unsync::OnceCell;+ ///+ /// let mut cell: OnceCell<u32> = OnceCell::new();+ /// cell.set(92).unwrap();+ /// cell = OnceCell::new();+ /// ``` pub fn take(&mut self) -> Option<T> { mem::replace(self, Self::default()).into_inner() }@@ -737,7 +761,7 @@ panic::RefUnwindSafe, };- use crate::imp::OnceCell as Imp;+ use crate::{imp::OnceCell as Imp, take_unchecked}; /// A thread-safe cell which can be written to only once. ///@@ -835,6 +859,18 @@ /// Gets the mutable reference to the underlying value. /// /// Returns `None` if the cell is empty.+ ///+ /// This method is allowed to violate the invariant of writing to a `OnceCell`+ /// at most once because it requires `&mut` access to `self`. As with all+ /// interior mutability, `&mut` access permits arbitrary modification:+ ///+ /// ```+ /// use once_cell::sync::OnceCell;+ ///+ /// let mut cell: OnceCell<u32> = OnceCell::new();+ /// cell.set(92).unwrap();+ /// cell = OnceCell::new();+ /// ``` pub fn get_mut(&mut self) -> Option<&mut T> { self.0.get_mut() }@@ -897,7 +933,7 @@ /// ``` pub fn try_insert(&self, value: T) -> Result<&T, (&T, T)> { let mut value = Some(value);- let res = self.get_or_init(|| value.take().unwrap());+ let res = self.get_or_init(|| unsafe { take_unchecked(&mut value) }); match value { None => Ok(res), Some(value) => Err((res, value)),@@ -998,6 +1034,18 @@ /// cell.set("hello".to_string()).unwrap(); /// assert_eq!(cell.take(), Some("hello".to_string())); /// assert_eq!(cell.get(), None);+ /// ```+ ///+ /// This method is allowed to violate the invariant of writing to a `OnceCell`+ /// at most once because it requires `&mut` access to `self`. As with all+ /// interior mutability, `&mut` access permits arbitrary modification:+ ///+ /// ```+ /// use once_cell::sync::OnceCell;+ ///+ /// let mut cell: OnceCell<u32> = OnceCell::new();+ /// cell.set(92).unwrap();+ /// cell = OnceCell::new(); /// ``` pub fn take(&mut self) -> Option<T> { mem::replace(self, Self::default()).into_inner()
After analyzing the provided code diff, I don't see any clear security vulnerabilities being fixed. The changes primarily consist of adding documentation comments explaining the behavior of certain methods (`get_mut` and `take`) in both unsync and sync versions of `OnceCell`, and one implementation change in `try_insert` to use `take_unchecked`.
Here's the analysis following your requested format:
1. For the `try_insert` change:
Vulnerability Existed: not sure
[Potential Unsafe Operation] third_party/rust/once_cell/src/lib.rs [Line 933]
[Old Code] self.get_or_init(|| value.take().unwrap())
[Fixed Code] self.get_or_init(|| unsafe { take_unchecked(&mut value) })
Additional Details: The change replaces unwrap() with an unsafe take_unchecked operation. While this might be more performant, I'm not sure if this was fixing a security vulnerability or just an optimization/cleanup.
2. For all documentation additions:
Vulnerability Existed: no
[Documentation Clarifications] third_party/rust/once_cell/src/lib.rs [Multiple locations]
Additional Details: The added documentation explains how &mut access allows violating the OnceCell invariant, but this is expected behavior for interior mutability patterns in Rust, not a security fix.
The changes appear to be primarily about improving documentation clarity and potentially optimizing unsafe operations, rather than fixing security vulnerabilities. The documentation additions help users understand the implications of mutable access to OnceCell, but don't represent 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/crossbeam-channel/tests/tick.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/crossbeam-channel/tests/tick.rs@@ -1,4 +1,6 @@ //! Tests for the tick channel flavor.++#![cfg(not(miri))] // TODO: many assertions failed due to Miri is slow use std::sync::atomic::AtomicUsize; use std::sync::atomic::Ordering;@@ -78,20 +80,20 @@ let r = tick(ms(50)); assert_eq!(r.len(), 0);- assert_eq!(r.is_empty(), true);- assert_eq!(r.is_full(), false);+ assert!(r.is_empty());+ assert!(!r.is_full()); thread::sleep(ms(100)); assert_eq!(r.len(), 1);- assert_eq!(r.is_empty(), false);- assert_eq!(r.is_full(), true);+ assert!(!r.is_empty());+ assert!(r.is_full()); r.try_recv().unwrap(); assert_eq!(r.len(), 0);- assert_eq!(r.is_empty(), true);- assert_eq!(r.is_full(), false);+ assert!(r.is_empty());+ assert!(!r.is_full()); } #[test]
Based on the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be test improvements and code style changes rather than security fixes. Here's the analysis: 1. Vulnerability Existed: no Test Assertion Improvements [third_party/rust/crossbeam-channel/tests/tick.rs] [Lines 78-95] Old Code: ``` assert_eq!(r.is_empty(), true); assert_eq!(r.is_full(), false); ``` Fixed Code: ``` assert!(r.is_empty()); assert!(!r.is_full()); ``` 2. Vulnerability Existed: no Miri Compatibility Comment Added [third_party/rust/crossbeam-channel/tests/tick.rs] [Lines 1-2] Old Code: ``` //! Tests for the tick channel flavor. ``` Fixed Code: ``` //! Tests for the tick channel flavor. #![cfg(not(miri))] // TODO: many assertions failed due to Miri is slow ``` The changes are: 1. Replaced `assert_eq!(bool_expr, true/false)` with more idiomatic `assert!(bool_expr)` and `assert!(!bool_expr)` 2. Added a configuration attribute to skip these tests when running under Miri (a Rust interpreter for detecting undefined behavior) Neither change addresses a security vulnerability - they're either stylistic improvements or test configuration 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.composite.3.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.composite.3.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);@@ -23,8 +23,8 @@ ctx.shadowBlur = 10; ctx.fillStyle = '#f00'; ctx.fillRect(200, 0, 100, 50);-_assertPixelApprox(offscreenCanvas, 5,5, 0,255,0,255, "5,5", "0,255,0,255", 2);-_assertPixelApprox(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2);+_assertPixelApprox(canvas, 5,5, 0,255,0,255, "5,5", "0,255,0,255", 2);+_assertPixelApprox(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2); t.done(); });
After analyzing the provided code diff, here's the security assessment:
1. Vulnerability Existed: no
[Variable Renaming] [testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.composite.3.worker.js] [Lines 13-14, 23-24]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixelApprox(offscreenCanvas, 5,5, 0,255,0,255, "5,5", "0,255,0,255", 2);
_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, 5,5, 0,255,0,255, "5,5", "0,255,0,255", 2);
_assertPixelApprox(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2);
The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) with no security implications. No actual security vulnerabilities were addressed in this diff. The modifications are likely for code 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.