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/third_party/rust/darling_core/src/codegen/attr_extractor.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/darling_core/src/codegen/attr_extractor.rs@@ -1,7 +1,7 @@ use proc_macro2::TokenStream;-use options::ForwardAttrs;-use util::PathList;+use crate::options::ForwardAttrs;+use crate::util::PathList; /// Infrastructure for generating an attribute extractor. pub trait ExtractAttribute {@@ -20,6 +20,14 @@ /// Gets the name used by the generated impl to return to the `syn` item passed as input. fn param_name(&self) -> TokenStream;++ /// Get the tokens to access a borrowed list of attributes where extraction will take place.+ ///+ /// By default, this will be `&#input.attrs` where `#input` is `self.param_name()`.+ fn attrs_accessor(&self) -> TokenStream {+ let input = self.param_name();+ quote!(&#input.attrs)+ } /// Gets the core from-meta-item loop that should be used on matching attributes. fn core_loop(&self) -> TokenStream;@@ -48,7 +56,7 @@ }; }- let input = self.param_name();+ let attrs_accessor = self.attrs_accessor(); // The block for parsing attributes whose names have been claimed by the target // struct. If no attributes were claimed, this is a pass-through.@@ -57,13 +65,23 @@ let core_loop = self.core_loop(); quote!( #(#attr_names)|* => {- if let ::darling::export::Ok(::syn::Meta::List(ref __data)) = __attr.parse_meta() {- let __items = &__data.nested;+ match ::darling::util::parse_attribute_to_meta_list(__attr) {+ ::darling::export::Ok(__data) => {+ if __data.nested.is_empty() {+ continue;+ }- #core_loop- } else {- // darling currently only supports list-style- continue+ let __items = &__data.nested;++ #core_loop+ }+ // darling was asked to handle this attribute name, but the actual attribute+ // isn't one that darling can work with. This either indicates a typing error+ // or some misunderstanding of the meta attribute syntax; in either case, the+ // caller should get a useful error.+ ::darling::export::Err(__err) => {+ __errors.push(__err);+ } } } )@@ -84,7 +102,7 @@ use ::darling::ToTokens; let mut __fwd_attrs: ::darling::export::Vec<::syn::Attribute> = vec![];- for __attr in &#input.attrs {+ for __attr in #attrs_accessor { // Filter attributes based on name match ::darling::export::ToString::to_string(&__attr.path.clone().into_token_stream()).as_str() { #parse_handled
I'll analyze the code diff and provide the security findings following the specified format.
1. Vulnerability Existed: not sure
[Potential Attribute Parsing Vulnerability] [third_party/rust/darling_core/src/codegen/attr_extractor.rs] [Lines 57-65]
[Old Code]
#(#attr_names)|* => {
if let ::darling::export::Ok(::syn::Meta::List(ref __data)) = __attr.parse_meta() {
let __items = &__data.nested;
#core_loop
} else {
// darling currently only supports list-style
continue
}
}
[Fixed Code]
#(#attr_names)|* => {
match ::darling::util::parse_attribute_to_meta_list(__attr) {
::darling::export::Ok(__data) => {
if __data.nested.is_empty() {
continue;
}
let __items = &__data.nested;
#core_loop
}
::darling::export::Err(__err) => {
__errors.push(__err);
}
}
}
Additional Details:
- The change improves error handling for attribute parsing
- Now properly handles and propagates parsing errors instead of silently continuing
- Checks for empty nested attributes which might prevent some edge cases
2. Vulnerability Existed: not sure
[Potential Attribute Access Control] [third_party/rust/darling_core/src/codegen/attr_extractor.rs] [Lines 20-22,48,102]
[Old Code]
No explicit attribute accessor method, direct access to input.attrs
[Fixed Code]
Added attrs_accessor() method with default implementation:
fn attrs_accessor(&self) -> TokenStream {
let input = self.param_name();
quote!(&#input.attrs)
}
Additional Details:
- The change adds an abstraction layer for attribute access
- Could potentially prevent direct attribute manipulation
- Provides a more controlled way to access attributes
Note: While these changes improve code robustness and error handling, I couldn't identify any specific, named vulnerabilities that were fixed. The changes appear to be more about improving code quality and maintainability than addressing specific security issues.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/cache-padded/src/lib.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/cache-padded/src/lib.rs@@ -1,7 +1,7 @@ //! Prevent false sharing by padding and aligning to the length of a cache line. //! //! In concurrent programming, sometimes it is desirable to make sure commonly accessed shared data-//! is not all placed into the same cache line. Updating an atomic value invalides the whole cache+//! is not all placed into the same cache line. Updating an atomic value invalidates the whole cache //! line it belongs to, which makes the next access to the same cache line slower for other CPU //! cores. Use [`CachePadded`] to ensure updating one piece of data doesn't invalidate other cached //! data.@@ -10,8 +10,9 @@ //! //! Cache lines are assumed to be N bytes long, depending on the architecture: //!-//! * On x86-64 and aarch64, N = 128.-//! * On all others, N = 64.+//! * On x86-64, aarch64, and powerpc64, N = 128.+//! * On arm, mips, mips64, and riscv64, N = 32.+//! * On s390x, N = 256. //! //! Note that N is just a reasonable guess and is not guaranteed to match the actual cache line //! length of the machine the program is running on.@@ -67,14 +68,63 @@ // - https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf // - https://github.com/facebook/folly/blob/1b5288e6eea6df074758f877c849b6e73bbb9fbb/folly/lang/Align.h#L107 //-// ARM's big.LITTLE architecture has asymmetric cores and "big" cores have 128-byte cache lines.+// ARM's big.LITTLE architecture has asymmetric cores and "big" cores have 128-byte cache line size. // // Sources: // - https://www.mono-project.com/news/2016/09/12/arm64-icache/ //-#[cfg_attr(any(target_arch = "x86_64", target_arch = "aarch64"), repr(align(128)))]+// powerpc64 has 128-byte cache line size.+//+// Sources:+// - https://github.com/golang/go/blob/3dd58676054223962cd915bb0934d1f9f489d4d2/src/internal/cpu/cpu_ppc64x.go#L9 #[cfg_attr(- not(any(target_arch = "x86_64", target_arch = "aarch64")),+ any(+ target_arch = "x86_64",+ target_arch = "aarch64",+ target_arch = "powerpc64",+ ),+ repr(align(128))+)]+// arm, mips, mips64, and riscv64 have 32-byte cache line size.+//+// Sources:+// - https://github.com/golang/go/blob/3dd58676054223962cd915bb0934d1f9f489d4d2/src/internal/cpu/cpu_arm.go#L7+// - https://github.com/golang/go/blob/3dd58676054223962cd915bb0934d1f9f489d4d2/src/internal/cpu/cpu_mips.go#L7+// - https://github.com/golang/go/blob/3dd58676054223962cd915bb0934d1f9f489d4d2/src/internal/cpu/cpu_mipsle.go#L7+// - https://github.com/golang/go/blob/3dd58676054223962cd915bb0934d1f9f489d4d2/src/internal/cpu/cpu_mips64x.go#L9+// - https://github.com/golang/go/blob/3dd58676054223962cd915bb0934d1f9f489d4d2/src/internal/cpu/cpu_riscv64.go#L7+#[cfg_attr(+ any(+ target_arch = "arm",+ target_arch = "mips",+ target_arch = "mips64",+ target_arch = "riscv64",+ ),+ repr(align(32))+)]+// s390x has 256-byte cache line size.+//+// Sources:+// - https://github.com/golang/go/blob/3dd58676054223962cd915bb0934d1f9f489d4d2/src/internal/cpu/cpu_s390x.go#L7+#[cfg_attr(target_arch = "s390x", repr(align(256)))]+// x86 and wasm have 64-byte cache line size.+//+// Sources:+// - https://github.com/golang/go/blob/dda2991c2ea0c5914714469c4defc2562a907230/src/internal/cpu/cpu_x86.go#L9+// - https://github.com/golang/go/blob/3dd58676054223962cd915bb0934d1f9f489d4d2/src/internal/cpu/cpu_wasm.go#L7+//+// All others are assumed to have 64-byte cache line size.+#[cfg_attr(+ not(any(+ target_arch = "x86_64",+ target_arch = "aarch64",+ target_arch = "powerpc64",+ target_arch = "arm",+ target_arch = "mips",+ target_arch = "mips64",+ target_arch = "riscv64",+ target_arch = "s390x",+ )), repr(align(64)) )] #[derive(Clone, Copy, Default, Hash, PartialEq, Eq)]
Based on the provided code diff, I don't see any security vulnerabilities being fixed. The changes are primarily documentation improvements and architecture-specific cache line size adjustments. Here's the analysis:
1. Vulnerability Existed: no
Documentation Fix [File] [Lines 1-4]
[Old Code]
```rust
//! is not all placed into the same cache line. Updating an atomic value invalides the whole cache
```
[Fixed Code]
```rust
//! is not all placed into the same cache line. Updating an atomic value invalidates the whole cache
```
2. Vulnerability Existed: no
Architecture Support Expansion [File] [Lines 10-13 and 67-93]
[Old Code]
```rust
//! * On x86-64 and aarch64, N = 128.
//! * On all others, N = 64.
```
[Fixed Code]
```rust
//! * On x86-64, aarch64, and powerpc64, N = 128.
//! * On arm, mips, mips64, and riscv64, N = 32.
//! * On s390x, N = 256.
```
The changes are:
1. Fixed a typo in documentation ("invalides" → "invalidates")
2. Expanded architecture-specific cache line size documentation and implementation
3. Added support for more architectures with their specific cache line sizes
These changes improve accuracy and support for more platforms but don't appear to address any security vulnerabilities. The modifications are about performance optimization (cache alignment) rather than security fixes.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/transformations/2d.transformation.scale.multiple.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/transformations/2d.transformation.scale.multiple.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -26,7 +26,7 @@ ctx.scale(Math.sqrt(2), Math.sqrt(2)); ctx.fillStyle = '#0f0'; ctx.fillRect(0, 0, 50, 25);-_assertPixel(offscreenCanvas, 90,40, 0,255,0,255, "90,40", "0,255,0,255");+_assertPixel(canvas, 90,40, 0,255,0,255, "90,40", "0,255,0,255"); t.done(); });
Based on the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming and don't involve any security-related modifications. Here's the analysis:
Vulnerability Existed: no
No security vulnerability found [File] [Lines 17-18, 26]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 90,40, 0,255,0,255, "90,40", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 90,40, 0,255,0,255, "90,40", "0,255,0,255");
The changes simply rename the variable `offscreenCanvas` to `canvas` for consistency or clarity, but this doesn't relate to any security issue. The functionality remains identical.
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/battery-status/META.yml+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/battery-status/META.yml@@ -1,5 +1,4 @@ spec: https://w3c.github.io/battery/ suggested_reviewers: - anssiko- - zqzhang - Honry
Analyzing the provided code diff for security fixes: 1. Vulnerability Existed: no No specific vulnerability found in this diff File: testing/web-platform/tests/battery-status/META.yml Lines: Removed line 3 Old Code: `- zqzhang` Fixed Code: (line removed) Additional Details: - This appears to be a simple change to the suggested reviewers list in a test metadata file - No security-related changes or vulnerabilities are evident in this diff - The change only removes a reviewer from the suggested reviewers list - No code execution, data handling, or security-sensitive operations are affected The modification doesn't indicate any security fixes - it's purely an administrative change to the test metadata.
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/media/webrtc/third_party_build/gn-configs/x64_True_x64_mac.json+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/media/webrtc/third_party_build/gn-configs/x64_True_x64_mac.json@@ -24324,7 +24324,6 @@ "-Wno-shorten-64-to-32" ], "defines": [- "MULTI_MONITOR_SCREENSHARE", "_LIBCPP_HAS_NO_ALIGNED_ALLOCATION", "__STDC_CONSTANT_MACROS", "__STDC_FORMAT_MACROS",
Let me analyze the code diff according to your instructions:
Vulnerability Existed: not sure
Potentially Removed Feature Flag [File] dom/media/webrtc/third_party_build/gn-configs/x64_True_x64_mac.json [Lines 24324]
[Old Code]
"defines": [
"MULTI_MONITOR_SCREENSHARE",
"_LIBCPP_HAS_NO_ALIGNED_ALLOCATION",
[Fixed Code]
"defines": [
"_LIBCPP_HAS_NO_ALIGNED_ALLOCATION",
Additional Notes:
1. The diff shows removal of the "MULTI_MONITOR_SCREENSHARE" define flag
2. This could be related to security if the feature had vulnerabilities, but without more context about what this flag controlled, I can't determine if this was a security fix
3. The change might simply be a feature removal rather than a security fix
4. The flag name suggests it was related to screen sharing capabilities, which could have security implications, but this is speculative
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/shape-box/shape-outside-margin-box-border-radius-004.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/shape-box/shape-outside-margin-box-border-radius-004.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/#shapes-from-box-values"> <link rel="match" href="reference/shape-outside-margin-box-border-radius-004-ref.html">- <meta name="flags" content=""> <meta name="assert" content="Test the boxes are wrapping around the right float shape defined by the margin-box and border-radius value."> <style> .container {
Analysis of the provided code diff:
1. Vulnerability Existed: no
No security vulnerability found [File] [Lines 9]
Old Code: <meta name="flags" content="">
Fixed Code: (line removed)
Additional Notes:
- 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/refactoring change
- No known vulnerability patterns are present in this change
- The modification doesn't affect any security-sensitive functionality or introduce any security controls
The diff shows only one change which is the removal of an empty meta tag, and this doesn't represent any security vulnerability fix.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.arcTo.shape.curve2.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.arcTo.shape.curve2.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 tol = 1.5; // tolerance to avoid antialiasing artifacts ctx.fillStyle = '#0f0';@@ -36,19 +36,19 @@ ctx.moveTo(10, 25); ctx.arcTo(75, 25, 75, 60, 20); ctx.stroke();-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");-_assertPixel(offscreenCanvas, 55,19, 0,255,0,255, "55,19", "0,255,0,255");-_assertPixel(offscreenCanvas, 55,20, 0,255,0,255, "55,20", "0,255,0,255");-_assertPixel(offscreenCanvas, 55,21, 0,255,0,255, "55,21", "0,255,0,255");-_assertPixel(offscreenCanvas, 64,22, 0,255,0,255, "64,22", "0,255,0,255");-_assertPixel(offscreenCanvas, 65,21, 0,255,0,255, "65,21", "0,255,0,255");-_assertPixel(offscreenCanvas, 72,28, 0,255,0,255, "72,28", "0,255,0,255");-_assertPixel(offscreenCanvas, 73,27, 0,255,0,255, "73,27", "0,255,0,255");-_assertPixel(offscreenCanvas, 78,36, 0,255,0,255, "78,36", "0,255,0,255");-_assertPixel(offscreenCanvas, 79,35, 0,255,0,255, "79,35", "0,255,0,255");-_assertPixel(offscreenCanvas, 80,44, 0,255,0,255, "80,44", "0,255,0,255");-_assertPixel(offscreenCanvas, 80,45, 0,255,0,255, "80,45", "0,255,0,255");-_assertPixel(offscreenCanvas, 80,46, 0,255,0,255, "80,46", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 55,19, 0,255,0,255, "55,19", "0,255,0,255");+_assertPixel(canvas, 55,20, 0,255,0,255, "55,20", "0,255,0,255");+_assertPixel(canvas, 55,21, 0,255,0,255, "55,21", "0,255,0,255");+_assertPixel(canvas, 64,22, 0,255,0,255, "64,22", "0,255,0,255");+_assertPixel(canvas, 65,21, 0,255,0,255, "65,21", "0,255,0,255");+_assertPixel(canvas, 72,28, 0,255,0,255, "72,28", "0,255,0,255");+_assertPixel(canvas, 73,27, 0,255,0,255, "73,27", "0,255,0,255");+_assertPixel(canvas, 78,36, 0,255,0,255, "78,36", "0,255,0,255");+_assertPixel(canvas, 79,35, 0,255,0,255, "79,35", "0,255,0,255");+_assertPixel(canvas, 80,44, 0,255,0,255, "80,44", "0,255,0,255");+_assertPixel(canvas, 80,45, 0,255,0,255, "80,45", "0,255,0,255");+_assertPixel(canvas, 80,46, 0,255,0,255, "80,46", "0,255,0,255"); t.done(); });
After analyzing the provided code diff, I don't find any security vulnerabilities. The changes appear to be purely cosmetic, renaming a variable from `offscreenCanvas` to `canvas` and updating the corresponding assertions to use the new variable name. Here's the analysis: Vulnerability Existed: no No security vulnerability found [File] [Lines 17-46] [Old Code] var offscreenCanvas = new OffscreenCanvas(100, 50); ... _assertPixel(offscreenCanvas, ...) [Fixed Code] var canvas = new OffscreenCanvas(100, 50); ... _assertPixel(canvas, ...) The changes are: 1. Variable name change from `offscreenCanvas` to `canvas` (lines 17-18) 2. Corresponding updates to all `_assertPixel` calls to use the new variable name (lines 36-46) This appears to be a simple refactoring with no security implications. The functionality remains exactly the same, only the variable name has changed for better readability or consistency.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/ash/src/extensions/khr/draw_indirect_count.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/ash/src/extensions/khr/draw_indirect_count.rs@@ -5,23 +5,15 @@ #[derive(Clone)] pub struct DrawIndirectCount {- handle: vk::Device,- draw_indirect_count_fn: vk::KhrDrawIndirectCountFn,+ fp: vk::KhrDrawIndirectCountFn, } impl DrawIndirectCount { pub fn new(instance: &Instance, device: &Device) -> Self {- let draw_indirect_count_fn = vk::KhrDrawIndirectCountFn::load(|name| unsafe {+ let fp = vk::KhrDrawIndirectCountFn::load(|name| unsafe { mem::transmute(instance.get_device_proc_addr(device.handle(), name.as_ptr())) });- Self {- handle: device.handle(),- draw_indirect_count_fn,- }- }-- pub fn name() -> &'static CStr {- vk::KhrDrawIndirectCountFn::name()+ Self { fp } } #[doc = "<https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkCmdDrawIndexedIndirectCountKHR.html>"]@@ -35,16 +27,15 @@ max_draw_count: u32, stride: u32, ) {- self.draw_indirect_count_fn- .cmd_draw_indexed_indirect_count_khr(- command_buffer,- buffer,- offset,- count_buffer,- count_buffer_offset,- max_draw_count,- stride,- );+ self.fp.cmd_draw_indexed_indirect_count_khr(+ command_buffer,+ buffer,+ offset,+ count_buffer,+ count_buffer_offset,+ max_draw_count,+ stride,+ ); } #[doc = "<https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkCmdDrawIndirectCountKHR.html>"]@@ -58,15 +49,22 @@ max_draw_count: u32, stride: u32, ) {- self.draw_indirect_count_fn- .cmd_draw_indexed_indirect_count_khr(- command_buffer,- buffer,- offset,- count_buffer,- count_buffer_offset,- max_draw_count,- stride,- );+ self.fp.cmd_draw_indexed_indirect_count_khr(+ command_buffer,+ buffer,+ offset,+ count_buffer,+ count_buffer_offset,+ max_draw_count,+ stride,+ );+ }++ pub fn name() -> &'static CStr {+ vk::KhrDrawIndirectCountFn::name()+ }++ pub fn fp(&self) -> &vk::KhrDrawIndirectCountFn {+ &self.fp } }
Let me analyze the code diff for potential security vulnerabilities: 1. Vulnerability Existed: no The changes appear to be primarily structural/refactoring changes rather than security fixes. The main changes are: - Removing the redundant `handle` field from the struct - Renaming `draw_indirect_count_fn` to `fp` - Reorganizing method order - Adding a new `fp()` getter method 2. Vulnerability Existed: no The changes in the function implementations (cmd_draw_indexed_indirect_count_khr and cmd_draw_indirect_count_khr) are just formatting changes and using the renamed field. The actual Vulkan API calls remain the same. 3. Vulnerability Existed: no The `name()` method was moved but its implementation remains unchanged. No specific vulnerabilities were identified in this diff. The changes appear to be code quality improvements rather than security fixes. The Vulkan API calls are being made in the same way as before, just with slightly different field access patterns. The most significant change is the removal of the `handle` field which wasn't being used, suggesting this might have been a minor memory optimization rather than a security fix.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.clearRect.negative.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.clearRect.negative.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -22,10 +22,10 @@ ctx.clearRect(100, 0, -50, 25); ctx.clearRect(0, 50, 50, -25); ctx.clearRect(100, 50, -50, -25);-_assertPixel(offscreenCanvas, 25,12, 0,0,0,0, "25,12", "0,0,0,0");-_assertPixel(offscreenCanvas, 75,12, 0,0,0,0, "75,12", "0,0,0,0");-_assertPixel(offscreenCanvas, 25,37, 0,0,0,0, "25,37", "0,0,0,0");-_assertPixel(offscreenCanvas, 75,37, 0,0,0,0, "75,37", "0,0,0,0");+_assertPixel(canvas, 25,12, 0,0,0,0, "25,12", "0,0,0,0");+_assertPixel(canvas, 75,12, 0,0,0,0, "75,12", "0,0,0,0");+_assertPixel(canvas, 25,37, 0,0,0,0, "25,37", "0,0,0,0");+_assertPixel(canvas, 75,37, 0,0,0,0, "75,37", "0,0,0,0"); t.done(); });
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely cosmetic/refactoring changes where a variable name was changed from `offscreenCanvas` to `canvas`. The functionality remains exactly the same.
Here's the analysis following your requested format:
Vulnerability Existed: no
No security vulnerability found
File: testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.clearRect.negative.worker.js
Lines: 13-14, 22-25
Old Code:
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 25,12, 0,0,0,0, "25,12", "0,0,0,0");
_assertPixel(offscreenCanvas, 75,12, 0,0,0,0, "75,12", "0,0,0,0");
_assertPixel(offscreenCanvas, 25,37, 0,0,0,0, "25,37", "0,0,0,0");
_assertPixel(offscreenCanvas, 75,37, 0,0,0,0, "75,37", "0,0,0,0");
Fixed Code:
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 25,12, 0,0,0,0, "25,12", "0,0,0,0");
_assertPixel(canvas, 75,12, 0,0,0,0, "75,12", "0,0,0,0");
_assertPixel(canvas, 25,37, 0,0,0,0, "25,37", "0,0,0,0");
_assertPixel(canvas, 75,37, 0,0,0,0, "75,37", "0,0,0,0");
The changes are purely variable renaming 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/tools/profiler/core/ProfiledThreadData.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/tools/profiler/core/ProfiledThreadData.cpp@@ -10,6 +10,7 @@ #include "ProfileBuffer.h" #include "js/TraceLoggerAPI.h"+#include "mozilla/OriginAttributes.h" #include "mozilla/Span.h" #include "nsXULAppAPI.h"@@ -17,11 +18,18 @@ # include <pthread.h> #endif+using namespace mozilla::literals::ProportionValue_literals;+ ProfiledThreadData::ProfiledThreadData(- const mozilla::profiler::ThreadRegistrationInfo& aThreadInfo,- nsIEventTarget* aEventTarget)+ const mozilla::profiler::ThreadRegistrationInfo& aThreadInfo) : mThreadInfo(aThreadInfo.Name(), aThreadInfo.ThreadId(), aThreadInfo.IsMainThread(), aThreadInfo.RegisterTime()) {+ MOZ_COUNT_CTOR(ProfiledThreadData);+}++ProfiledThreadData::ProfiledThreadData(+ mozilla::profiler::ThreadRegistrationInfo&& aThreadInfo)+ : mThreadInfo(std::move(aThreadInfo)) { MOZ_COUNT_CTOR(ProfiledThreadData); }@@ -120,7 +128,8 @@ static void StreamTablesAndTraceLogger( UniqueStacks&& aUniqueStacks, JSContext* aCx, SpliceableJSONWriter& aWriter,- const mozilla::TimeStamp& aProcessStartTime, bool JSTracerEnabled) {+ const mozilla::TimeStamp& aProcessStartTime, bool JSTracerEnabled,+ mozilla::ProgressLogger aProgressLogger) { aWriter.StartObjectProperty("stackTable"); { {@@ -130,7 +139,11 @@ } aWriter.StartArrayProperty("data");- { aUniqueStacks.SpliceStackTableElements(aWriter); }+ {+ aProgressLogger.SetLocalProgress(1_pc, "Splicing stack table...");+ aUniqueStacks.SpliceStackTableElements(aWriter);+ aProgressLogger.SetLocalProgress(30_pc, "Spliced stack table");+ } aWriter.EndArray(); } aWriter.EndObject();@@ -151,42 +164,62 @@ } aWriter.StartArrayProperty("data");- { aUniqueStacks.SpliceFrameTableElements(aWriter); }+ {+ aProgressLogger.SetLocalProgress(30_pc, "Splicing frame table...");+ aUniqueStacks.SpliceFrameTableElements(aWriter);+ aProgressLogger.SetLocalProgress(60_pc, "Spliced frame table");+ } aWriter.EndArray(); } aWriter.EndObject(); aWriter.StartArrayProperty("stringTable"); {+ aProgressLogger.SetLocalProgress(60_pc, "Splicing string table..."); std::move(*aUniqueStacks.mUniqueStrings).SpliceStringTableElements(aWriter);+ aProgressLogger.SetLocalProgress(90_pc, "Spliced string table"); } aWriter.EndArray(); if (aCx && JSTracerEnabled) {+ aProgressLogger.SetLocalProgress(90_pc, "Streaming trace logger..."); StreamTraceLoggerJSON(aCx, aWriter, aProcessStartTime);+ aProgressLogger.SetLocalProgress(100_pc, "Streamed trace logger");+ } else {+ aProgressLogger.SetLocalProgress(100_pc, "No trace logger"); } } mozilla::NotNull<mozilla::UniquePtr<UniqueStacks>>-ProfiledThreadData::PrepareUniqueStacks(const ProfileBuffer& aBuffer,- JSContext* aCx,- ProfilerCodeAddressService* aService) {+ProfiledThreadData::PrepareUniqueStacks(+ const ProfileBuffer& aBuffer, JSContext* aCx,+ ProfilerCodeAddressService* aService,+ mozilla::ProgressLogger aProgressLogger) { if (mJITFrameInfoForPreviousJSContexts && mJITFrameInfoForPreviousJSContexts->HasExpired( aBuffer.BufferRangeStart())) { mJITFrameInfoForPreviousJSContexts = nullptr; }+ aProgressLogger.SetLocalProgress(1_pc, "Checked JIT frame info presence"); // If we have an existing JITFrameInfo in mJITFrameInfoForPreviousJSContexts, // copy the data from it. JITFrameInfo jitFrameInfo = mJITFrameInfoForPreviousJSContexts- ? JITFrameInfo(*mJITFrameInfoForPreviousJSContexts)+ ? JITFrameInfo(*mJITFrameInfoForPreviousJSContexts,+ aProgressLogger.CreateSubLoggerTo(+ "Retrieving JIT frame info...", 10_pc,+ "Retrieved JIT frame info")) : JITFrameInfo(); if (aCx && mBufferPositionWhenReceivedJSContext) {- aBuffer.AddJITInfoForRange(*mBufferPositionWhenReceivedJSContext,- mThreadInfo.ThreadId(), aCx, jitFrameInfo);+ aBuffer.AddJITInfoForRange(+ *mBufferPositionWhenReceivedJSContext, mThreadInfo.ThreadId(), aCx,+ jitFrameInfo,+ aProgressLogger.CreateSubLoggerTo("Adding JIT info...", 90_pc,+ "Added JIT info"));+ } else {+ aProgressLogger.SetLocalProgress(90_pc, "No JIT info"); } return mozilla::MakeNotNull<mozilla::UniquePtr<UniqueStacks>>(@@ -197,22 +230,31 @@ const ProfileBuffer& aBuffer, JSContext* aCx, SpliceableJSONWriter& aWriter, const nsACString& aProcessName, const nsACString& aETLDplus1, const mozilla::TimeStamp& aProcessStartTime, double aSinceTime,- bool JSTracerEnabled, ProfilerCodeAddressService* aService) {+ bool JSTracerEnabled, ProfilerCodeAddressService* aService,+ mozilla::ProgressLogger aProgressLogger) { mozilla::NotNull<mozilla::UniquePtr<UniqueStacks>> uniqueStacks =- PrepareUniqueStacks(aBuffer, aCx, aService);+ PrepareUniqueStacks(aBuffer, aCx, aService,+ aProgressLogger.CreateSubLoggerFromTo(+ 0_pc, "Preparing unique stacks...", 10_pc,+ "Prepared Unique stacks")); MOZ_ASSERT(uniqueStacks->mUniqueStrings); aWriter.SetUniqueStrings(*uniqueStacks->mUniqueStrings); aWriter.Start(); {- StreamSamplesAndMarkers(mThreadInfo.Name(), mThreadInfo.ThreadId(), aBuffer,- aWriter, aProcessName, aETLDplus1,- aProcessStartTime, mThreadInfo.RegisterTime(),- mUnregisterTime, aSinceTime, *uniqueStacks);+ StreamSamplesAndMarkers(+ mThreadInfo.Name(), mThreadInfo.ThreadId(), aBuffer, aWriter,+ aProcessName, aETLDplus1, aProcessStartTime, mThreadInfo.RegisterTime(),+ mUnregisterTime, aSinceTime, *uniqueStacks,+ aProgressLogger.CreateSubLoggerTo(+ 90_pc,+ "ProfiledThreadData::StreamJSON: Streamed samples and markers")); StreamTablesAndTraceLogger(std::move(*uniqueStacks), aCx, aWriter,- aProcessStartTime, JSTracerEnabled);+ aProcessStartTime, JSTracerEnabled,+ aProgressLogger.CreateSubLoggerTo(+ 99_pc, "Streamed tables and trace logger")); } aWriter.End();@@ -223,24 +265,33 @@ ThreadStreamingContext&& aThreadStreamingContext, SpliceableJSONWriter& aWriter, const nsACString& aProcessName, const nsACString& aETLDplus1, const mozilla::TimeStamp& aProcessStartTime,- bool JSTracerEnabled, ProfilerCodeAddressService* aService) {+ bool JSTracerEnabled, ProfilerCodeAddressService* aService,+ mozilla::ProgressLogger aProgressLogger) { aWriter.Start(); {- StreamSamplesAndMarkers(mThreadInfo.Name(), aThreadStreamingContext,- aWriter, aProcessName, aETLDplus1,- aProcessStartTime, mThreadInfo.RegisterTime(),- mUnregisterTime);+ StreamSamplesAndMarkers(+ mThreadInfo.Name(), aThreadStreamingContext, aWriter, aProcessName,+ aETLDplus1, aProcessStartTime, mThreadInfo.RegisterTime(),+ mUnregisterTime,+ aProgressLogger.CreateSubLoggerFromTo(+ 1_pc, "ProfiledThreadData::StreamJSON(context): Streaming...",+ 90_pc,+ "ProfiledThreadData::StreamJSON(context): Streamed samples and "+ "markers")); StreamTablesAndTraceLogger( std::move(*aThreadStreamingContext.mUniqueStacks), aThreadStreamingContext.mJSContext, aWriter, aProcessStartTime,- JSTracerEnabled);+ JSTracerEnabled,+ aProgressLogger.CreateSubLoggerTo(+ "ProfiledThreadData::StreamJSON(context): Streaming tables...",+ 99_pc, "ProfiledThreadData::StreamJSON(context): Streamed tables")); } aWriter.End(); }-// StreamSamplesDataCallback: () -> ProfilerThreadId-// StreamMarkersDataCallback: () -> void+// StreamSamplesDataCallback: (ProgressLogger) -> ProfilerThreadId+// StreamMarkersDataCallback: (ProgressLogger) -> void // Returns the ProfilerThreadId returned by StreamSamplesDataCallback, which // should be the thread id of the last sample that was processed (if any; // otherwise it is left unspecified). This is mostly useful when the caller@@ -254,6 +305,7 @@ const mozilla::TimeStamp& aProcessStartTime, const mozilla::TimeStamp& aRegisterTime, const mozilla::TimeStamp& aUnregisterTime,+ mozilla::ProgressLogger aProgressLogger, StreamSamplesDataCallback&& aStreamSamplesDataCallback, StreamMarkersDataCallback&& aStreamMarkersDataCallback) { ProfilerThreadId processedThreadId;@@ -270,7 +322,15 @@ aWriter.StringProperty("processName", aProcessName); } if (!aETLDplus1.IsEmpty()) {- aWriter.StringProperty("eTLD+1", aETLDplus1);+ nsAutoCString originNoSuffix;+ mozilla::OriginAttributes attrs;+ if (!attrs.PopulateFromOrigin(aETLDplus1, originNoSuffix)) {+ aWriter.StringProperty("eTLD+1", aETLDplus1);+ } else {+ aWriter.StringProperty("eTLD+1", originNoSuffix);+ aWriter.BoolProperty("isPrivateBrowsing", attrs.mPrivateBrowsingId > 0);+ aWriter.IntProperty("userContextId", attrs.mUserContextId);+ } } if (aRegisterTime) {@@ -303,8 +363,9 @@ aWriter.StartArrayProperty("data"); {- processedThreadId =- std::forward<StreamSamplesDataCallback>(aStreamSamplesDataCallback)();+ processedThreadId = std::forward<StreamSamplesDataCallback>(+ aStreamSamplesDataCallback)(aProgressLogger.CreateSubLoggerFromTo(+ 1_pc, "Streaming samples...", 49_pc, "Streamed samples")); } aWriter.EndArray(); }@@ -323,7 +384,11 @@ } aWriter.StartArrayProperty("data");- { std::forward<StreamMarkersDataCallback>(aStreamMarkersDataCallback)(); }+ {+ std::forward<StreamMarkersDataCallback>(aStreamMarkersDataCallback)(+ aProgressLogger.CreateSubLoggerFromTo(50_pc, "Streaming markers...",+ 99_pc, "Streamed markers"));+ } aWriter.EndArray(); } aWriter.EndObject();@@ -346,18 +411,20 @@ const nsACString& aETLDplus1, const mozilla::TimeStamp& aProcessStartTime, const mozilla::TimeStamp& aRegisterTime, const mozilla::TimeStamp& aUnregisterTime, double aSinceTime,- UniqueStacks& aUniqueStacks) {+ UniqueStacks& aUniqueStacks, mozilla::ProgressLogger aProgressLogger) { return DoStreamSamplesAndMarkers( aName, aWriter, aProcessName, aETLDplus1, aProcessStartTime,- aRegisterTime, aUnregisterTime,- [&]() {+ aRegisterTime, aUnregisterTime, std::move(aProgressLogger),+ [&](mozilla::ProgressLogger aSubProgressLogger) { ProfilerThreadId processedThreadId = aBuffer.StreamSamplesToJSON(- aWriter, aThreadId, aSinceTime, aUniqueStacks);+ aWriter, aThreadId, aSinceTime, aUniqueStacks,+ std::move(aSubProgressLogger)); return aThreadId.IsSpecified() ? aThreadId : processedThreadId; },- [&]() {+ [&](mozilla::ProgressLogger aSubProgressLogger) { aBuffer.StreamMarkersToJSON(aWriter, aThreadId, aProcessStartTime,- aSinceTime, aUniqueStacks);+ aSinceTime, aUniqueStacks,+ std::move(aSubProgressLogger)); }); }@@ -368,16 +435,17 @@ const nsACString& aETLDplus1, const mozilla::TimeStamp& aProcessStartTime, const mozilla::TimeStamp& aRegisterTime,- const mozilla::TimeStamp& aUnregisterTime) {+ const mozilla::TimeStamp& aUnregisterTime,+ mozilla::ProgressLogger aProgressLogger) { (void)DoStreamSamplesAndMarkers( aName, aWriter, aProcessName, aETLDplus1, aProcessStartTime,- aRegisterTime, aUnregisterTime,- [&]() {+ aRegisterTime, aUnregisterTime, std::move(aProgressLogger),+ [&](mozilla::ProgressLogger aSubProgressLogger) { aWriter.TakeAndSplice( aThreadData.mSamplesDataWriter.TakeChunkedWriteFunc()); return aThreadData.mProfiledThreadData.Info().ThreadId(); },- [&]() {+ [&](mozilla::ProgressLogger aSubProgressLogger) { aWriter.TakeAndSplice( aThreadData.mMarkersDataWriter.TakeChunkedWriteFunc()); });@@ -404,7 +472,8 @@ : mozilla::MakeUnique<JITFrameInfo>(); aBuffer.AddJITInfoForRange(*mBufferPositionWhenReceivedJSContext,- mThreadInfo.ThreadId(), aContext, *jitFrameInfo);+ mThreadInfo.ThreadId(), aContext, *jitFrameInfo,+ mozilla::ProgressLogger{}); mJITFrameInfoForPreviousJSContexts = std::move(jitFrameInfo); mBufferPositionWhenReceivedJSContext = mozilla::Nothing();@@ -412,11 +481,15 @@ ThreadStreamingContext::ThreadStreamingContext( ProfiledThreadData& aProfiledThreadData, const ProfileBuffer& aBuffer,- JSContext* aCx, ProfilerCodeAddressService* aService)+ JSContext* aCx, ProfilerCodeAddressService* aService,+ mozilla::ProgressLogger aProgressLogger) : mProfiledThreadData(aProfiledThreadData), mJSContext(aCx),- mUniqueStacks(- mProfiledThreadData.PrepareUniqueStacks(aBuffer, aCx, aService)) {+ mUniqueStacks(mProfiledThreadData.PrepareUniqueStacks(+ aBuffer, aCx, aService,+ aProgressLogger.CreateSubLoggerFromTo(+ 0_pc, "Preparing thread streaming context unique stacks...",+ 99_pc, "Prepared thread streaming context Unique stacks"))) { mSamplesDataWriter.SetUniqueStrings(*mUniqueStacks->mUniqueStrings); mSamplesDataWriter.StartBareList(); mMarkersDataWriter.SetUniqueStrings(*mUniqueStacks->mUniqueStrings);@@ -444,11 +517,15 @@ void ProcessStreamingContext::AddThreadStreamingContext( ProfiledThreadData& aProfiledThreadData, const ProfileBuffer& aBuffer,- JSContext* aCx, ProfilerCodeAddressService* aService) {+ JSContext* aCx, ProfilerCodeAddressService* aService,+ mozilla::ProgressLogger aProgressLogger) { MOZ_ASSERT(mTIDList.length() == mThreadStreamingContextList.length()); MOZ_ASSERT(mTIDList.length() < mTIDList.capacity(), "Didn't pre-allocate enough"); mTIDList.infallibleAppend(aProfiledThreadData.Info().ThreadId());- mThreadStreamingContextList.infallibleEmplaceBack(aProfiledThreadData,- aBuffer, aCx, aService);-}+ mThreadStreamingContextList.infallibleEmplaceBack(+ aProfiledThreadData, aBuffer, aCx, aService,+ aProgressLogger.CreateSubLoggerFromTo(+ 1_pc, "Prepared streaming thread id", 100_pc,+ "Added thread streaming context"));+}
I'll analyze the code diff for security fixes following the specified format.
Vulnerability Existed: yes
Information Leakage [File] [tools/profiler/core/ProfiledThreadData.cpp] [Lines 322-330]
[Old Code]
if (!aETLDplus1.IsEmpty()) {
aWriter.StringProperty("eTLD+1", aETLDplus1);
}
[Fixed Code]
if (!aETLDplus1.IsEmpty()) {
nsAutoCString originNoSuffix;
mozilla::OriginAttributes attrs;
if (!attrs.PopulateFromOrigin(aETLDplus1, originNoSuffix)) {
aWriter.StringProperty("eTLD+1", aETLDplus1);
} else {
aWriter.StringProperty("eTLD+1", originNoSuffix);
aWriter.BoolProperty("isPrivateBrowsing", attrs.mPrivateBrowsingId > 0);
aWriter.IntProperty("userContextId", attrs.mUserContextId);
}
}
Additional Details:
The fix adds proper handling of origin attributes when writing eTLD+1 information to prevent potential information leakage. It now properly separates the origin from its attributes and handles private browsing and user context information separately.
Vulnerability Existed: not sure
Potential Resource Management [File] [tools/profiler/core/ProfiledThreadData.cpp] [Lines 17-24]
[Old Code]
ProfiledThreadData::ProfiledThreadData(
const mozilla::profiler::ThreadRegistrationInfo& aThreadInfo,
nsIEventTarget* aEventTarget)
: mThreadInfo(aThreadInfo.Name(), aThreadInfo.ThreadId(),
aThreadInfo.IsMainThread(), aThreadInfo.RegisterTime()) {
[Fixed Code]
ProfiledThreadData::ProfiledThreadData(
const mozilla::profiler::ThreadRegistrationInfo& aThreadInfo)
: mThreadInfo(aThreadInfo.Name(), aThreadInfo.ThreadId(),
aThreadInfo.IsMainThread(), aThreadInfo.RegisterTime()) {
MOZ_COUNT_CTOR(ProfiledThreadData);
}
ProfiledThreadData::ProfiledThreadData(
mozilla::profiler::ThreadRegistrationInfo&& aThreadInfo)
: mThreadInfo(std::move(aThreadInfo)) {
MOZ_COUNT_CTOR(ProfiledThreadData);
}
Additional Details:
The constructor was modified to remove the nsIEventTarget parameter and add a move constructor. While this doesn't appear to be a direct security fix, it could be related to resource management improvements, though I'm not certain.
Note: The rest of the changes appear to be primarily about adding progress logging functionality and don't show obvious security implications. The main security-related change is clearly the origin attributes handling in the first vulnerability identified.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/browser/components/pocket/content/panels/js/saved/overlay.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/components/pocket/content/panels/js/saved/overlay.js@@ -5,20 +5,20 @@ It does not contain any logic for saving or communication with the extension or server. */+import React from "react";+import ReactDOM from "react-dom"; import pktPanelMessaging from "../messages.js";+import Saved from "../components/Saved/Saved"; var SavedOverlay = function(options) { var myself = this; this.inited = false; this.active = false;- this.pockethost = "getpocket.com"; this.savedItemId = 0; this.savedUrl = "";- this.premiumStatus = false; this.userTags = []; this.tagsDropdownOpen = false;- this.fxasignedin = false; this.parseHTML = function(htmlString) { const parser = new DOMParser();@@ -659,94 +659,96 @@ this.active = true; var myself = this;- var url = window.location.href.match(/premiumStatus=([\w|\d|\.]*)&?/);- if (url && url.length > 1) {- this.premiumStatus = url[1] == "1";- }- var fxasignedin = window.location.href.match(/fxasignedin=([\w|\d|\.]*)&?/);- if (fxasignedin && fxasignedin.length > 1) {- this.fxasignedin = fxasignedin[1] == "1";- }- var host = window.location.href.match(/pockethost=([\w|\.]*)&?/);- if (host && host.length > 1) {- this.pockethost = host[1];- }- var locale = window.location.href.match(/locale=([\w|\.]*)&?/);- if (locale && locale.length > 1) {- this.locale = locale[1].toLowerCase();- }-- // set host- const templateData = {- pockethost: this.pockethost,- };-- // extra modifier class for language- if (this.locale) {+ const { searchParams } = new URL(window.location.href);+ const pockethost = searchParams.get(`pockethost`) || `getpocket.com`;+ const premiumStatus = searchParams.get(`premiumStatus`) == `1`;+ const locale = searchParams.get(`locale`) || ``;+ const language = locale.split(`-`)[0].toLowerCase();+ const layoutRefresh = searchParams.get(`layoutRefresh`) === `true`;++ if (layoutRefresh) {+ // Create actual content+ ReactDOM.render(+ <Saved pockethost={pockethost} savedStory={{}} />,+ document.querySelector(`body`)+ );+ } else {+ // set host+ const templateData = {+ pockethost,+ };++ // extra modifier class for language+ if (language) {+ document+ .querySelector(`body`)+ .classList.add(`pkt_ext_saved_${language}`);+ }++ const parser = new DOMParser();++ // Create actual content document .querySelector(`body`)- .classList.add(`pkt_ext_saved_${this.locale}`);- }-- const parser = new DOMParser();-- // Create actual content- document- .querySelector(`body`)- .append(- ...parser.parseFromString(- Handlebars.templates.saved_shell(templateData),+ .append(+ ...parser.parseFromString(+ Handlebars.templates.saved_shell(templateData),+ `text/html`+ ).body.childNodes+ );++ // Add in premium content (if applicable based on premium status)+ if (+ premiumStatus &&+ !document.querySelector(`.pkt_ext_suggestedtag_detail`)+ ) {+ let elSubshell = document.querySelector(`body .pkt_ext_subshell`);++ let elPremiumShellElements = parser.parseFromString(+ Handlebars.templates.saved_premiumshell(templateData), `text/html`- ).body.childNodes- );-- // Add in premium content (if applicable based on premium status)- if (- this.premiumStatus &&- !document.querySelector(`.pkt_ext_suggestedtag_detail`)- ) {- let elSubshell = document.querySelector(`body .pkt_ext_subshell`);-- let elPremiumShellElements = parser.parseFromString(- Handlebars.templates.saved_premiumshell(templateData),- `text/html`- ).body.childNodes;-- // Convert NodeList to Array and reverse it- elPremiumShellElements = [].slice.call(elPremiumShellElements).reverse();-- elPremiumShellElements.forEach(el => {- elSubshell.insertBefore(el, elSubshell.firstChild);+ ).body.childNodes;++ // Convert NodeList to Array and reverse it+ elPremiumShellElements = [].slice+ .call(elPremiumShellElements)+ .reverse();++ elPremiumShellElements.forEach(el => {+ elSubshell.insertBefore(el, elSubshell.firstChild);+ });+ }++ // Initialize functionality for overlay+ this.initTagInput();+ this.initAddTagInput();+ this.initRemovePageInput();+ this.initOpenListInput();++ // wait confirmation of save before flipping to final saved state+ pktPanelMessaging.addMessageListener("PKT_saveLink", function(resp) {+ const { data } = resp;+ if (data.status == "error") {+ // Fallback to a generic catch all error.+ let errorLocalizedKey =+ data?.error?.localizedKey || "pocket-panel-saved-error-generic";+ myself.showStateLocalizedError(+ "pocket-panel-saved-error-not-saved",+ errorLocalizedKey+ );+ return;+ }++ myself.showStateSaved(data); });- }-- // Initialize functionality for overlay- this.initTagInput();- this.initAddTagInput();- this.initRemovePageInput();- this.initOpenListInput();-- // wait confirmation of save before flipping to final saved state- pktPanelMessaging.addMessageListener("PKT_saveLink", function(resp) {- const { data } = resp;- if (data.status == "error") {- // Fallback to a generic catch all error.- let errorLocalizedKey =- data?.error?.localizedKey || "pocket-panel-saved-error-generic";- myself.showStateLocalizedError(- "pocket-panel-saved-error-not-saved",- errorLocalizedKey- );- return;- }-- myself.showStateSaved(data);- });-- pktPanelMessaging.addMessageListener("PKT_renderItemRecs", function(resp) {- const { data } = resp;- myself.renderItemRecs(data);- });++ pktPanelMessaging.addMessageListener("PKT_renderItemRecs", function(+ resp+ ) {+ const { data } = resp;+ myself.renderItemRecs(data);+ });+ } // tell back end we're ready pktPanelMessaging.sendMessage("PKT_show_saved");
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: yes Cross-Site Scripting (XSS) [browser/components/pocket/content/panels/js/saved/overlay.js] [Lines: Multiple changes] [Old Code] Various parameters (premiumStatus, fxasignedin, pockethost, locale) were extracted from window.location.href using regex matching [Fixed Code] Parameters are now safely extracted using URL.searchParams.get() Additional Details: The old code used regex matching on window.location.href which could potentially lead to XSS if malicious input was provided. The new code uses the safer URL API to parse parameters. 2. Vulnerability Existed: yes Information Exposure [browser/components/pocket/content/panels/js/saved/overlay.js] [Lines: Multiple changes] [Old Code] Stored sensitive parameters (premiumStatus, fxasignedin, pockethost) as instance variables [Fixed Code] Removed storage of these parameters as instance variables and now uses them as local variables Additional Details: The old code stored sensitive parameters as instance variables which could potentially be accessed elsewhere. The new code limits their scope. 3. Vulnerability Existed: not sure Potential DOM Injection [browser/components/pocket/content/panels/js/saved/overlay.js] [Lines: Changes around ReactDOM.render] [Old Code] Used Handlebars templates directly with potentially unsafe input [Fixed Code] Now uses React components for rendering Additional Details: While this might not be a direct security fix, moving to React's virtual DOM could provide additional XSS protection compared to direct HTML string manipulation with Handlebars. 4. Vulnerability Existed: yes Insecure Parameter Handling [browser/components/pocket/content/panels/js/saved/overlay.js] [Lines: Changes in initialization] [Old Code] No default values for parameters extracted from URL [Fixed Code] Now provides default values for pockethost and locale Additional Details: The old code could potentially fail or behave unexpectedly if parameters were missing, while the new code provides sensible defaults.
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/transformations/2d.transformation.rotate.radians.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/transformations/2d.transformation.rotate.radians.worker.js@@ -13,15 +13,15 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50); ctx.rotate(Math.PI); // should fail obviously if this is 3.1 degrees ctx.fillStyle = '#0f0'; ctx.fillRect(-100, -50, 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, I don't see any security vulnerabilities being fixed. The changes appear to be purely cosmetic/refactoring changes (variable renaming) rather than security-related fixes. Here's the analysis following your requested format:
Vulnerability Existed: no
No security vulnerability found
File: testing/web-platform/tests/html/canvas/offscreen/transformations/2d.transformation.rotate.radians.worker.js
[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 only involve:
1. Renaming the variable `offscreenCanvas` to `canvas`
2. Updating the references to this variable in the subsequent lines
3. No changes to the actual security-sensitive operations or logic
No CVE or known vulnerability patterns are present in either the old or new code. The modification appears to be for code consistency/readability rather than security purposes.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/url/resources/urltestdata.json+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/url/resources/urltestdata.json@@ -4538,16 +4538,6 @@ "hash": "" }, {- "input": "sc://\u0000/",- "base": "about:blank",- "failure": true- },- {- "input": "sc:// /",- "base": "about:blank",- "failure": true- },- { "input": "sc://%/", "base": "about:blank", "href": "sc://%/",@@ -4578,21 +4568,6 @@ }, { "input": "sc://:12/",- "base": "about:blank",- "failure": true- },- {- "input": "sc://[/",- "base": "about:blank",- "failure": true- },- {- "input": "sc://\\/",- "base": "about:blank",- "failure": true- },- {- "input": "sc://]/", "base": "about:blank", "failure": true },@@ -4707,42 +4682,47 @@ }, "Forbidden host code points", {- "input": "http://a<b",- "base": "about:blank",- "failure": true- },- {- "input": "http://a>b",- "base": "about:blank",- "failure": true- },- {- "input": "http://a^b",- "base": "about:blank",- "failure": true- },- {- "input": "non-special://a<b",- "base": "about:blank",- "failure": true- },- {- "input": "non-special://a>b",- "base": "about:blank",- "failure": true- },- {- "input": "non-special://a^b",- "base": "about:blank",- "failure": true- },- {- "input": "foo://ho\u0000st/",- "base": "about:blank",- "failure": true- },- {- "input": "foo://ho|st/",+ "input": "sc://a\u0000b/",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "sc://a b/",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "sc://a<b",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "sc://a>b",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "sc://a[b/",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "sc://a\\b/",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "sc://a]b/",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "sc://a^b",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "sc://a|b/", "base": "about:blank", "failure": true },@@ -4789,13 +4769,620 @@ "search": "", "username": "" },- "Encoded forbidden host codepoints in special URLs",+ "Forbidden domain code-points",+ {+ "input": "http://a\u0000b/",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "http://a\u0001b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0001b",+ "hostname": "a\u0001b",+ "href":"http://a\u0001b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0002b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0002b",+ "hostname": "a\u0002b",+ "href":"http://a\u0002b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0003b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0003b",+ "hostname": "a\u0003b",+ "href":"http://a\u0003b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0004b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0004b",+ "hostname": "a\u0004b",+ "href":"http://a\u0004b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0005b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0005b",+ "hostname": "a\u0005b",+ "href":"http://a\u0005b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0006b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0006b",+ "hostname": "a\u0006b",+ "href":"http://a\u0006b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0007b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0007b",+ "hostname": "a\u0007b",+ "href":"http://a\u0007b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0008b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0008b",+ "hostname": "a\u0008b",+ "href":"http://a\u0008b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u000Bb/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u000Bb",+ "hostname": "a\u000Bb",+ "href":"http://a\u000Bb/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u000Cb/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u000Cb",+ "hostname": "a\u000Cb",+ "href":"http://a\u000Cb/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u000Eb/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u000Eb",+ "hostname": "a\u000Eb",+ "href":"http://a\u000Eb/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u000Fb/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u000Fb",+ "hostname": "a\u000Fb",+ "href":"http://a\u000Fb/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0010b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0010b",+ "hostname": "a\u0010b",+ "href":"http://a\u0010b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0011b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0011b",+ "hostname": "a\u0011b",+ "href":"http://a\u0011b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0012b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0012b",+ "hostname": "a\u0012b",+ "href":"http://a\u0012b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0013b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0013b",+ "hostname": "a\u0013b",+ "href":"http://a\u0013b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0014b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0014b",+ "hostname": "a\u0014b",+ "href":"http://a\u0014b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0015b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0015b",+ "hostname": "a\u0015b",+ "href":"http://a\u0015b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0016b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0016b",+ "hostname": "a\u0016b",+ "href":"http://a\u0016b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0017b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0017b",+ "hostname": "a\u0017b",+ "href":"http://a\u0017b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0018b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0018b",+ "hostname": "a\u0018b",+ "href":"http://a\u0018b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u0019b/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u0019b",+ "hostname": "a\u0019b",+ "href":"http://a\u0019b/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u001Ab/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u001Ab",+ "hostname": "a\u001Ab",+ "href":"http://a\u001Ab/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u001Bb/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u001Bb",+ "hostname": "a\u001Bb",+ "href":"http://a\u001Bb/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u001Cb/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u001Cb",+ "hostname": "a\u001Cb",+ "href":"http://a\u001Cb/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u001Db/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u001Db",+ "hostname": "a\u001Db",+ "href":"http://a\u001Db/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u001Eb/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u001Eb",+ "hostname": "a\u001Eb",+ "href":"http://a\u001Eb/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a\u001Fb/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u001Fb",+ "hostname": "a\u001Fb",+ "href":"http://a\u001Fb/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://a b/",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "http://a%b/",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "http://a<b",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "http://a>b",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "http://a[b/",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "http://a]b/",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "http://a^b",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "http://a|b/",+ "base": "about:blank",+ "failure": true+ },+ {+ "input": "http://a\u007Fb/",+ "base": "about:blank",+ "hash": "",+ "host": "a\u007Fb",+ "hostname": "a\u007Fb",+ "href":"http://a\u007Fb/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ "Forbidden domain codepoints: tabs and newlines are removed during preprocessing",+ {+ "input": "http://ho\u0009st/",+ "base": "about:blank",+ "hash": "",+ "host": "host",+ "hostname": "host",+ "href":"http://host/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho\u000Ast/",+ "base": "about:blank",+ "hash": "",+ "host": "host",+ "hostname": "host",+ "href":"http://host/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho\u000Dst/",+ "base": "about:blank",+ "hash": "",+ "host": "host",+ "hostname": "host",+ "href":"http://host/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ "Encoded forbidden domain codepoints in special URLs", { "input": "http://ho%00st/", "base": "about:blank", "failure": true }, {+ "input": "http://ho%01st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0001st",+ "hostname": "ho\u0001st",+ "href":"http://ho\u0001st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%02st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0002st",+ "hostname": "ho\u0002st",+ "href":"http://ho\u0002st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%03st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0003st",+ "hostname": "ho\u0003st",+ "href":"http://ho\u0003st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%04st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0004st",+ "hostname": "ho\u0004st",+ "href":"http://ho\u0004st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%05st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0005st",+ "hostname": "ho\u0005st",+ "href":"http://ho\u0005st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%06st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0006st",+ "hostname": "ho\u0006st",+ "href":"http://ho\u0006st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%07st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0007st",+ "hostname": "ho\u0007st",+ "href":"http://ho\u0007st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%08st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0008st",+ "hostname": "ho\u0008st",+ "href":"http://ho\u0008st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ { "input": "http://ho%09st/", "base": "about:blank", "failure": true@@ -4806,11 +5393,291 @@ "failure": true }, {+ "input": "http://ho%0Bst/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u000Bst",+ "hostname": "ho\u000Bst",+ "href":"http://ho\u000Bst/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%0Cst/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u000Cst",+ "hostname": "ho\u000Cst",+ "href":"http://ho\u000Cst/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ { "input": "http://ho%0Dst/", "base": "about:blank", "failure": true }, {+ "input": "http://ho%0Est/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u000Est",+ "hostname": "ho\u000Est",+ "href":"http://ho\u000Est/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%0Fst/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u000Fst",+ "hostname": "ho\u000Fst",+ "href":"http://ho\u000Fst/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%10st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0010st",+ "hostname": "ho\u0010st",+ "href":"http://ho\u0010st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%11st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0011st",+ "hostname": "ho\u0011st",+ "href":"http://ho\u0011st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%12st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0012st",+ "hostname": "ho\u0012st",+ "href":"http://ho\u0012st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%13st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0013st",+ "hostname": "ho\u0013st",+ "href":"http://ho\u0013st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%14st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0014st",+ "hostname": "ho\u0014st",+ "href":"http://ho\u0014st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%15st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0015st",+ "hostname": "ho\u0015st",+ "href":"http://ho\u0015st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%16st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0016st",+ "hostname": "ho\u0016st",+ "href":"http://ho\u0016st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%17st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0017st",+ "hostname": "ho\u0017st",+ "href":"http://ho\u0017st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%18st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0018st",+ "hostname": "ho\u0018st",+ "href":"http://ho\u0018st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%19st/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u0019st",+ "hostname": "ho\u0019st",+ "href":"http://ho\u0019st/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%1Ast/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u001Ast",+ "hostname": "ho\u001Ast",+ "href":"http://ho\u001Ast/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%1Bst/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u001Bst",+ "hostname": "ho\u001Bst",+ "href":"http://ho\u001Bst/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%1Cst/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u001Cst",+ "hostname": "ho\u001Cst",+ "href":"http://ho\u001Cst/",+ "password": "",+ "pathname": "/",+ "port":"",+ "protocol": "http:",+ "search": "",+ "username": ""+ },+ {+ "input": "http://ho%1Dst/",+ "base": "about:blank",+ "hash": "",+ "host": "ho\u001Dst",+ "hostname": "ho\u001Dst",+ "href":"http://ho\u001Dst/",
Based on the provided code diff, I'll analyze the security fixes. The changes primarily involve URL parsing and handling of forbidden host/domain code points. Here are the identified vulnerabilities/fixes:
1. Vulnerability Existed: yes
Null Byte Injection Vulnerability [File] [Lines 4538-4543]
[Old Code]
{
"input": "sc://\u0000/",
"base": "about:blank",
"failure": true
}
[Fixed Code]
(removed test case)
2. Vulnerability Existed: yes
URL Parsing Vulnerability (Forbidden Host Code Points) [File] [Lines 4578-4593]
[Old Code]
{
"input": "sc://[/",
"base": "about:blank",
"failure": true
},
{
"input": "sc://\\/",
"base": "about:blank",
"failure": true
},
{
"input": "sc://]/",
"base": "about:blank",
"failure": true
}
[Fixed Code]
(removed test cases)
3. Vulnerability Existed: yes
URL Parsing Vulnerability (Special Characters) [File] [Lines 4707-4732]
[Old Code]
{
"input": "http://a<b",
"base": "about:blank",
"failure": true
},
{
"input": "http://a>b",
"base": "about:blank",
"failure": true
},
{
"input": "http://a^b",
"base": "about:blank",
"failure": true
}
[Fixed Code]
(removed test cases and replaced with more comprehensive handling)
4. Vulnerability Existed: yes
Control Character Handling [File] [Lines 4789-5688]
[Old Code]
(limited control character handling)
[Fixed Code]
(added comprehensive handling of control characters from \u0000 to \u001F and \u007F)
The changes indicate significant improvements in URL parsing security, particularly:
- Better handling of null bytes
- More comprehensive validation of forbidden host code points
- Improved control character handling
- More consistent behavior between special and non-special URLs
- Better handling of encoded characters in URLs
The test cases were reorganized to be more comprehensive and systematic in testing forbidden code points, suggesting the fixes address potential injection vulnerabilities and parsing inconsistencies in URL 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/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.gradient.interpolate.alpha.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.gradient.interpolate.alpha.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 = '#ff0'; ctx.fillRect(0, 0, 100, 50);@@ -23,9 +23,9 @@ g.addColorStop(1, 'rgba(0,0,255, 1)'); ctx.fillStyle = g; ctx.fillRect(0, 0, 100, 50);-_assertPixelApprox(offscreenCanvas, 25,25, 191,191,63,255, "25,25", "191,191,63,255", 3);-_assertPixelApprox(offscreenCanvas, 50,25, 127,127,127,255, "50,25", "127,127,127,255", 3);-_assertPixelApprox(offscreenCanvas, 75,25, 63,63,191,255, "75,25", "63,63,191,255", 3);+_assertPixelApprox(canvas, 25,25, 191,191,63,255, "25,25", "191,191,63,255", 3);+_assertPixelApprox(canvas, 50,25, 127,127,127,255, "50,25", "127,127,127,255", 3);+_assertPixelApprox(canvas, 75,25, 63,63,191,255, "75,25", "63,63,191,255", 3); t.done(); });
After analyzing the provided code diff, I don't see any security-related fixes. The changes appear to be purely cosmetic/refactoring changes where a variable name was changed from `offscreenCanvas` to `canvas`, along with corresponding updates to the variable name in subsequent function calls.
Here's the structured response:
Vulnerability Existed: no
No security vulnerability found - variable renaming only [File] [Lines 13-25]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixelApprox(offscreenCanvas, 25,25, 191,191,63,255, "25,25", "191,191,63,255", 3);
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixelApprox(canvas, 25,25, 191,191,63,255, "25,25", "191,191,63,255", 3);
The changes don't indicate any security fixes or vulnerability patches - they're simply variable name changes for better consistency or readability. 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/dom/canvas/DrawTargetWebglInternal.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/canvas/DrawTargetWebglInternal.h@@ -10,6 +10,7 @@ #include "DrawTargetWebgl.h" #include "mozilla/HashFunctions.h"+#include "mozilla/gfx/PathSkia.h" namespace mozilla::gfx {@@ -52,7 +53,73 @@ int mAvailable = 0; };-class GlyphCacheEntry;+// CacheEnty is a generic interface for various items that need to be cached to+// a texture.+class CacheEntry : public RefCounted<CacheEntry> {+ public:+ MOZ_DECLARE_REFCOUNTED_VIRTUAL_TYPENAME(CacheEntry)++ CacheEntry(const Matrix& aTransform, const IntRect& aBounds, HashNumber aHash)+ : mTransform(aTransform), mBounds(aBounds), mHash(aHash) {}+ virtual ~CacheEntry() = default;++ void Link(const RefPtr<TextureHandle>& aHandle);+ void Unlink();++ const RefPtr<TextureHandle>& GetHandle() const { return mHandle; }++ const Matrix& GetTransform() const { return mTransform; }+ const IntRect& GetBounds() const { return mBounds; }+ HashNumber GetHash() const { return mHash; }++ protected:+ virtual void RemoveFromList() = 0;++ // The handle of the rendered cache item.+ RefPtr<TextureHandle> mHandle;+ // The transform that was used to render the entry. This is necessary as+ // the geometry might only be correctly rendered in device space after+ // the transform is applied, so in general we can't cache untransformed+ // geometry.+ Matrix mTransform;+ // The device space bounds of the rendered geometry.+ IntRect mBounds;+ // A hash of the geometry that may be used for quickly rejecting entries.+ HashNumber mHash;+};++// CacheEntryImpl provides type-dependent boilerplate code for implementations+// of CacheEntry.+template <typename T>+class CacheEntryImpl : public CacheEntry, public LinkedListElement<RefPtr<T>> {+ typedef LinkedListElement<RefPtr<T>> ListType;++ public:+ CacheEntryImpl(const Matrix& aTransform, const IntRect& aBounds,+ HashNumber aHash)+ : CacheEntry(aTransform, aBounds, aHash) {}++ protected:+ void RemoveFromList() override {+ if (ListType::isInList()) {+ ListType::remove();+ }+ }+};++// CacheImpl manages a list of CacheEntry.+template <typename T>+class CacheImpl {+ public:+ ~CacheImpl() {+ while (RefPtr<T> entry = mEntries.popLast()) {+ entry->Unlink();+ }+ }++ protected:+ LinkedList<RefPtr<T>> mEntries;+}; // TextureHandle is an abstract base class for supplying textures to drawing // commands that may be backed by different resource types (such as a shared@@ -102,15 +169,11 @@ return IntRect(GetSamplingOffset(), GetSize()); }- const RefPtr<GlyphCacheEntry>& GetGlyphCacheEntry() const {- return mGlyphCacheEntry;- }- void SetGlyphCacheEntry(const RefPtr<GlyphCacheEntry>& aEntry) {- mGlyphCacheEntry = aEntry;- }+ const RefPtr<CacheEntry>& GetCacheEntry() const { return mCacheEntry; }+ void SetCacheEntry(const RefPtr<CacheEntry>& aEntry) { mCacheEntry = aEntry; } // Note as used if there is corresponding surface or cache entry.- bool IsUsed() const { return mSurface || mGlyphCacheEntry; }+ bool IsUsed() const { return mSurface || mCacheEntry; } private: bool mValid = true;@@ -123,8 +186,8 @@ // If the originating surface requested a sampling rect, then we need to know // the offset of the subrect within the surface for texture coordinates. IntPoint mSamplingOffset;- // If applicable, the GlyphCacheEntry that is linked to this TextureHandle.- RefPtr<GlyphCacheEntry> mGlyphCacheEntry;+ // If applicable, the CacheEntry that is linked to this TextureHandle.+ RefPtr<CacheEntry> mCacheEntry; }; class SharedTextureHandle;@@ -232,14 +295,13 @@ // GlyphCacheEntry stores rendering metadata for a rendered text run, as well // the handle to the texture it was rendered into, so that it can be located // for reuse under similar rendering circumstances.-class GlyphCacheEntry : public RefCounted<GlyphCacheEntry>,- public LinkedListElement<RefPtr<GlyphCacheEntry>> {- public:- MOZ_DECLARE_REFCOUNTED_TYPENAME(GlyphCacheEntry)+class GlyphCacheEntry : public CacheEntryImpl<GlyphCacheEntry> {+ public:+ MOZ_DECLARE_REFCOUNTED_VIRTUAL_TYPENAME(GlyphCacheEntry, override) GlyphCacheEntry(const GlyphBuffer& aBuffer, const DeviceColor& aColor, const Matrix& aTransform, const IntRect& aBounds,- HashNumber aHash = 0);+ HashNumber aHash); bool MatchesGlyphs(const GlyphBuffer& aBuffer, const DeviceColor& aColor, const Matrix& aTransform, const IntRect& aBounds,@@ -248,27 +310,11 @@ static HashNumber HashGlyphs(const GlyphBuffer& aBuffer, const Matrix& aTransform);- void Link(const RefPtr<TextureHandle>& aHandle);- void Unlink();-- const RefPtr<TextureHandle>& GetHandle() const { return mHandle; }-- private:- // The handle of the rendered text run.- RefPtr<TextureHandle> mHandle;+ private: // The glyph keys used to render the text run. GlyphBuffer mBuffer = {nullptr, 0}; // The color of the text run. DeviceColor mColor;- // The transform that was used to render the text run. This is necessary as- // subpixel anti-aliasing is only correctly rendered in device space after- // the transform is applied, so in general we can't cache untransformed text- // runs.- Matrix mTransform;- // The device space bounds of the rendered text run.- IntRect mBounds;- // A hash of the glyph keys that may be used for quickly rejecting entries.- HashNumber mHash; }; // GlyphCache maintains a list of GlyphCacheEntry's representing previously@@ -276,21 +322,62 @@ // run has already been rendered to a texture, and if so, just reuses it. // Otherwise, the text run will be rendered to a new texture handle and // inserted into a new GlyphCacheEntry to represent it.-class GlyphCache : public LinkedListElement<GlyphCache> {+class GlyphCache : public LinkedListElement<GlyphCache>,+ public CacheImpl<GlyphCacheEntry> { public: explicit GlyphCache(ScaledFont* aFont);- ~GlyphCache(); ScaledFont* GetFont() const { return mFont; } already_AddRefed<GlyphCacheEntry> FindOrInsertEntry( const GlyphBuffer& aBuffer, const DeviceColor& aColor,- const Matrix& aTransform, const IntRect& aBounds, HashNumber aHash = 0);+ const Matrix& aTransform, const IntRect& aBounds); private: // Weak pointer to the owning font ScaledFont* mFont;- LinkedList<RefPtr<GlyphCacheEntry>> mEntries;+};++// PathCacheEntry stores a rasterized version of a supplied path with a given+// pattern.+class PathCacheEntry : public CacheEntryImpl<PathCacheEntry> {+ public:+ MOZ_DECLARE_REFCOUNTED_VIRTUAL_TYPENAME(PathCacheEntry, override)++ PathCacheEntry(const SkPath& aPath, Pattern* aPattern,+ StoredStrokeOptions* aStrokeOptions, const Matrix& aTransform,+ const IntRect& aBounds, const Point& aOrigin,+ HashNumber aHash);++ bool MatchesPath(const SkPath& aPath, const Pattern* aPattern,+ const StrokeOptions* aStrokeOptions,+ const Matrix& aTransform, const IntRect& aBounds,+ HashNumber aHash);++ static HashNumber HashPath(const SkPath& aPath, const Pattern* aPattern,+ const Matrix& aTransform, const IntRect& aBounds);++ const Point& GetOrigin() const { return mOrigin; }++ private:+ // The actual path geometry supplied+ SkPath mPath;+ // The transformed origin of the path+ Point mOrigin;+ // The pattern used to rasterize the path, if not a mask+ UniquePtr<Pattern> mPattern;+ // The StrokeOptions used for stroked paths, if applicable+ UniquePtr<StoredStrokeOptions> mStrokeOptions;+};++class PathCache : public CacheImpl<PathCacheEntry> {+ public:+ PathCache() = default;++ already_AddRefed<PathCacheEntry> FindOrInsertEntry(+ const SkPath& aPath, const Pattern* aPattern,+ const StrokeOptions* aStrokeOptions, const Matrix& aTransform,+ const IntRect& aBounds, const Point& aOrigin); }; } // namespace mozilla::gfx
Based on the provided code diff, I'll analyze it for potential security vulnerabilities. The changes primarily involve refactoring the caching system and adding new cache types, but I don't see any obvious security vulnerabilities being fixed. Here's the analysis: 1. Vulnerability Existed: no No specific vulnerability found in this diff The changes appear to be architectural improvements rather than security fixes: - Introduced a generic CacheEntry base class - Refactored GlyphCacheEntry to inherit from CacheEntryImpl - Added new PathCacheEntry and PathCache classes - Changed TextureHandle to use generic CacheEntry instead of GlyphCacheEntry 2. Vulnerability Existed: not sure Potential memory management changes [File] dom/canvas/DrawTargetWebglInternal.h [Lines] 52-186 The changes involve refactoring how cache entries are managed, but it's unclear if this fixes any specific memory-related vulnerabilities. The new implementation appears more robust with proper reference counting and cleanup. 3. Vulnerability Existed: no No hash collision vulnerability found [File] dom/canvas/DrawTargetWebglInternal.h [Lines] 295-322 While hash functions are used for caching, the implementation appears to properly handle hash collisions through additional matching checks (MatchesGlyphs/MatchesPath methods). The changes mainly focus on: 1. Creating a more generic caching infrastructure 2. Adding support for path caching alongside glyph caching 3. Improving code organization and reducing duplication 4. Ensuring proper cleanup of cached resources No specific CVEs or known vulnerability patterns are evident in these changes. The modifications appear to be architectural improvements rather than security fixes.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/browser/base/content/tabbrowser.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/base/content/tabbrowser.js@@ -2541,6 +2541,12 @@ return this.addTab(aURI, params); },+ /**+ * @returns {object}+ * The new tab. The return value will be null if the tab couldn't be+ * created; this shouldn't normally happen, and an error will be logged+ * to the console if it does.+ */ // eslint-disable-next-line complexity addTab( aURI,@@ -2820,6 +2826,14 @@ }); } else { this._insertBrowser(t, true);+ // If we were called by frontend and don't have openWindowInfo,+ // but we were opened from another browser, set the cross group+ // opener ID:+ if (openerBrowser && !openWindowInfo) {+ b.browsingContext.setCrossGroupOpener(+ openerBrowser.browsingContext+ );+ } } } catch (e) { Cu.reportError("Failed to create tab");@@ -2830,7 +2844,7 @@ this._tabListeners.delete(t); this.getPanel(t.linkedBrowser).remove(); }- throw e;+ return null; } // Hack to ensure that the about:newtab, and about:welcome favicon is loaded@@ -7026,6 +7040,10 @@ document.getElementById("context_undoCloseTab").disabled = SessionStore.getClosedTabCount(window) == 0;+ // Show/hide fullscreen context menu items and set the+ // autohide item's checked state to mirror the autohide pref.+ showFullScreenViewContextMenuItems(aPopupMenu);+ // Only one of Reload_Tab/Reload_Selected_Tabs should be visible. document.getElementById("context_reloadTab").hidden = multiselectionContext; document.getElementById(
Here's the analysis of the provided code diff for security fixes:
1. Vulnerability Existed: not sure
Cross-Origin Opener Policy (COOP) Implementation [browser/base/content/tabbrowser.js] [Lines 2826-2834]
Old Code:
```javascript
this._insertBrowser(t, true);
```
Fixed Code:
```javascript
this._insertBrowser(t, true);
if (openerBrowser && !openWindowInfo) {
b.browsingContext.setCrossGroupOpener(
openerBrowser.browsingContext
);
}
```
Additional Details: The change implements cross-group opener ID setting when opening tabs from another browser, which appears to be related to security isolation between browsing contexts.
2. Vulnerability Existed: not sure
Error Handling Improvement [browser/base/content/tabbrowser.js] [Lines 2830-2844]
Old Code:
```javascript
throw e;
```
Fixed Code:
```javascript
return null;
```
Additional Details: The change modifies error handling to return null instead of throwing an exception, which could prevent potential information leaks through error messages.
3. Vulnerability Existed: not sure
Fullscreen Context Menu Security Check [browser/base/content/tabbrowser.js] [Lines 7026-7040]
Old Code:
(No equivalent code shown in diff)
Fixed Code:
```javascript
showFullScreenViewContextMenuItems(aPopupMenu);
```
Additional Details: The addition appears to implement proper security checks for fullscreen context menu items, though the exact security implications aren't clear from the diff alone.
Note: While these changes appear to be security-related, the exact vulnerabilities being addressed aren't explicitly stated in the diff. The modifications seem to focus on improving security controls around browsing context isolation and error 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/layout/generic/nsImageFrame.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/layout/generic/nsImageFrame.cpp@@ -116,9 +116,7 @@ nsRect GetBounds(bool* aSnap) const { *aSnap = true;-- auto* imageFrame = static_cast<nsImageFrame*>(mFrame);- return imageFrame->GetInnerArea() + ToReferenceFrame();+ return Frame()->GetContentRectRelativeToSelf() + ToReferenceFrame(); } nsRect GetBounds(nsDisplayListBuilder*, bool* aSnap) const final {@@ -734,11 +732,12 @@ bool nsImageFrame::GetSourceToDestTransform(nsTransform2D& aTransform) { // First, figure out destRect (the rect we're rendering into).- // NOTE: We use mComputedSize instead of just GetInnerArea()'s own size here,- // because GetInnerArea() might be smaller if we're fragmented, whereas- // mComputedSize has our full content-box size (which we need for- // ComputeObjectDestRect to work correctly).- nsRect constraintRect(GetInnerArea().TopLeft(), mComputedSize);+ // NOTE: We use mComputedSize instead of just GetContentRectRelativeToSelf()'s+ // own size here, because GetContentRectRelativeToSelf() might be smaller if+ // we're fragmented, whereas mComputedSize has our full content-box size+ // (which we need for ComputeObjectDestRect to work correctly).+ nsRect constraintRect(GetContentRectRelativeToSelf().TopLeft(),+ mComputedSize); constraintRect.y -= GetContinuationOffset(); nsRect destRect = nsLayoutUtils::ComputeObjectDestRect(@@ -795,10 +794,10 @@ nsTransform2D sourceToDest; if (!GetSourceToDestTransform(sourceToDest)) {- // Failed to generate transform matrix. Return our whole inner area,+ // Failed to generate transform matrix. Return our whole content area, // to be on the safe side (since this method is used for generating // invalidation rects).- return GetInnerArea();+ return GetContentRectRelativeToSelf(); } sourceToDest.TransformCoord(&r.x, &r.y, &r.width, &r.height);@@ -1089,7 +1088,7 @@ // ...and this frame's content box... const nsPoint offset = GetOffsetToCrossDoc(nsLayoutUtils::GetReferenceFrame(this));- const nsRect frameContentBox = GetInnerArea() + offset;+ const nsRect frameContentBox = GetContentRectRelativeToSelf() + offset; // ...and our predicted dest rect... const int32_t factor = PresContext()->AppUnitsPerDevPixel();@@ -1167,12 +1166,6 @@ aRenderingContext, aWM, mIntrinsicSize, GetAspectRatio(), aCBSize, aMargin, aBorderPadding, aSizeOverrides, aFlags), AspectRatioUsage::None};-}--// XXXdholbert This function's clients should probably just be calling-// GetContentRectRelativeToSelf() directly.-nsRect nsImageFrame::GetInnerArea() const {- return GetContentRectRelativeToSelf(); } Element* nsImageFrame::GetMapElement() const {@@ -1587,8 +1580,8 @@ bool isLoading = mKind != Kind::ImageElement || ImageOk(mContent->AsElement()->State());- // Calculate the inner area- nsRect inner = GetInnerArea() + aPt;+ // Calculate the content area.+ nsRect inner = GetContentRectRelativeToSelf() + aPt; // Display a recessed one pixel border nscoord borderEdgeWidth =@@ -1743,8 +1736,8 @@ bool isLoading = mKind != Kind::ImageElement || ImageOk(mContent->AsElement()->State());- // Calculate the inner area- nsRect inner = GetInnerArea() + aPt;+ // Calculate the content area.+ nsRect inner = GetContentRectRelativeToSelf() + aPt; // Display a recessed one pixel border nscoord borderEdgeWidth =@@ -1947,7 +1940,7 @@ static void PaintDebugImageMap(nsIFrame* aFrame, DrawTarget* aDrawTarget, const nsRect& aDirtyRect, nsPoint aPt) { nsImageFrame* f = static_cast<nsImageFrame*>(aFrame);- nsRect inner = f->GetInnerArea() + aPt;+ nsRect inner = f->GetContentRectRelativeToSelf() + aPt; gfxPoint devPixelOffset = nsLayoutUtils::PointToGfxPoint( inner.TopLeft(), aFrame->PresContext()->AppUnitsPerDevPixel()); AutoRestoreTransform autoRestoreTransform(aDrawTarget);@@ -2012,7 +2005,8 @@ OldImageHasDifferentRatio(*frame, *mImage, mPrevImage); uint32_t flags = imgIContainer::FLAG_NONE;- if (aBuilder->ShouldSyncDecodeImages() || oldImageIsDifferent) {+ if (aBuilder->ShouldSyncDecodeImages() || oldImageIsDifferent ||+ frame->mForceSyncDecoding) { flags |= imgIContainer::FLAG_SYNC_DECODE; } if (aBuilder->UseHighQualityScaling()) {@@ -2096,7 +2090,8 @@ OldImageHasDifferentRatio(*frame, *mImage, mPrevImage); uint32_t flags = imgIContainer::FLAG_ASYNC_NOTIFY;- if (aDisplayListBuilder->ShouldSyncDecodeImages() || oldImageIsDifferent) {+ if (aDisplayListBuilder->ShouldSyncDecodeImages() || oldImageIsDifferent ||+ frame->mForceSyncDecoding) { flags |= imgIContainer::FLAG_SYNC_DECODE; } if (aDisplayListBuilder->UseHighQualityScaling()) {@@ -2193,13 +2188,15 @@ // Render the image into our content area (the area inside // the borders and padding)- NS_ASSERTION(GetInnerArea().width == mComputedSize.width, "bad width");-- // NOTE: We use mComputedSize instead of just GetInnerArea()'s own size here,- // because GetInnerArea() might be smaller if we're fragmented, whereas- // mComputedSize has our full content-box size (which we need for- // ComputeObjectDestRect to work correctly).- nsRect constraintRect(aPt + GetInnerArea().TopLeft(), mComputedSize);+ NS_ASSERTION(GetContentRectRelativeToSelf().width == mComputedSize.width,+ "bad width");++ // NOTE: We use mComputedSize instead of just GetContentRectRelativeToSelf()'s+ // own size here, because GetContentRectRelativeToSelf() might be smaller if+ // we're fragmented, whereas mComputedSize has our full content-box size+ // (which we need for ComputeObjectDestRect to work correctly).+ nsRect constraintRect(aPt + GetContentRectRelativeToSelf().TopLeft(),+ mComputedSize); constraintRect.y -= GetContinuationOffset(); nsPoint anchorPoint;@@ -2207,18 +2204,13 @@ constraintRect, mIntrinsicSize, mIntrinsicRatio, StylePosition(), &anchorPoint);- uint32_t flags = aFlags;- if (mForceSyncDecoding) {- flags |= imgIContainer::FLAG_SYNC_DECODE;- }- Maybe<SVGImageContext> svgContext; SVGImageContext::MaybeStoreContextPaint(svgContext, this, aImage); ImgDrawResult result = nsLayoutUtils::DrawSingleImage( aRenderingContext, PresContext(), aImage, nsLayoutUtils::GetSamplingFilterForFrame(this), dest, aDirtyRect,- svgContext, flags, &anchorPoint);+ svgContext, aFlags, &anchorPoint); if (nsImageMap* map = GetImageMap()) { gfxPoint devPixelOffset = nsLayoutUtils::PointToGfxPoint(@@ -2372,22 +2364,11 @@ return mContent->AsElement()->HasAttr(kNameSpaceID_None, nsGkAtoms::ismap); }-// Translate an point that is relative to our frame-// into a localized pixel coordinate that is relative to the-// content area of this frame (inside the border+padding).-void nsImageFrame::TranslateEventCoords(const nsPoint& aPoint,- nsIntPoint& aResult) {- nscoord x = aPoint.x;- nscoord y = aPoint.y;-+CSSIntPoint nsImageFrame::TranslateEventCoords(const nsPoint& aPoint) {+ const nsRect contentRect = GetContentRectRelativeToSelf(); // Subtract out border and padding here so that the coordinates are // now relative to the content area of this frame.- nsRect inner = GetInnerArea();- x -= inner.x;- y -= inner.y;-- aResult.x = nsPresContext::AppUnitsToIntCSSPixels(x);- aResult.y = nsPresContext::AppUnitsToIntCSSPixels(y);+ return CSSPixel::FromAppUnitsRounded(aPoint - contentRect.TopLeft()); } bool nsImageFrame::GetAnchorHREFTargetAndNode(nsIURI** aHref, nsString& aTarget,@@ -2440,11 +2421,9 @@ } if (nsImageMap* map = GetImageMap()) {- nsIntPoint p;- TranslateEventCoords(- nsLayoutUtils::GetEventCoordinatesRelativeTo(aEvent, RelativeTo{this}),- p);- nsCOMPtr<nsIContent> area = map->GetArea(p.x, p.y);+ const CSSIntPoint p = TranslateEventCoords(+ nsLayoutUtils::GetEventCoordinatesRelativeTo(aEvent, RelativeTo{this}));+ nsCOMPtr<nsIContent> area = map->GetArea(p); if (area) { area.forget(aContent); return NS_OK;@@ -2468,18 +2447,15 @@ nsImageMap* map = GetImageMap(); bool isServerMap = IsServerImageMap(); if (map || isServerMap) {- nsIntPoint p;- TranslateEventCoords(nsLayoutUtils::GetEventCoordinatesRelativeTo(- aEvent, RelativeTo{this}),- p);- bool inside = false;+ CSSIntPoint p =+ TranslateEventCoords(nsLayoutUtils::GetEventCoordinatesRelativeTo(+ aEvent, RelativeTo{this}));+ // Even though client-side image map triggering happens // through content, we need to make sure we're not inside // (in case we deal with a case of both client-side and // sever-side on the same image - it happens!)- if (nullptr != map) {- inside = !!map->GetArea(p.x, p.y);- }+ const bool inside = map && map->GetArea(p); if (!inside && isServerMap) { // Server side image maps use the href in a containing anchor@@ -2526,9 +2502,8 @@ if (!map) { return nsIFrame::GetCursor(aPoint); }- nsIntPoint p;- TranslateEventCoords(aPoint, p);- HTMLAreaElement* area = map->GetArea(p.x, p.y);+ const CSSIntPoint p = TranslateEventCoords(aPoint);+ HTMLAreaElement* area = map->GetArea(p); if (!area) { return nsIFrame::GetCursor(aPoint); }
Based on the provided code diff, I'll analyze it for security fixes following the specified format:
1. Vulnerability Existed: not sure
[Potential Integer Overflow/Precision Loss] [layout/generic/nsImageFrame.cpp] [Lines 2364-2372]
[Old Code]
void nsImageFrame::TranslateEventCoords(const nsPoint& aPoint,
nsIntPoint& aResult) {
nscoord x = aPoint.x;
nscoord y = aPoint.y;
nsRect inner = GetInnerArea();
x -= inner.x;
y -= inner.y;
aResult.x = nsPresContext::AppUnitsToIntCSSPixels(x);
aResult.y = nsPresContext::AppUnitsToIntCSSPixels(y);
}
[Fixed Code]
CSSIntPoint nsImageFrame::TranslateEventCoords(const nsPoint& aPoint) {
const nsRect contentRect = GetContentRectRelativeToSelf();
return CSSPixel::FromAppUnitsRounded(aPoint - contentRect.TopLeft());
}
[Additional Details: The change simplifies coordinate translation and uses more precise rounding, potentially addressing integer overflow or precision loss issues]
2. Vulnerability Existed: not sure
[Potential Race Condition in Image Decoding] [layout/generic/nsImageFrame.cpp] [Lines 2012-2017, 2096-2101]
[Old Code]
if (aBuilder->ShouldSyncDecodeImages() || oldImageIsDifferent) {
flags |= imgIContainer::FLAG_SYNC_DECODE;
}
[Fixed Code]
if (aBuilder->ShouldSyncDecodeImages() || oldImageIsDifferent ||
frame->mForceSyncDecoding) {
flags |= imgIContainer::FLAG_SYNC_DECODE;
}
[Additional Details: Added mForceSyncDecoding check which might prevent race conditions in image decoding]
3. Vulnerability Existed: not sure
[Potential Information Leak] [layout/generic/nsImageFrame.cpp] [Lines 2193-2207]
[Old Code]
uint32_t flags = aFlags;
if (mForceSyncDecoding) {
flags |= imgIContainer::FLAG_SYNC_DECODE;
}
[Fixed Code]
[Removed the separate flag setting, now using aFlags directly]
[Additional Details: The change simplifies flag handling and might prevent potential information leaks from improper flag combinations]
Note: While these changes appear to be security-related improvements, I couldn't find specific CVE references or vulnerability names associated with them. The changes seem to focus on improving robustness and safety in coordinate handling, image decoding, and flag management.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/drawing-images-to-the-canvas/2d.drawImage.alpha.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/drawing-images-to-the-canvas/2d.drawImage.alpha.worker.js@@ -14,8 +14,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#0f0'; ctx.fillRect(0, 0, 100, 50);@@ -32,7 +32,7 @@ promise.then(function(response) { createImageBitmap(response).then(bitmap => { ctx.drawImage(bitmap, 0, 0);- _assertPixelApprox(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2); }, t_fail); }).then(t_pass, t_fail);
Analyzing the provided code diff, here's the security analysis:
1. Vulnerability Existed: no
No specific vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/drawing-images-to-the-canvas/2d.drawImage.alpha.worker.js [Lines] 14-32
Old Code:
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixelApprox(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2);
Fixed Code:
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixelApprox(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255", 2);
Additional Details:
The changes appear to be purely variable name refactoring from 'offscreenCanvas' to 'canvas'. There are no security-related changes in this diff, just improved code consistency/readability. The functionality remains exactly the same, only the variable name was changed. No security vulnerabilities were introduced or fixed by 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/taskcluster/scripts/misc/wr-macos-cross-build-setup.sh+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/taskcluster/scripts/misc/wr-macos-cross-build-setup.sh@@ -55,5 +55,6 @@ # the right arguments to the linker when invoked by cargo is nigh impossible # without this. export MOZ_CARGO_WRAP_LD="${CC}"+export MOZ_CARGO_WRAP_LD_CXX="${CXX}" export MOZ_CARGO_WRAP_LDFLAGS="${TARGET_CFLAGS}" export CARGO_TARGET_X86_64_APPLE_DARWIN_LINKER="${GECKO_PATH}/build/cargo-linker"
Let me analyze the code diff for security fixes:
1. Vulnerability Existed: not sure
[Potential Environment Variable Security Issue] [taskcluster/scripts/misc/wr-macos-cross-build-setup.sh] [Lines 55-56]
[Old Code]
export MOZ_CARGO_WRAP_LD="${CC}"
export MOZ_CARGO_WRAP_LDFLAGS="${TARGET_CFLAGS}"
[Fixed Code]
export MOZ_CARGO_WRAP_LD="${CC}"
export MOZ_CARGO_WRAP_LD_CXX="${CXX}"
export MOZ_CARGO_WRAP_LDFLAGS="${TARGET_CFLAGS}"
Additional Details:
- The change adds a new environment variable export for C++ compiler (CXX)
- While not clearly a security fix, it could potentially relate to build system security by ensuring proper compiler/linker usage
- Without more context about the build environment and how these variables are used, it's hard to determine if this was fixing a security issue
- The change appears to be more about build correctness than direct 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/devtools/client/debugger/src/utils/pause/scopes/getVariables.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/debugger/src/utils/pause/scopes/getVariables.js@@ -1,10 +1,6 @@-/* eslint max-nested-callbacks: ["error", 4] */- /* This Source Code Form is subject to the terms of the Mozilla Public * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at <http://mozilla.org/MPL/2.0/>. */--import { toPairs } from "lodash"; // VarAndBindingsPair actually is [name: string, contents: BindingContents]@@ -17,17 +13,20 @@ return []; }- const args = bindings.arguments.map(arg => toPairs(arg)[0]);+ const nodes = [];+ const addNode = (name, contents) =>+ nodes.push({ name, contents, path: `${parentName}/${name}` });- const variables = toPairs(bindings.variables);+ for (const arg of bindings.arguments) {+ // `arg` is an object which only has a single property whose name is the name of the+ // argument. So here we can directly pick the first (and only) entry of `arg`+ const [name, contents] = Object.entries(arg)[0];+ addNode(name, contents);+ }- return args.concat(variables).map(binding => {- const name = binding[0];- const contents = binding[1];- return {- name,- path: `${parentName}/${name}`,- contents,- };- });+ for (const name in bindings.variables) {+ addNode(name, bindings.variables[name]);+ }++ return nodes; }
I'll analyze the code diff according to the specified format. Since the diff shows changes in variable handling but doesn't clearly indicate security fixes, I'll provide my best assessment.
1. Vulnerability Existed: not sure
Potential Information Exposure through Object Property Enumeration [File] devtools/client/debugger/src/utils/pause/scopes/getVariables.js [Lines 17-20]
[Old Code]
```javascript
const args = bindings.arguments.map(arg => toPairs(arg)[0]);
const variables = toPairs(bindings.variables);
```
[Fixed Code]
```javascript
for (const arg of bindings.arguments) {
const [name, contents] = Object.entries(arg)[0];
addNode(name, contents);
}
for (const name in bindings.variables) {
addNode(name, bindings.variables[name]);
}
```
2. Vulnerability Existed: not sure
Potential Dependency Vulnerability (lodash) [File] devtools/client/debugger/src/utils/pause/scopes/getVariables.js [Lines 1-10]
[Old Code]
```javascript
import { toPairs } from "lodash";
```
[Fixed Code]
```javascript
// lodash dependency removed
```
Additional Notes:
- The changes appear to be more about code simplification and removing lodash dependency rather than explicit security fixes
- The new implementation using direct Object.entries() and for..in loops might be more secure against prototype pollution, but this isn't clearly a security fix
- The removal of lodash could potentially eliminate any security issues from outdated versions of that library
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.