--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/css-break/widows-orphans-003.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-break/widows-orphans-003.html@@ -5,7 +5,6 @@ <link rel="help" href="https://drafts.csswg.org/css-break/#widows-orphans"> <link rel="match" href="reference/widows-orphans-001-ref.html"> <meta name="assert" content="The orphans property has no effect on block container boxes that contains only block-level boxes.">-<meta name="flags" content=""> <style> div p { margin: 0; }

Analyzing the provided code diff, here's the security assessment:

Vulnerability Existed: no
[No specific vulnerability] [testing/web-platform/tests/css/css-break/widows-orphans-003.html] [Lines 5]
[Old Code]
<meta name="flags" content="">
[Fixed Code]
[Line removed]

Additional Details:
- The change simply removes an empty meta tag for "flags" which appears to be test-related metadata
- This doesn't appear to be a security fix but rather a cleanup of test configuration
- No security vulnerability is being addressed in this change
- The modification doesn't affect any security-sensitive functionality

Note: The diff shows only one change, which is the removal of an empty meta tag. This doesn't indicate any security vulnerability being fixed. The change appears to be part of routine test maintenance rather than a security patch.

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.image.destination-over.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.image.destination-over.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = 'rgba(0, 255, 255, 0.5)';@@ -32,7 +32,7 @@ promise.then(function(response) {     createImageBitmap(response).then(bitmap => {         ctx.drawImage(bitmap, 0, 0);-        _assertPixelApprox(offscreenCanvas, 50,25, 109,255,146,223, "50,25", "109,255,146,223", 5);+        _assertPixelApprox(canvas, 50,25, 109,255,146,223, "50,25", "109,255,146,223", 5);     }, t_fail); }).then(t_pass, t_fail);

Analyzing the provided code diff, here's the security assessment:

1. Vulnerability Existed: no
    No security vulnerability found [File] [Lines 13-14, 32]
    [Old Code]
    var offscreenCanvas = new OffscreenCanvas(100, 50);
    var ctx = offscreenCanvas.getContext('2d');
    _assertPixelApprox(offscreenCanvas, 50,25, 109,255,146,223, "50,25", "109,255,146,223", 5);
    
    [Fixed Code]
    var canvas = new OffscreenCanvas(100, 50);
    var ctx = canvas.getContext('2d');
    _assertPixelApprox(canvas, 50,25, 109,255,146,223, "50,25", "109,255,146,223", 5);

Additional Details:
- The changes appear to be purely variable renaming from `offscreenCanvas` to `canvas` for consistency or readability
- No security-related changes were made in this diff
- The functionality remains exactly the same, just with a different variable name
- No known vulnerabilities are addressed by this change
- The change affects test code rather than production code

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/darling/tests/enums_unit.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/darling/tests/enums_unit.rs@@ -1,8 +1,6 @@ //! Test expansion of enum variants which have no associated data.-#[macro_use]-extern crate darling;-extern crate syn;+use darling::FromMeta; #[derive(Debug, FromMeta)] #[darling(rename_all = "snake_case")]

Based on the provided code diff, I'll analyze it for potential security vulnerabilities:

1. Vulnerability Existed: no
   Dependency Update [third_party/rust/darling/tests/enums_unit.rs] [Lines 1-3]
   Old Code:
   ```
   #[macro_use]
   extern crate darling;
   extern crate syn;
   ```
   Fixed Code:
   ```
   use darling::FromMeta;
   ```

This appears to be a simple modernization of Rust code rather than a security fix. The change:
1. Removes the old-style `extern crate` declarations
2. Replaces them with a more modern `use` statement
3. Removes the explicit `syn` dependency which wasn't being used directly in this test file
4. Removes the `#[macro_use]` attribute which is no longer needed with Rust 2018 edition

No security vulnerabilities are being addressed here - this is purely a code style and modernization change. The functionality remains the same, just expressed in a more idiomatic way for newer Rust versions.

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/dom/indexedDB/IDBDatabase.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/indexedDB/IDBDatabase.cpp@@ -623,8 +623,6 @@   MOZ_ALWAYS_TRUE(mBackgroundActor->SendPBackgroundIDBTransactionConstructor(       actor, sortedStoreNames, mode));-  MOZ_ASSERT(actor->GetActorEventTarget(),-             "The event target shall be inherited from it manager actor.");   transaction->SetBackgroundActor(actor);@@ -681,9 +679,6 @@       IDB_LOG_STRINGIFY(this), NS_ConvertUTF16toUTF8(aName).get());   mBackgroundActor->SendPBackgroundIDBDatabaseRequestConstructor(actor, params);--  MOZ_ASSERT(actor->GetActorEventTarget(),-             "The event target shall be inherited from its manager actor.");   return request; }@@ -814,8 +809,6 @@       return nullptr;     }-    MOZ_ASSERT(actor->GetActorEventTarget(),-               "The event target shall be inherited from its manager actor.");     mFileActors.InsertOrUpdate(weakRef, actor);   }

Analyzing the provided code diff for security fixes:

1. Vulnerability Existed: not sure  
   [Removed Assertions] [dom/indexedDB/IDBDatabase.cpp] [Lines 623-624, 681-682, 814-815]  
   [Old Code]  
   ```cpp
   MOZ_ASSERT(actor->GetActorEventTarget(),
              "The event target shall be inherited from it manager actor.");
   ```  
   [Fixed Code]  
   ```cpp
   // Assertion removed
   ```  
   Additional Details: The diff shows removal of several MOZ_ASSERT statements checking for actor event targets. While assertions are typically for debugging and not security mechanisms, their removal might indicate a change in assumptions about actor initialization. Without more context, it's unclear if this relates to a specific vulnerability.

2. Vulnerability Existed: not sure  
   [Potential Race Condition] [dom/indexedDB/IDBDatabase.cpp] [Lines 814-815]  
   [Old Code]  
   ```cpp
   MOZ_ASSERT(actor->GetActorEventTarget(),
              "The event target shall be inherited from its manager actor.");
   mFileActors.InsertOrUpdate(weakRef, actor);
   ```  
   [Fixed Code]  
   ```cpp
   mFileActors.InsertOrUpdate(weakRef, actor);
   ```  
   Additional Details: The removal of the assertion before inserting/updating file actors could potentially relate to race condition handling, but this is speculative without more context about the actor initialization guarantees.

Note: The changes primarily involve removal of debug assertions rather than obvious security fixes. While assertions can sometimes catch security-relevant conditions, these particular checks appear to be more about ensuring proper actor initialization rather than preventing specific vulnerabilities. The changes might be related to making the code more robust against edge cases rather than fixing 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/services/settings/dumps/main/search-telemetry-v2.json+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/services/settings/dumps/main/search-telemetry-v2.json@@ -1,5 +1,39 @@ {   "data": [+    {+      "schema": 1647536413492,+      "taggedCodes": [+        "ffab",+        "ffcm",+        "ffhp",+        "ffip",+        "ffit",+        "ffnt",+        "ffocus",+        "ffos",+        "ffsb",+        "fpas",+        "fpsa",+        "ftas",+        "ftsa",+        "newext"+      ],+      "telemetryId": "duckduckgo",+      "organicCodes": [],+      "codeParamName": "t",+      "queryParamName": "q",+      "searchPageRegexp": "^https://duckduckgo\\.com/",+      "expectedOrganicCodes": [+        "hz",+        "h_"+      ],+      "extraAdServersRegexps": [+        "^https://duckduckgo.com/y\\.js?.*ad_provider\\=",+        "^https://www\\.amazon\\.(?:[a-z.]{2,24}).*(?:tag=duckduckgo-)"+      ],+      "id": "9dfd626b-26f2-4913-9d0a-27db6cb7d8ca",+      "last_modified": 1647619735693+    },     {       "schema": 1643096116299,       "taggedCodes": [@@ -86,36 +120,6 @@       "last_modified": 1643136933998     },     {-      "schema": 1643100257574,-      "taggedCodes": [-        "ffab",-        "ffcm",-        "ffhp",-        "ffip",-        "ffit",-        "ffnt",-        "ffocus",-        "ffos",-        "ffsb",-        "fpas",-        "fpsa",-        "ftas",-        "ftsa",-        "newext"-      ],-      "telemetryId": "duckduckgo",-      "organicCodes": [],-      "codeParamName": "t",-      "queryParamName": "q",-      "searchPageRegexp": "^https://duckduckgo\\.com/",-      "extraAdServersRegexps": [-        "^https://duckduckgo.com/y\\.js?.*ad_provider\\=",-        "^https://www\\.amazon\\.(?:[a-z.]{2,24}).*(?:tag=duckduckgo-)"-      ],-      "id": "9dfd626b-26f2-4913-9d0a-27db6cb7d8ca",-      "last_modified": 1643136933995-    },-    {       "schema": 1643100258578,       "telemetryId": "yahoo",       "queryParamName": "p",

Based on the provided diff, I'll analyze it for potential security vulnerabilities:

1. Vulnerability Existed: not sure
[Potential Information Disclosure] [services/settings/dumps/main/search-telemetry-v2.json] [Lines 1-39]
[Old Code: No DuckDuckGo configuration present]
[Fixed Code: Added detailed DuckDuckGo search configuration including regex patterns and tracking codes]

2. Vulnerability Existed: not sure
[Potential Regex Injection] [services/settings/dumps/main/search-telemetry-v2.json] [Lines 27-29]
[Old Code: N/A (new addition)]
[Fixed Code: Added regex patterns "^https://duckduckgo.com/y\\.js?.*ad_provider\\=" and "^https://www\\.amazon\\.(?:[a-z.]{2,24}).*(?:tag=duckduckgo-)"]

3. Vulnerability Existed: not sure
[Potential Tracking Code Exposure] [services/settings/dumps/main/search-telemetry-v2.json] [Lines 3-17]
[Old Code: N/A (new addition)]
[Fixed Code: Added multiple tracking codes ("ffab", "ffcm", etc.) and telemetryId]

Note: This appears to be a configuration update rather than a direct security fix. The changes involve adding new search telemetry configuration for DuckDuckGo, including tracking codes and URL patterns. While not clearly a security vulnerability fix, there could be security implications in how these patterns are used elsewhere in the system. The main changes involve:
1. Adding a new DuckDuckGo configuration block
2. Removing an older version of the DuckDuckGo configuration
3. Adding more detailed tracking and URL matching patterns

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/syn/src/lib.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/syn/src/lib.rs@@ -250,16 +250,18 @@ //!   dynamic library libproc_macro from rustc toolchain. // Syn types in rustdoc of other crates get linked to here.-#![doc(html_root_url = "https://docs.rs/syn/1.0.82")]+#![doc(html_root_url = "https://docs.rs/syn/1.0.85")] #![cfg_attr(doc_cfg, feature(doc_cfg))] #![allow(non_camel_case_types)] // Ignored clippy lints. #![allow(+    clippy::cast_lossless,     clippy::collapsible_match, // https://github.com/rust-lang/rust-clippy/issues/7575     clippy::doc_markdown,     clippy::eval_order_dependence,     clippy::inherent_to_string,     clippy::large_enum_variant,+    clippy::let_underscore_drop,     clippy::manual_assert,     clippy::manual_map, // https://github.com/rust-lang/rust-clippy/issues/6795     clippy::match_on_vec_items,@@ -267,6 +269,7 @@     clippy::needless_doctest_main,     clippy::needless_pass_by_value,     clippy::never_loop,+    clippy::return_self_not_must_use,     clippy::too_many_arguments,     clippy::trivially_copy_pass_by_ref,     clippy::unnecessary_unwrap,

After analyzing the provided code diff, I don't see any security-related fixes. The changes appear to be version updates and linter configuration adjustments. Here's the structured response:

Vulnerability Existed: no
No security vulnerability found in the diff. Changes are related to version updates and linter configurations.

The main changes are:
1. Updated documentation URL version from 1.0.82 to 1.0.85
2. Added new allowed clippy lints:
   - clippy::cast_lossless
   - clippy::let_underscore_drop
   - clippy::return_self_not_must_use

These changes don't appear to address any security vulnerabilities but rather maintain code quality and documentation accuracy.

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.hsl-4.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.hsl-4.html@@ -17,14 +17,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillStyle = 'hsl(-360240, 100%, 50%)'; 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 found] [testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.hsl-4.html] [Lines 17-25]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
ctx.fillStyle = '#f00';
ctx.fillStyle = 'hsl(-360240, 100%, 50%)';
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 = '#f00';
ctx.fillStyle = 'hsl(-360240, 100%, 50%)';
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, changing the variable name from `offscreenCanvas` to `canvas`. There's no indication of any security vulnerability being fixed in this change. The test logic remains exactly the same, only the variable name was updated for consistency or clarity.

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/line-styles/2d.line.join.valid.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/line-styles/2d.line.join.valid.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.lineJoin = 'bevel' _assertSame(ctx.lineJoin, 'bevel', "ctx.lineJoin", "'bevel'");

Analysis of the provided code diff:

1. Vulnerability Existed: no
    No security vulnerability found [testing/web-platform/tests/html/canvas/offscreen/line-styles/2d.line.join.valid.html] [Lines 17-18]
    Old Code:
    var offscreenCanvas = new OffscreenCanvas(100, 50);
    var ctx = offscreenCanvas.getContext('2d');
    
    Fixed Code:
    var canvas = new OffscreenCanvas(100, 50);
    var ctx = canvas.getContext('2d');

Additional Notes:
- The change appears to be a simple variable renaming from `offscreenCanvas` to `canvas`
- No security implications are evident in this change
- The modification seems to be for code consistency/readability rather than security fixes
- No known vulnerability patterns are present in either the old or new code

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.rgb-clamp-5.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.rgb-clamp-5.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 = '#f00'; ctx.fillStyle = 'rgb(-10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, -10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000)'; 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(); });

I'll analyze the provided code diff for security fixes following the specified format.

Vulnerability Existed: not sure
[Potential Integer Overflow/Underflow] [testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.rgb-clamp-5.worker.js] [Lines 17-19]
[Old Code]
ctx.fillStyle = 'rgb(-10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000, -10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000)';
[Fixed Code]
(same code, but variable name changed)

Notes:
1. The main change appears to be renaming `offscreenCanvas` to `canvas` and updating the assertion accordingly.
2. The test case still contains extremely large numbers in the RGB values, which could potentially cause integer overflow/underflow issues if not properly clamped.
3. Since this is a test file, it's likely testing the browser's handling of such extreme values rather than fixing a vulnerability.
4. No actual security fix is visible in the diff, just a variable name 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/dom/webgpu/Instance.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/webgpu/Instance.cpp@@ -12,7 +12,7 @@ #include "ipc/WebGPUTypes.h" #include "mozilla/webgpu/ffi/wgpu.h" #include "mozilla/dom/Promise.h"-#include "mozilla/layers/CompositorBridgeChild.h"+#include "mozilla/gfx/CanvasManagerChild.h" namespace mozilla { namespace webgpu {@@ -24,7 +24,7 @@   RefPtr<WebGPUChild> bridge;   if (gfx::gfxConfig::IsEnabled(gfx::Feature::WEBGPU)) {-    bridge = layers::CompositorBridgeChild::Get()->GetWebGPUChild();+    bridge = gfx::CanvasManagerChild::Get()->GetWebGPUChild();     if (NS_WARN_IF(!bridge)) {       MOZ_CRASH("Failed to create an IPDL bridge for WebGPU!");     }@@ -72,8 +72,7 @@         if (aResponseReason.isSome()) {           promise->MaybeRejectWithAbortError("Internal communication error!");         } else {-          promise->MaybeRejectWithInvalidStateError(-              "No matching adapter found!");+          promise->MaybeResolve(JS::NullHandleValue);         }       });

Here's the analysis of the provided code diff following the specified format:

1. Vulnerability Existed: not sure  
   [Dependency Change] [dom/webgpu/Instance.cpp] [Lines 12,24]  
   [Old Code]  
   `#include "mozilla/layers/CompositorBridgeChild.h"`  
   `bridge = layers::CompositorBridgeChild::Get()->GetWebGPUChild();`  
   [Fixed Code]  
   `#include "mozilla/gfx/CanvasManagerChild.h"`  
   `bridge = gfx::CanvasManagerChild::Get()->GetWebGPUChild();`  
   Additional Details: This appears to be an architectural change rather than a security fix. The dependency was changed from CompositorBridgeChild to CanvasManagerChild, but it's unclear if this addresses any specific vulnerability.

2. Vulnerability Existed: not sure  
   [Error Handling Change] [dom/webgpu/Instance.cpp] [Lines 72-74]  
   [Old Code]  
   `promise->MaybeRejectWithInvalidStateError("No matching adapter found!");`  
   [Fixed Code]  
   `promise->MaybeResolve(JS::NullHandleValue);`  
   Additional Details: The error handling behavior was changed to resolve with null instead of rejecting with an error. This might be related to API behavior changes rather than security, but could potentially affect how applications handle WebGPU initialization failures.

Note: Neither change clearly indicates a specific CVE or well-known vulnerability. The changes appear to be more about architectural improvements and API behavior modifications rather than direct 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/warp/src/lib.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/warp/src/lib.rs@@ -1,4 +1,4 @@-#![doc(html_root_url = "https://docs.rs/warp/0.2.2")]+#![doc(html_root_url = "https://docs.rs/warp/0.2.3")] #![deny(missing_docs)] #![deny(missing_debug_implementations)] #![cfg_attr(test, deny(warnings))]@@ -106,6 +106,9 @@ // This otherwise shows a big dump of re-exports in the doc homepage, // with zero context, so just hide it from the docs. Doc examples // on each can show that a convenient import exists.+#[cfg(feature = "compression")]+#[doc(hidden)]+pub use self::filters::compression; #[cfg(feature = "multipart")] #[doc(hidden)] pub use self::filters::multipart;

Based on the provided diff, I don't see any clear security vulnerabilities being fixed. The changes appear to be documentation and version updates. Here's the analysis:

1. Version update:
    Vulnerability Existed: no
    Version Update [File] [Lines 1]
    Old Code: #![doc(html_root_url = "https://docs.rs/warp/0.2.2")]
    Fixed Code: #![doc(html_root_url = "https://docs.rs/warp/0.2.3")]

2. Documentation addition:
    Vulnerability Existed: no
    Documentation Addition [File] [Lines 106-108]
    Old Code: (no code existed here before)
    Fixed Code: #[cfg(feature = "compression")]
    #[doc(hidden)]
    pub use self::filters::compression;

Neither change appears to address any security vulnerability. The first is a version bump, and the second adds documentation for a compression feature that was likely already present in the code but not properly documented.

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/layout/generic/nsHTMLCanvasFrame.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/layout/generic/nsHTMLCanvasFrame.cpp@@ -95,8 +95,7 @@   virtual nsRect GetBounds(nsDisplayListBuilder* aBuilder,                            bool* aSnap) const override {     *aSnap = true;-    nsHTMLCanvasFrame* f = static_cast<nsHTMLCanvasFrame*>(Frame());-    return f->GetInnerArea() + ToReferenceFrame();+    return Frame()->GetContentRectRelativeToSelf() + ToReferenceFrame();   }   virtual bool CreateWebRenderCommands(@@ -397,16 +396,6 @@ NS_IMPL_FRAMEARENA_HELPERS(nsHTMLCanvasFrame)-void nsHTMLCanvasFrame::Init(nsIContent* aContent, nsContainerFrame* aParent,-                             nsIFrame* aPrevInFlow) {-  nsContainerFrame::Init(aContent, aParent, aPrevInFlow);--  // We can fill in the canvas before the canvas frame is created, in-  // which case we never get around to marking the content as active. Therefore,-  // we mark it active here when we create the frame.-  ActiveLayerTracker::NotifyContentChange(this);-}- void nsHTMLCanvasFrame::DestroyFrom(nsIFrame* aDestroyRoot,                                     PostDestroyData& aPostDestroyData) {   if (IsPrimaryFrame()) {@@ -509,19 +498,7 @@   MOZ_ASSERT(mState & NS_FRAME_IN_REFLOW, "frame is not in reflow");   WritingMode wm = aReflowInput.GetWritingMode();-  LogicalSize finalSize = aReflowInput.ComputedSize();--  // stash this away so we can compute our inner area later-  mBorderPadding = aReflowInput.ComputedLogicalBorderPadding(wm);--  finalSize.ISize(wm) += mBorderPadding.IStartEnd(wm);-  finalSize.BSize(wm) += mBorderPadding.BStartEnd(wm);--  if (GetPrevInFlow()) {-    nscoord y = GetContinuationOffset(&finalSize.ISize(wm));-    finalSize.BSize(wm) -= y + mBorderPadding.BStart(wm);-    finalSize.BSize(wm) = std::max(0, finalSize.BSize(wm));-  }+  const LogicalSize finalSize = aReflowInput.ComputedSizeWithBorderPadding(wm);   aMetrics.SetSize(wm, finalSize);   aMetrics.SetOverflowAreasToDesiredBounds();@@ -548,20 +525,6 @@   NS_FRAME_SET_TRUNCATION(aStatus, aReflowInput, aMetrics); }-// FIXME taken from nsImageFrame, but then had splittable frame stuff-// removed.  That needs to be fixed.-// XXXdholbert As in nsImageFrame, this function's clients should probably-// just be calling GetContentRectRelativeToSelf().-nsRect nsHTMLCanvasFrame::GetInnerArea() const {-  nsMargin bp = mBorderPadding.GetPhysicalMargin(GetWritingMode());-  nsRect r;-  r.x = bp.left;-  r.y = bp.top;-  r.width = mRect.width - bp.left - bp.right;-  r.height = mRect.height - bp.top - bp.bottom;-  return r;-}- bool nsHTMLCanvasFrame::UpdateWebRenderCanvasData(     nsDisplayListBuilder* aBuilder, WebRenderCanvasData* aCanvasData) {   HTMLCanvasElement* element = static_cast<HTMLCanvasElement*>(GetContent());@@ -586,29 +549,6 @@   DisplaySelectionOverlay(aBuilder, aLists.Content(),                           nsISelectionDisplay::DISPLAY_IMAGES);-}--// get the offset into the content area of the image where aImg starts if it is-// a continuation. from nsImageFrame-nscoord nsHTMLCanvasFrame::GetContinuationOffset(nscoord* aWidth) const {-  nscoord offset = 0;-  if (aWidth) {-    *aWidth = 0;-  }--  if (GetPrevInFlow()) {-    for (nsIFrame* prevInFlow = GetPrevInFlow(); prevInFlow;-         prevInFlow = prevInFlow->GetPrevInFlow()) {-      nsRect rect = prevInFlow->GetRect();-      if (aWidth) {-        *aWidth = rect.width;-      }-      offset += rect.height;-    }-    offset -= mBorderPadding.GetPhysicalMargin(GetWritingMode()).top;-    offset = std::max(0, offset);-  }-  return offset; } void nsHTMLCanvasFrame::AppendDirectlyOwnedAnonBoxes(

Analyzing the provided code diff, here are the security-related findings:

1. Vulnerability Existed: not sure
   [Potential Memory Safety Issue] [layout/generic/nsHTMLCanvasFrame.cpp] [Lines: 95-96]
   [Old Code]
   nsHTMLCanvasFrame* f = static_cast<nsHTMLCanvasFrame*>(Frame());
   return f->GetInnerArea() + ToReferenceFrame();
   [Fixed Code]
   return Frame()->GetContentRectRelativeToSelf() + ToReferenceFrame();

2. Vulnerability Existed: not sure
   [Potential Integer Overflow] [layout/generic/nsHTMLCanvasFrame.cpp] [Lines: 509-520]
   [Old Code]
   LogicalSize finalSize = aReflowInput.ComputedSize();
   mBorderPadding = aReflowInput.ComputedLogicalBorderPadding(wm);
   finalSize.ISize(wm) += mBorderPadding.IStartEnd(wm);
   finalSize.BSize(wm) += mBorderPadding.BStartEnd(wm);
   [Fixed Code]
   const LogicalSize finalSize = aReflowInput.ComputedSizeWithBorderPadding(wm);

3. Vulnerability Existed: not sure
   [Potential Memory Safety Issue] [layout/generic/nsHTMLCanvasFrame.cpp] [Lines: 548-560]
   [Old Code]
   nsRect nsHTMLCanvasFrame::GetInnerArea() const {
     nsMargin bp = mBorderPadding.GetPhysicalMargin(GetWritingMode());
     nsRect r;
     r.x = bp.left;
     r.y = bp.top;
     r.width = mRect.width - bp.left - bp.right;
     r.height = mRect.height - bp.top - bp.bottom;
     return r;
   }
   [Fixed Code]
   [Function removed]

Note: While these changes appear to be security-related improvements (removing potentially unsafe calculations and using safer alternatives), I can't be certain they were specifically addressing known vulnerabilities. The changes generally follow security best practices by:
1. Using safer built-in methods instead of manual calculations
2. Removing potentially unsafe custom implementations
3. Simplifying code paths that could have edge cases

The most likely security implications would be preventing:
- Integer overflows in layout calculations
- Memory safety issues from incorrect bounds calculations
- Potential null pointer dereferences from unsafe casts

However, without explicit vulnerability reports or CVE references, I can't confirm these were actual vulnerabilities being fixed.

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/dom/base/nsContentUtils.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/base/nsContentUtils.cpp@@ -81,6 +81,7 @@ #include "mozilla/EventQueue.h" #include "mozilla/EventStateManager.h" #include "mozilla/FlushType.h"+#include "mozilla/FOGIPC.h" #include "mozilla/HTMLEditor.h" #include "mozilla/HangAnnotations.h" #include "mozilla/IMEStateManager.h"@@ -268,7 +269,6 @@ #include "nsIContentSecurityPolicy.h" #include "nsIContentSink.h" #include "nsIContentViewer.h"-#include "nsID.h" #include "nsIDOMWindowUtils.h" #include "nsIDocShell.h" #include "nsIDocShellTreeItem.h"@@ -326,7 +326,6 @@ #if defined(MOZ_THUNDERBIRD) || defined(MOZ_SUITE) #  include "nsIURIWithSpecialOrigin.h" #endif-#include "nsIUUIDGenerator.h" #include "nsIUserIdleService.h" #include "nsIWeakReferenceUtils.h" #include "nsIWebNavigation.h"@@ -415,7 +414,6 @@ nsIPrincipal* nsContentUtils::sSystemPrincipal; nsIPrincipal* nsContentUtils::sNullSubjectPrincipal; nsIIOService* nsContentUtils::sIOService;-nsIUUIDGenerator* nsContentUtils::sUUIDGenerator; nsIConsoleService* nsContentUtils::sConsoleService; nsTHashMap<nsRefPtrHashKey<nsAtom>, EventNameMapping>*     nsContentUtils::sAtomEventTable = nullptr;@@ -794,13 +792,6 @@   Element::InitCCCallbacks();   Unused << nsRFPService::GetOrCreate();--  nsCOMPtr<nsIUUIDGenerator> uuidGenerator =-      do_GetService("@mozilla.org/uuid-generator;1", &rv);-  if (NS_WARN_IF(NS_FAILED(rv))) {-    return rv;-  }-  uuidGenerator.forget(&sUUIDGenerator);   if (XRE_IsParentProcess()) {     AsyncPrecreateStringBundles();@@ -1868,7 +1859,7 @@   NS_IF_RELEASE(sSystemPrincipal);   NS_IF_RELEASE(sNullSubjectPrincipal);   NS_IF_RELEASE(sIOService);-  NS_IF_RELEASE(sUUIDGenerator);+   sBidiKeyboard = nullptr;   delete sAtomEventTable;@@ -7347,27 +7338,6 @@   }   return false;-}--nsresult nsContentUtils::GenerateUUIDInPlace(nsID& aUUID) {-  MOZ_ASSERT(sUUIDGenerator);--  nsresult rv = sUUIDGenerator->GenerateUUIDInPlace(&aUUID);-  if (NS_WARN_IF(NS_FAILED(rv))) {-    return rv;-  }--  return NS_OK;-}--nsID nsContentUtils::GenerateUUID() {-  MOZ_DIAGNOSTIC_ASSERT(sUUIDGenerator);--  nsID uuid;-  nsresult rv = sUUIDGenerator->GenerateUUIDInPlace(&uuid);-  MOZ_RELEASE_ASSERT(NS_SUCCEEDED(rv));--  return uuid; } bool nsContentUtils::PrefetchPreloadEnabled(nsIDocShell* aDocShell) {@@ -10148,8 +10118,14 @@                                                  const char* aTopic,                                                  const char16_t* aData) {   if (!strcmp(aTopic, kUserInteractionInactive)) {+    if (sUserActive && XRE_IsParentProcess()) {+      glean::RecordPowerMetrics();+    }     sUserActive = false;   } else if (!strcmp(aTopic, kUserInteractionActive)) {+    if (!sUserActive && XRE_IsParentProcess()) {+      glean::RecordPowerMetrics();+    }     sUserActive = true;   } else {     NS_WARNING("Unexpected observer notification");@@ -10513,30 +10489,34 @@     return windowSafeAreaInsets;   }-  // Screen's rect of safe area-  LayoutDeviceIntRect safeAreaRect(-      screenLeft + aSafeAreaInsets.left, screenTop + aSafeAreaInsets.top,-      screenWidth - aSafeAreaInsets.right - aSafeAreaInsets.left,-      screenHeight - aSafeAreaInsets.bottom - aSafeAreaInsets.top);+  const ScreenIntRect screenRect(screenLeft, screenTop, screenWidth,+                                 screenHeight);++  ScreenIntRect safeAreaRect = screenRect;+  safeAreaRect.Deflate(aSafeAreaInsets);++  ScreenIntRect windowRect = ViewAs<ScreenPixel>(+      aWindowRect, PixelCastJustification::LayoutDeviceIsScreenForTabDims);++  // FIXME(bug 1754323): This can trigger because the screen rect is not+  // orientation-aware.+  // MOZ_ASSERT(screenRect.Contains(windowRect),+  //            "Screen doesn't contain window rect? Something seems off");+   // window's rect of safe area-  safeAreaRect = safeAreaRect.Intersect(aWindowRect);--  windowSafeAreaInsets.top =-      aSafeAreaInsets.top ? std::max(safeAreaRect.y - aWindowRect.y, 0) : 0;-  windowSafeAreaInsets.left =-      aSafeAreaInsets.left ? std::max(safeAreaRect.x - aWindowRect.x, 0) : 0;+  safeAreaRect = safeAreaRect.Intersect(windowRect);++  windowSafeAreaInsets.top = safeAreaRect.y - aWindowRect.y;+  windowSafeAreaInsets.left = safeAreaRect.x - aWindowRect.x;   windowSafeAreaInsets.right =-      aSafeAreaInsets.right-          ? std::max((aWindowRect.x + aWindowRect.width) --                         (safeAreaRect.x + safeAreaRect.width),-                     0)-          : 0;-  windowSafeAreaInsets.bottom =-      aSafeAreaInsets.bottom-          ? std::max(aWindowRect.y + aWindowRect.height --                         (safeAreaRect.y + safeAreaRect.height),-                     0)-          : 0;+      aWindowRect.x + aWindowRect.width - (safeAreaRect.x + safeAreaRect.width);+  windowSafeAreaInsets.bottom = aWindowRect.y + aWindowRect.height -+                                (safeAreaRect.y + safeAreaRect.height);++  windowSafeAreaInsets.EnsureAtLeast(ScreenIntMargin());+  // This shouldn't be needed, but it wallpapers orientation issues, see bug+  // 1754323.+  windowSafeAreaInsets.EnsureAtMost(aSafeAreaInsets);   return windowSafeAreaInsets; }@@ -10544,8 +10524,7 @@ /* static */ nsContentUtils::SubresourceCacheValidationInfo nsContentUtils::GetSubresourceCacheValidationInfo(nsIRequest* aRequest,-                                                  nsIURI* aURI,-                                                  SubresourceKind aKind) {+                                                  nsIURI* aURI) {   SubresourceCacheValidationInfo info;   if (nsCOMPtr<nsICacheInfoChannel> cache = do_QueryInterface(aRequest)) {     uint32_t value = 0;@@ -10574,13 +10553,9 @@     if (!aURI) {       return false;     }-    if (aURI->SchemeIs("data") || aURI->SchemeIs("moz-page-thumb")) {+    if (aURI->SchemeIs("data") || aURI->SchemeIs("moz-page-thumb") ||+        aURI->SchemeIs("moz-extension")) {       return true;-    }-    if (aURI->SchemeIs("moz-extension")) {-      // TODO(bug 1746841): This should be true always, but we force style to be-      // revalidated until bug 1746841 is fixed.-      return aKind != SubresourceKind::Style;     }     if (dom::IsChromeURI(aURI)) {       return !StaticPrefs::nglayout_debug_disable_xul_cache();

Here's the security analysis of the provided code diff:

1. Vulnerability Existed: not sure
   UUID Generator Removal [dom/base/nsContentUtils.cpp] [Lines: 415, 794-800, 1862, 7347-7362]
   [Old Code]
   nsIUUIDGenerator* nsContentUtils::sUUIDGenerator;
   nsCOMPtr<nsIUUIDGenerator> uuidGenerator =
       do_GetService("@mozilla.org/uuid-generator;1", &rv);
   if (NS_WARN_IF(NS_FAILED(rv))) {
     return rv;
   }
   uuidGenerator.forget(&sUUIDGenerator);
   NS_IF_RELEASE(sUUIDGenerator);
   nsresult nsContentUtils::GenerateUUIDInPlace(nsID& aUUID) {
     MOZ_ASSERT(sUUIDGenerator);
     nsresult rv = sUUIDGenerator->GenerateUUIDInPlace(&aUUID);
     if (NS_WARN_IF(NS_FAILED(rv))) {
       return rv;
     }
     return NS_OK;
   }
   [Fixed Code]
   [Removed all UUID generator related code]

2. Vulnerability Existed: not sure
   Safe Area Calculation Fix [dom/base/nsContentUtils.cpp] [Lines: 10489-10524]
   [Old Code]
   LayoutDeviceIntRect safeAreaRect(
       screenLeft + aSafeAreaInsets.left, screenTop + aSafeAreaInsets.top,
       screenWidth - aSafeAreaInsets.right - aSafeAreaInsets.left,
       screenHeight - aSafeAreaInsets.bottom - aSafeAreaInsets.top);
   safeAreaRect = safeAreaRect.Intersect(aWindowRect);
   windowSafeAreaInsets.top =
       aSafeAreaInsets.top ? std::max(safeAreaRect.y - aWindowRect.y, 0) : 0;
   [Fixed Code]
   ScreenIntRect safeAreaRect = screenRect;
   safeAreaRect.Deflate(aSafeAreaInsets);
   ScreenIntRect windowRect = ViewAs<ScreenPixel>(
       aWindowRect, PixelCastJustification::LayoutDeviceIsScreenForTabDims);
   safeAreaRect = safeAreaRect.Intersect(windowRect);
   windowSafeAreaInsets.top = safeAreaRect.y - aWindowRect.y;
   windowSafeAreaInsets.EnsureAtLeast(ScreenIntMargin());
   windowSafeAreaInsets.EnsureAtMost(aSafeAreaInsets);

3. Vulnerability Existed: not sure
   Subresource Cache Validation Change [dom/base/nsContentUtils.cpp] [Lines: 10524-10553]
   [Old Code]
   nsContentUtils::GetSubresourceCacheValidationInfo(nsIRequest* aRequest,
                                                   nsIURI* aURI,
                                                   SubresourceKind aKind)
   if (aURI->SchemeIs("moz-extension")) {
     return aKind != SubresourceKind::Style;
   }
   [Fixed Code]
   nsContentUtils::GetSubresourceCacheValidationInfo(nsIRequest* aRequest,
                                                   nsIURI* aURI)
   if (aURI->SchemeIs("moz-extension")) {
     return true;
   }

4. Vulnerability Existed: not sure
   Power Metrics Recording [dom/base/nsContentUtils.cpp] [Lines: 10118-10128]
   [Old Code]
   if (!strcmp(aTopic, kUserInteractionInactive)) {
     sUserActive = false;
   } else if (!strcmp(aTopic, kUserInteractionActive)) {
     sUserActive = true;
   [Fixed Code]
   if (!strcmp(aTopic, kUserInteractionInactive)) {
     if (sUserActive && XRE_IsParentProcess()) {
       glean::RecordPowerMetrics();
     }
     sUserActive = false;
   } else if (!strcmp(aTopic, kUserInteractionActive)) {
     if (!sUserActive && XRE_IsParentProcess()) {
       glean::RecordPowerMetrics();
     }
     sUserActive = true;

Note: While these changes appear to be security-related improvements (particularly the UUID generator removal and safe area calculation fixes), I couldn't find specific vulnerability names associated with them. The changes seem to be general security hardening measures rather than fixes for 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/layout/reftests/css-grid/grid-fragmentation-001-ref.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/layout/reftests/css-grid/grid-fragmentation-001-ref.html@@ -21,7 +21,7 @@       -ms-column-fill: auto;   -webkit-column-fill: auto;           column-fill: auto;-  border: 2px dashed;+  border: 2px solid salmon;   margin-bottom: 5px; }

After analyzing the provided code diff, here's the security assessment:

Vulnerability Existed: no
[No security vulnerability found] [layout/reftests/css-grid/grid-fragmentation-001-ref.html] [Lines 21]
[Old Code: border: 2px dashed;]
[Fixed Code: border: 2px solid salmon;]

Explanation:
1. The change is purely cosmetic, modifying the border style from dashed to solid and changing the color to salmon
2. This appears to be a visual test reference update rather than a security fix
3. No security-related patterns (XSS, injection, etc.) are present in either the old or new code
4. The file is a test reference HTML file for CSS grid fragmentation testing

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/marionette/harness/marionette_harness/tests/unit/test_prefs_enforce.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/marionette/harness/marionette_harness/tests/unit/test_prefs_enforce.py@@ -12,34 +12,45 @@ class TestEnforcePreferences(MarionetteTestCase):     def setUp(self):         super(TestEnforcePreferences, self).setUp()--        self.marionette.enforce_gecko_prefs(-            {-                "marionette.test.bool": True,-                "marionette.test.int": 3,-                "marionette.test.string": "testing",-            }-        )         self.marionette.set_context("chrome")     def tearDown(self):-        self.marionette.quit(clean=True)+        self.marionette.restart(clean=True)         super(TestEnforcePreferences, self).tearDown()+    def enforce_prefs(self, prefs=None):+        test_prefs = {+            "marionette.test.bool": True,+            "marionette.test.int": 3,+            "marionette.test.string": "testing",+        }++        self.marionette.enforce_gecko_prefs(prefs or test_prefs)+     def test_preferences_are_set(self):+        self.enforce_prefs()         self.assertTrue(self.marionette.get_pref("marionette.test.bool"))         self.assertEqual(self.marionette.get_pref("marionette.test.string"), "testing")         self.assertEqual(self.marionette.get_pref("marionette.test.int"), 3)-    def test_change_preference(self):+    def test_change_enforced_preference(self):+        self.enforce_prefs()         self.assertTrue(self.marionette.get_pref("marionette.test.bool"))-        self.marionette.enforce_gecko_prefs({"marionette.test.bool": False})-+        self.enforce_prefs({"marionette.test.bool": False})         self.assertFalse(self.marionette.get_pref("marionette.test.bool"))-    def test_restart_with_clean_profile(self):+    def test_restart_with_clean_profile_after_enforce_prefs(self):+        self.enforce_prefs()+        self.assertTrue(self.marionette.get_pref("marionette.test.bool"))+         self.marionette.restart(clean=True)+        self.assertEqual(self.marionette.get_pref("marionette.test.bool"), None)-        self.assertEqual(self.marionette.get_pref("marionette.test.bool"), None)+    def test_restart_preserves_requested_capabilities(self):+        self.marionette.delete_session()+        self.marionette.start_session(capabilities={"moz:fooBar": True})++        self.enforce_prefs()+        self.assertEqual(self.marionette.session.get("moz:fooBar"), True)

Based on the provided code diff, I'll analyze it for potential security vulnerabilities:

1. Vulnerability Existed: no
   No specific vulnerability found [File] testing/marionette/harness/marionette_harness/tests/unit/test_prefs_enforce.py [Lines] Various
   [Old Code] Various test implementations with direct enforce_gecko_prefs calls
   [Fixed Code] Refactored to use enforce_prefs helper method and added new test cases

The changes appear to be primarily about:
1. Refactoring the code to use a helper method (enforce_prefs) for consistency
2. Changing quit() to restart() in tearDown
3. Adding new test cases for behavior verification
4. Improving test isolation and cleanup

There are no obvious security vulnerabilities being fixed here - the changes seem focused on test code quality and additional test coverage rather than security fixes. The modifications deal with preference enforcement testing in Marionette (Firefox's automation driver), but don't reveal any security weaknesses in the original code.

No security-related CVEs or vulnerability patterns (like XSS, injection, etc.) are evident in these changes. The changes appear to be test improvements rather than vulnerability 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/toolkit/components/extensions/parent/ext-alarms.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/toolkit/components/extensions/parent/ext-alarms.js@@ -85,6 +85,29 @@     }   }+  registerOnAlarm(fire) {+    let callback = alarm => {+      fire.sync(alarm.data);+    };++    this.callbacks.add(callback);++    return {+      unregister: () => {+        this.callbacks.delete(callback);+      },+      convert(_fire, context) {+        fire = _fire;+      },+    };+  }++  primeListener(extension, event, fire) {+    if (event == "onAlarm") {+      return this.registerOnAlarm(fire);+    }+  }+   getAPI(context) {     const self = this;@@ -132,16 +155,10 @@         onAlarm: new EventManager({           context,-          name: "alarms.onAlarm",+          module: "alarms",+          event: "onAlarm",           register: fire => {-            let callback = alarm => {-              fire.sync(alarm.data);-            };--            self.callbacks.add(callback);-            return () => {-              self.callbacks.delete(callback);-            };+            return self.registerOnAlarm(fire).unregister;           },         }).api(),       },

Based on the provided code diff, I'll analyze it for security vulnerabilities:

1. Vulnerability Existed: not sure
Potential Information Exposure [File] [Lines 85-155]
[Old Code]
The old implementation had the event registration logic directly in the EventManager, with hardcoded "alarms.onAlarm" name.
[Fixed Code]
The new implementation abstracts the event registration into separate methods (registerOnAlarm and primeListener) and uses more modular event naming ("module: alarms" and "event: onAlarm").

2. Vulnerability Existed: not sure
Potential Callback Management Issue [File] [Lines 85-155]
[Old Code]
The callback management was handled directly in the EventManager register function with no clear separation of concerns.
[Fixed Code]
The new implementation provides better callback management through registerOnAlarm method with explicit unregister functionality.

Note: While these changes appear to improve code organization and potentially security, I can't identify any specific, named vulnerabilities that were fixed. The changes seem more related to code structure and maintainability rather than addressing specific security flaws. The EventManager changes might provide better isolation of event handling, which could have security benefits, but no clear vulnerability is being patched here.

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/fetch/data-urls/resources/data-urls.json+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/fetch/data-urls/resources/data-urls.json@@ -52,6 +52,12 @@   ["data:text/plain;Charset=UTF-8,%C2%B1",    "text/plain;charset=UTF-8",    [194, 177]],+  ["data:text/plain;charset=windows-1252,áñçə💩",+   "text/plain;charset=windows-1252",+   [195, 161, 195, 177, 195, 167, 201, 153, 240, 159, 146, 169]],+  ["data:text/plain;charset=UTF-8,áñçə💩",+   "text/plain;charset=UTF-8",+   [195, 161, 195, 177, 195, 167, 201, 153, 240, 159, 146, 169]],   ["data:image/gif,%C2%B1",    "image/gif",    [194, 177]],

Analyzing the provided code diff for security fixes:

1. Vulnerability Existed: not sure  
   [Character Encoding Handling] [testing/web-platform/tests/fetch/data-urls/resources/data-urls.json] [Lines added]  
   [Old Code] - (No previous test cases for windows-1252 and UTF-8 with these characters)  
   [Fixed Code]  
   ```json
   ["data:text/plain;charset=windows-1252,áñçə💩",
    "text/plain;charset=windows-1252",
    [195, 161, 195, 177, 195, 167, 201, 153, 240, 159, 146, 169]],
   ["data:text/plain;charset=UTF-8,áñçə💩",
    "text/plain;charset=UTF-8",
    [195, 161, 195, 177, 195, 167, 201, 153, 240, 159, 146, 169]],
   ```

Additional Notes:  
- The diff adds test cases for handling different character encodings (windows-1252 and UTF-8) with special characters and emoji  
- While not directly fixing a vulnerability, these tests could help prevent potential encoding-related security issues like:  
  - Character encoding confusion attacks  
  - Improper handling of Unicode characters  
  - Encoding-based XSS vectors  
- The test cases ensure proper handling of non-ASCII characters in data URLs, which could be security-relevant for:  
  - Cross-site scripting (XSS) prevention  
  - Content sniffing protection  
  - MIME type handling correctness  

No clear vulnerability is being fixed, but the changes improve test coverage for security-sensitive character encoding handling.

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/unicode-normalization/src/test.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/unicode-normalization/src/test.rs@@ -97,69 +97,81 @@ #[test] fn test_official() {-    use testdata::TEST_NORM;+    use normalization_tests::NORMALIZATION_TESTS;     macro_rules! normString {         ($method: ident, $input: expr) => { $input.$method().collect::<String>() }     }-    for &(s1, s2, s3, s4, s5) in TEST_NORM {+    for test in NORMALIZATION_TESTS {         // these invariants come from the CONFORMANCE section of         // http://www.unicode.org/Public/UNIDATA/NormalizationTest.txt         {-            let r1 = normString!(nfc, s1);-            let r2 = normString!(nfc, s2);-            let r3 = normString!(nfc, s3);-            let r4 = normString!(nfc, s4);-            let r5 = normString!(nfc, s5);-            assert_eq!(s2, &r1[..]);-            assert_eq!(s2, &r2[..]);-            assert_eq!(s2, &r3[..]);-            assert_eq!(s4, &r4[..]);-            assert_eq!(s4, &r5[..]);+            let r1 = normString!(nfc, test.source);+            let r2 = normString!(nfc, test.nfc);+            let r3 = normString!(nfc, test.nfd);+            let r4 = normString!(nfc, test.nfkc);+            let r5 = normString!(nfc, test.nfkd);+            assert_eq!(test.nfc, &r1[..]);+            assert_eq!(test.nfc, &r2[..]);+            assert_eq!(test.nfc, &r3[..]);+            assert_eq!(test.nfkc, &r4[..]);+            assert_eq!(test.nfkc, &r5[..]);         }         {-            let r1 = normString!(nfd, s1);-            let r2 = normString!(nfd, s2);-            let r3 = normString!(nfd, s3);-            let r4 = normString!(nfd, s4);-            let r5 = normString!(nfd, s5);-            assert_eq!(s3, &r1[..]);-            assert_eq!(s3, &r2[..]);-            assert_eq!(s3, &r3[..]);-            assert_eq!(s5, &r4[..]);-            assert_eq!(s5, &r5[..]);+            let r1 = normString!(nfd, test.source);+            let r2 = normString!(nfd, test.nfc);+            let r3 = normString!(nfd, test.nfd);+            let r4 = normString!(nfd, test.nfkc);+            let r5 = normString!(nfd, test.nfkd);+            assert_eq!(test.nfd, &r1[..]);+            assert_eq!(test.nfd, &r2[..]);+            assert_eq!(test.nfd, &r3[..]);+            assert_eq!(test.nfkd, &r4[..]);+            assert_eq!(test.nfkd, &r5[..]);         }         {-            let r1 = normString!(nfkc, s1);-            let r2 = normString!(nfkc, s2);-            let r3 = normString!(nfkc, s3);-            let r4 = normString!(nfkc, s4);-            let r5 = normString!(nfkc, s5);-            assert_eq!(s4, &r1[..]);-            assert_eq!(s4, &r2[..]);-            assert_eq!(s4, &r3[..]);-            assert_eq!(s4, &r4[..]);-            assert_eq!(s4, &r5[..]);+            let r1 = normString!(nfkc, test.source);+            let r2 = normString!(nfkc, test.nfc);+            let r3 = normString!(nfkc, test.nfd);+            let r4 = normString!(nfkc, test.nfkc);+            let r5 = normString!(nfkc, test.nfkd);+            assert_eq!(test.nfkc, &r1[..]);+            assert_eq!(test.nfkc, &r2[..]);+            assert_eq!(test.nfkc, &r3[..]);+            assert_eq!(test.nfkc, &r4[..]);+            assert_eq!(test.nfkc, &r5[..]);         }         {-            let r1 = normString!(nfkd, s1);-            let r2 = normString!(nfkd, s2);-            let r3 = normString!(nfkd, s3);-            let r4 = normString!(nfkd, s4);-            let r5 = normString!(nfkd, s5);-            assert_eq!(s5, &r1[..]);-            assert_eq!(s5, &r2[..]);-            assert_eq!(s5, &r3[..]);-            assert_eq!(s5, &r4[..]);-            assert_eq!(s5, &r5[..]);+            let r1 = normString!(nfkd, test.source);+            let r2 = normString!(nfkd, test.nfc);+            let r3 = normString!(nfkd, test.nfd);+            let r4 = normString!(nfkd, test.nfkc);+            let r5 = normString!(nfkd, test.nfkd);+            assert_eq!(test.nfkd, &r1[..]);+            assert_eq!(test.nfkd, &r2[..]);+            assert_eq!(test.nfkd, &r3[..]);+            assert_eq!(test.nfkd, &r4[..]);+            assert_eq!(test.nfkd, &r5[..]);         }     } }-+#[test]+fn test_quick_check() {+    use normalization_tests::NORMALIZATION_TESTS;+    use quick_check;+    for test in NORMALIZATION_TESTS {+        assert!(quick_check::is_nfc(test.nfc));+        assert!(quick_check::is_nfd(test.nfd));+        if test.nfc != test.nfd {+            assert!(!quick_check::is_nfc(test.nfd));+            assert!(!quick_check::is_nfd(test.nfc));+        }+    }+} #[test] fn test_is_combining_mark_ascii() {

After analyzing the provided code diff, I don't find any security vulnerabilities. The changes appear to be primarily refactoring of test code and adding a new test function, rather than fixing security issues. Here's my analysis:

1. Vulnerability Existed: no
   Test Code Refactoring [third_party/rust/unicode-normalization/src/test.rs] [Lines 97-161]
   Old Code: Used TEST_NORM and tuple pattern matching
   Fixed Code: Uses NORMALIZATION_TESTS with named fields

2. Vulnerability Existed: no
   New Test Function Added [third_party/rust/unicode-normalization/src/test.rs] [Lines 163-172]
   Old Code: (No equivalent function existed)
   Fixed Code: Added test_quick_check function with new assertions

The changes are focused on:
1. Refactoring the test data structure from tuples to named fields
2. Adding a new test function for quick check functionality
3. No security-related fixes were identified in the diff

These appear to be normal test improvements rather than security fixes. The test assertions are being updated to use the new data structure format, and new test coverage is being added for quick check functionality.

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.object.clamp.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.object.clamp.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'); var imgdata = ctx.getImageData(0, 0, 10, 10); imgdata.data[0] = 100;

Let me analyze the code diff for potential security vulnerabilities:

Vulnerability Existed: no
[Variable Renaming] [testing/web-platform/tests/html/canvas/offscreen/pixel-manipulation/2d.imageData.object.clamp.html] [Lines 17-18]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');

The changes appear to be purely cosmetic, renaming the variable from `offscreenCanvas` to `canvas`. This doesn't represent any security fix but rather a code style/readability improvement. There are no actual security vulnerabilities being addressed in this diff.

If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.

--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/selectors/old-tests/css3-modsel-183.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-183.xml@@ -10,7 +10,6 @@ ]]></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 class="test">This text should be green.</p>

After analyzing the provided code diff, here's the security assessment:

1. Vulnerability Existed: no
   No specific vulnerability found [File] testing/web-platform/tests/css/selectors/old-tests/css3-modsel-183.xml [Lines] 10
   [Old Code] <meta name="flags" content="" />
   [Fixed Code] (removed line)

Additional details:
- The change simply removes an empty meta tag with a "flags" attribute. This doesn't appear to be a security-related fix.
- The modification seems to be a cleanup of unnecessary markup rather than addressing any security vulnerability.
- The "flags" meta tag was empty and not serving any apparent purpose in the test file.
- No known vulnerabilities are associated with this type of 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.