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/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.rgb-clamp-1.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.rgb-clamp-1.worker.js@@ -13,14 +13,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillStyle = 'rgb(-1000, 1000, -1000)'; ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be primarily variable renaming and don't involve any security-sensitive modifications.
Answer for Each Vulnerability:
Vulnerability Existed: no
No security vulnerability found in this diff. The changes are limited to variable renaming (offscreenCanvas to canvas) and don't affect security.
Additional Details:
- The changes are purely cosmetic/refactoring in nature
- No security-sensitive operations were modified
- No input validation or output encoding changes were made
- No authentication/authorization logic was touched
- No cryptographic operations were modified
The diff shows a simple renaming of a variable from `offscreenCanvas` to `canvas` and updating the references accordingly in the test assertions. This doesn't represent a security fix but rather a code style or clarity improvement.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.roundrect.end.2.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.roundrect.end.2.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -29,10 +29,10 @@ ctx.roundRect(150, 150, 2000, 2000, [0]); ctx.lineTo(160, 160); ctx.stroke();-_assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");-_assertPixel(offscreenCanvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255");+_assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");+_assertPixel(canvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");+_assertPixel(canvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");+_assertPixel(canvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255"); t.done(); });
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and corresponding updates to the variable references in the assertions. Here's the analysis following your requested format:
Vulnerability Existed: no
No security vulnerability found
File: testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.roundrect.end.2.html
Lines: 17-29
Old Code: var offscreenCanvas = new OffscreenCanvas(100, 50); var ctx = offscreenCanvas.getContext('2d');
Fixed Code: var canvas = new OffscreenCanvas(100, 50); var ctx = canvas.getContext('2d');
Vulnerability Existed: no
No security vulnerability found
File: testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.roundrect.end.2.html
Lines: 29-33
Old Code: _assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255"); (and similar lines)
Fixed Code: _assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255"); (and similar lines)
The changes are purely cosmetic/refactoring in nature and don't appear to address any security issues. The functionality remains exactly the same, only the variable name has been changed for consistency or clarity.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/taskcluster/gecko_taskgraph/actions/merge_automation.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/taskcluster/gecko_taskgraph/actions/merge_automation.py@@ -2,11 +2,10 @@ # 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/.+from taskgraph.parameters import Parameters-from .registry import register_callback_action-+from gecko_taskgraph.actions.registry import register_callback_action from gecko_taskgraph.decision import taskgraph_decision-from gecko_taskgraph.parameters import Parameters from gecko_taskgraph.util.attributes import RELEASE_PROMOTION_PROJECTS
Based on the provided diff, I'll analyze it for security vulnerabilities:
1. Vulnerability Existed: not sure
[Potential Dependency Confusion] [taskcluster/gecko_taskgraph/actions/merge_automation.py] [Lines 2-6]
[Old Code]
from .registry import register_callback_action
from gecko_taskgraph.decision import taskgraph_decision
from gecko_taskgraph.parameters import Parameters
[Fixed Code]
from taskgraph.parameters import Parameters
from gecko_taskgraph.actions.registry import register_callback_action
from gecko_taskgraph.decision import taskgraph_decision
Additional Details:
- The changes involve import statement reorganization and switching from a relative import to an absolute import
- The potential issue could be dependency confusion if there was a malicious package named 'taskgraph' in PyPI, but this is speculative
- The change from relative to absolute imports might suggest previous import path resolution issues, but not necessarily a security vulnerability
No clear security vulnerabilities were identified in this diff, but the import changes could potentially affect module resolution security if there were malicious packages in the Python package index.
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.strokeRect.transform.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.strokeRect.transform.html@@ -17,15 +17,15 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.scale(10, 10); ctx.translate(0, 5); ctx.strokeStyle = '#0f0'; ctx.lineWidth = 5; ctx.strokeRect(2.5, -2.6, 5, 0.2);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });
Based on the provided diff, I don't see any security-related fixes. The changes appear to be purely cosmetic/refactoring changes (variable renaming) and don't affect security. Here's the analysis:
Vulnerability Existed: no
No security vulnerability found [File] [Lines 17-25]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes simply rename the variable `offscreenCanvas` to `canvas` and update the references accordingly. There are no security implications to 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/third_party/rust/warp/src/filters/mod.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/warp/src/filters/mod.rs@@ -6,6 +6,8 @@ pub mod addr; pub mod any; pub mod body;+#[cfg(feature = "compression")]+pub mod compression; pub mod cookie; pub mod cors; pub mod ext;
Based on the provided diff, I'll analyze it for security fixes:
1. Vulnerability Existed: no
No specific vulnerability - Feature addition [File] third_party/rust/warp/src/filters/mod.rs [Lines] 6-8
[Old Code]
pub mod body;
[Fixed Code]
pub mod body;
#[cfg(feature = "compression")]
pub mod compression;
Additional Details:
- The diff shows the addition of a new compression module guarded by a feature flag, but doesn't indicate any security vulnerability being fixed.
- This appears to be a feature addition rather than a security patch.
- No old code was removed or modified in a way that would suggest a security fix.
- The change is simply adding support for compression functionality when the corresponding feature is enabled.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/syn/src/buffer.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/syn/src/buffer.rs@@ -16,6 +16,7 @@ use proc_macro2::{Delimiter, Group, Ident, Literal, Punct, Spacing, Span, TokenStream, TokenTree}; use std::marker::PhantomData; use std::ptr;+use std::slice; /// Internal type which is used instead of `TokenTree` to represent a token tree /// within a `TokenBuffer`.@@ -36,20 +37,30 @@ /// /// *This type is available only if Syn is built with the `"parsing"` feature.* pub struct TokenBuffer {- // NOTE: Do not derive clone on this - there are raw pointers inside which- // will be messed up. Moving the `TokenBuffer` itself is safe as the actual- // backing slices won't be moved.- data: Box<[Entry]>,+ // NOTE: Do not implement clone on this - there are raw pointers inside+ // these entries which will be messed up. Moving the `TokenBuffer` itself is+ // safe as the data pointed to won't be moved.+ ptr: *const Entry,+ len: usize,+}++impl Drop for TokenBuffer {+ fn drop(&mut self) {+ unsafe {+ let slice = slice::from_raw_parts_mut(self.ptr as *mut Entry, self.len);+ let _ = Box::from_raw(slice);+ }+ } } impl TokenBuffer {- // NOTE: DO NOT MUTATE THE `Vec` RETURNED FROM THIS FUNCTION ONCE IT- // RETURNS, THE ADDRESS OF ITS BACKING MEMORY MUST REMAIN STABLE.+ // NOTE: Do not mutate the Vec returned from this function once it returns;+ // the address of its backing memory must remain stable. fn inner_new(stream: TokenStream, up: *const Entry) -> TokenBuffer { // Build up the entries list, recording the locations of any Groups // in the list to be processed later. let mut entries = Vec::new();- let mut seqs = Vec::new();+ let mut groups = Vec::new(); for tt in stream { match tt { TokenTree::Ident(sym) => {@@ -63,8 +74,8 @@ } TokenTree::Group(g) => { // Record the index of the interesting entry, and store an- // `End(null)` there temporarially.- seqs.push((entries.len(), g));+ // `End(null)` there temporarily.+ groups.push((entries.len(), g)); entries.push(Entry::End(ptr::null())); } }@@ -78,23 +89,28 @@ // constant address after this point, as we are going to store a raw // pointer into it. let mut entries = entries.into_boxed_slice();- for (idx, group) in seqs {+ for (idx, group) in groups { // We know that this index refers to one of the temporary // `End(null)` entries, and we know that the last entry is // `End(up)`, so the next index is also valid.- let seq_up = &entries[idx + 1] as *const Entry;+ let group_up = unsafe { entries.as_ptr().add(idx + 1) }; // The end entry stored at the end of this Entry::Group should // point to the Entry which follows the Group in the list.- let inner = Self::inner_new(group.stream(), seq_up);+ let inner = Self::inner_new(group.stream(), group_up); entries[idx] = Entry::Group(group, inner); }- TokenBuffer { data: entries }+ let len = entries.len();+ let ptr = Box::into_raw(entries);+ TokenBuffer {+ ptr: ptr as *const Entry,+ len,+ } } /// Creates a `TokenBuffer` containing all the tokens from the input- /// `TokenStream`.+ /// `proc_macro::TokenStream`. /// /// *This method is available only if Syn is built with both the `"parsing"` and /// `"proc-macro"` features.*@@ -102,20 +118,20 @@ not(all(target_arch = "wasm32", any(target_os = "unknown", target_os = "wasi"))), feature = "proc-macro" ))]- pub fn new(stream: pm::TokenStream) -> TokenBuffer {+ pub fn new(stream: pm::TokenStream) -> Self { Self::new2(stream.into()) } /// Creates a `TokenBuffer` containing all the tokens from the input- /// `TokenStream`.- pub fn new2(stream: TokenStream) -> TokenBuffer {+ /// `proc_macro2::TokenStream`.+ pub fn new2(stream: TokenStream) -> Self { Self::inner_new(stream, ptr::null()) } /// Creates a cursor referencing the first token in the buffer and able to /// traverse until the end of the buffer. pub fn begin(&self) -> Cursor {- unsafe { Cursor::create(&self.data[0], &self.data[self.data.len() - 1]) }+ unsafe { Cursor::create(self.ptr, self.ptr.add(self.len - 1)) } } }@@ -210,7 +226,7 @@ // situations where we should immediately exit the span after // entering it are handled correctly. unsafe {- *self = Cursor::create(&buf.data[0], self.scope);+ *self = Cursor::create(buf.ptr, self.scope); } } else { break;@@ -254,7 +270,7 @@ } }- /// If the cursor is pointing at an `Punct`, returns it along with a cursor+ /// If the cursor is pointing at a `Punct`, returns it along with a cursor /// pointing at the next `TokenTree`. pub fn punct(mut self) -> Option<(Punct, Cursor<'a>)> { self.ignore_none();@@ -321,9 +337,7 @@ Entry::Literal(lit) => lit.clone().into(), Entry::Ident(ident) => ident.clone().into(), Entry::Punct(op) => op.clone().into(),- Entry::End(..) => {- return None;- }+ Entry::End(..) => return None, }; Some((tree, unsafe { self.bump() }))
I'll analyze the code diff for security fixes following the specified format.
Vulnerability Existed: yes
Memory Safety Issue (Improper Raw Pointer Handling) [third_party/rust/syn/src/buffer.rs] [Lines 36-41, 89-96, 131-134]
[Old Code]
pub struct TokenBuffer {
data: Box<[Entry]>,
}
...
TokenBuffer { data: entries }
...
unsafe { Cursor::create(&self.data[0], &self.data[self.data.len() - 1]) }
[Fixed Code]
pub struct TokenBuffer {
ptr: *const Entry,
len: usize,
}
...
let ptr = Box::into_raw(entries);
TokenBuffer {
ptr: ptr as *const Entry,
len,
}
...
unsafe { Cursor::create(self.ptr, self.ptr.add(self.len - 1)) }
Additional Details:
- The fix changes how the TokenBuffer handles its internal data storage from using Box<[Entry]> to using raw pointers directly
- A new Drop implementation was added to properly clean up the allocated memory
- The changes improve memory safety by making the ownership and lifetime of the buffer more explicit
- The raw pointer operations are now properly contained within unsafe blocks
- The comments were updated to be more precise about the safety requirements
Vulnerability Existed: yes
Potential Memory Leak [third_party/rust/syn/src/buffer.rs] [Lines 36-41, 44-50]
[Old Code]
pub struct TokenBuffer {
data: Box<[Entry]>,
}
(No Drop implementation)
[Fixed Code]
pub struct TokenBuffer {
ptr: *const Entry,
len: usize,
}
impl Drop for TokenBuffer {
fn drop(&mut self) {
unsafe {
let slice = slice::from_raw_parts_mut(self.ptr as *mut Entry, self.len);
let _ = Box::from_raw(slice);
}
}
}
Additional Details:
- The original code didn't have explicit memory cleanup
- The fix adds a proper Drop implementation to ensure allocated memory is freed
- This prevents potential memory leaks when TokenBuffer goes out of scope
Vulnerability Existed: not sure
Potential Unsafe Pointer Arithmetic [third_party/rust/syn/src/buffer.rs] [Lines 89-96]
[Old Code]
let seq_up = &entries[idx + 1] as *const Entry;
[Fixed Code]
let group_up = unsafe { entries.as_ptr().add(idx + 1) };
Additional Details:
- The pointer arithmetic is now explicitly marked as unsafe
- The operation appears safer but I'm not entirely certain if all edge cases are handled
- The change makes the unsafe operation more visible and contained
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-002.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-002.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-002-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 value."> <style> .container {
Analysis of the provided code diff: 1. Vulnerability Existed: no No security vulnerability found in this diff. The change simply removes an empty meta tag for "flags" which doesn't impact security. The diff shows: - Removal of: `<meta name="flags" content="">` This appears to be a cleanup change rather than a security fix, as the empty flags meta tag served no purpose. No vulnerability name applies as this is not a security-related change. The modification is purely cosmetic/cleanup in nature.
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.object.invalidoffset.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.gradient.object.invalidoffset.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 g = ctx.createLinearGradient(0, 0, 100, 0); assert_throws_dom("INDEX_SIZE_ERR", function() { g.addColorStop(-1, '#000'); });
Let me analyze the provided code diff for security fixes.
Vulnerability Existed: no
[No specific vulnerability] [testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.gradient.object.invalidoffset.html] [Lines 17-18]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
Additional Notes:
1. The change appears to be purely a variable renaming from `offscreenCanvas` to `canvas`, which doesn't indicate any security vulnerability being fixed.
2. The test continues to check for proper error handling of invalid color stops in canvas gradients, but this was not modified in the diff.
3. No security-related changes are visible in this diff - it seems to be a minor code style/consistency improvement.
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/uriloader/exthandler/tests/mochitest/browser_protocol_ask_dialog_permission.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/uriloader/exthandler/tests/mochitest/browser_protocol_ask_dialog_permission.js@@ -34,6 +34,10 @@ const PRINCIPAL3 = Services.scriptSecurityManager.createContentPrincipalFromOrigin( ORIGIN3 );++const NULL_PRINCIPAL_SCHEME = Services.scriptSecurityManager+ .createNullPrincipal({})+ .scheme.toLowerCase(); let testExtension;@@ -236,6 +240,17 @@ actionConfirm = false; }+ let descriptionEl = dialogEl.querySelector("#description");+ ok(+ descriptionEl && BrowserTestUtils.is_visible(descriptionEl),+ "Has a visible description element."+ );++ ok(+ !descriptionEl.innerHTML.toLowerCase().includes(NULL_PRINCIPAL_SCHEME),+ "Description does not include NullPrincipal scheme."+ );+ await testCheckbox(dialogEl, dialogType, { hasCheckbox, actionCheckbox,@@ -324,6 +339,19 @@ hasCheckbox, "Dialog checkbox has correct visibility." );++ let checkboxLabel = dialogEl.ownerDocument.getElementById("remember-label");+ is(+ checkbox && BrowserTestUtils.is_visible(checkboxLabel),+ hasCheckbox,+ "Dialog checkbox label has correct visibility."+ );+ if (hasCheckbox) {+ ok(+ !checkboxLabel.innerHTML.toLowerCase().includes(NULL_PRINCIPAL_SCHEME),+ "Dialog checkbox label does not include NullPrincipal scheme."+ );+ } } if (typeof hasCheckboxState == "boolean") {
Analyzing the provided code diff, I can identify one clear security-related change and another potential improvement:
1. First vulnerability fix:
Vulnerability Existed: yes
Information Leakage Vulnerability [File] [Lines 34-36, 240-248, 339-348]
[Old Code]
(No code handling null principal scheme in description or checkbox labels)
[Fixed Code]
const NULL_PRINCIPAL_SCHEME = Services.scriptSecurityManager
.createNullPrincipal({})
.scheme.toLowerCase();
...
ok(
!descriptionEl.innerHTML.toLowerCase().includes(NULL_PRINCIPAL_SCHEME),
"Description does not include NullPrincipal scheme."
);
...
ok(
!checkboxLabel.innerHTML.toLowerCase().includes(NULL_PRINCIPAL_SCHEME),
"Dialog checkbox label does not include NullPrincipal scheme."
);
2. Second potential improvement:
Vulnerability Existed: not sure
Visibility Control Improvement [File] [Lines 339-344]
[Old Code]
(No explicit visibility check for checkbox label)
[Fixed Code]
is(
checkbox && BrowserTestUtils.is_visible(checkboxLabel),
hasCheckbox,
"Dialog checkbox label has correct visibility."
);
The main security fix prevents potential information leakage by ensuring that null principal scheme information isn't displayed in the dialog description or checkbox labels. The second change improves visibility control checks but may not be directly security-related.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/streams/writable-streams/byte-length-queuing-strategy.any.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/streams/writable-streams/byte-length-queuing-strategy.any.js@@ -1,4 +1,4 @@-// META: global=window,worker,jsshell+// META: global=window,worker 'use strict'; promise_test(t => {
Analysis of the provided code diff: 1. Vulnerability Existed: not sure [Potential Removal of jsshell Environment] [testing/web-platform/tests/streams/writable-streams/byte-length-queuing-strategy.any.js] [Lines 1] [Old Code] `// META: global=window,worker,jsshell` [Fixed Code] `// META: global=window,worker` Additional Details: The diff shows the removal of 'jsshell' from the test environment metadata. While this isn't a direct security vulnerability in the code itself, it might indicate a security-related decision to no longer test in the jsshell environment, possibly due to security concerns or deprecation. However, without more context about why this change was made, we can't be certain if it was for security reasons.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/dom/webgpu/Device.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/webgpu/Device.h@@ -10,6 +10,7 @@ #include "nsTHashSet.h" #include "mozilla/MozPromise.h" #include "mozilla/RefPtr.h"+#include "mozilla/WeakPtr.h" #include "mozilla/webgpu/WebGPUTypes.h" #include "mozilla/webrender/WebRenderAPI.h" #include "mozilla/DOMEventTargetHelper.h"@@ -77,7 +78,7 @@ using MappingPromise = MozPromise<ipc::Shmem, ipc::ResponseRejectReason, true>;-class Device final : public DOMEventTargetHelper {+class Device final : public DOMEventTargetHelper, public SupportsWeakPtr { public: NS_DECL_ISUPPORTS_INHERITED NS_DECL_CYCLE_COLLECTION_CLASS_INHERITED(Device, DOMEventTargetHelper)@@ -104,6 +105,8 @@ wr::ExternalImageId aExternalImageId, gfx::SurfaceFormat aFormat, gfx::IntSize* aDefaultSize); bool CheckNewWarning(const nsACString& aMessage);++ void CleanupUnregisteredInParent(); private: ~Device();@@ -149,6 +152,10 @@ const dom::GPUComputePipelineDescriptor& aDesc); already_AddRefed<RenderPipeline> CreateRenderPipeline( const dom::GPURenderPipelineDescriptor& aDesc);+ already_AddRefed<dom::Promise> CreateComputePipelineAsync(+ const dom::GPUComputePipelineDescriptor& aDesc, ErrorResult& aRv);+ already_AddRefed<dom::Promise> CreateRenderPipelineAsync(+ const dom::GPURenderPipelineDescriptor& aDesc, ErrorResult& aRv); void PushErrorScope(const dom::GPUErrorFilter& aFilter); already_AddRefed<dom::Promise> PopErrorScope(ErrorResult& aRv);
Analyzing the provided code diff for security fixes:
1. Vulnerability Existed: not sure
[Potential Memory Management Issue] [dom/webgpu/Device.h] [Lines 77-78]
[Old Code]
`class Device final : public DOMEventTargetHelper {`
[Fixed Code]
`class Device final : public DOMEventTargetHelper, public SupportsWeakPtr {`
Additional Details: The change adds WeakPtr support, which could be related to preventing dangling pointer issues, but without more context it's unclear if this was fixing an actual vulnerability.
2. Vulnerability Existed: not sure
[Potential Resource Cleanup Issue] [dom/webgpu/Device.h] [Lines 104-105]
[Old Code]
(No equivalent function existed)
[Fixed Code]
`void CleanupUnregisteredInParent();`
Additional Details: The addition of this cleanup function suggests potential resource management issues, but without seeing the implementation we can't confirm if this fixes a vulnerability.
3. Vulnerability Existed: not sure
[Potential Async Pipeline Creation Issue] [dom/webgpu/Device.h] [Lines 149-152]
[Old Code]
(No async pipeline creation methods existed)
[Fixed Code]
`already_AddRefed<dom::Promise> CreateComputePipelineAsync(...);`
`already_AddRefed<dom::Promise> CreateRenderPipelineAsync(...);`
Additional Details: The addition of async pipeline creation methods might indicate previous synchronous operations were problematic, but this could also be a feature addition rather than a security fix.
Note: The diff shows several changes that could be security-related, but without more context about the vulnerabilities being fixed or seeing the implementation details of the new methods, we can't be certain about specific vulnerabilities. The changes appear to focus on better resource management and async operations, which often correlate with security improvements.
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/streams/ReadableStreamTee.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/streams/ReadableStreamTee.cpp@@ -188,8 +188,9 @@ // Step 2. if (!mTeeState->Canceled1()) {- ReadableStreamDefaultControllerClose(- aCx, mTeeState->Branch1()->DefaultController(), aRv);+ RefPtr<ReadableStreamDefaultController> controller(+ mTeeState->Branch1()->DefaultController());+ ReadableStreamDefaultControllerClose(aCx, controller, aRv); if (aRv.Failed()) { return; }@@ -197,8 +198,9 @@ // Step 3. if (!mTeeState->Canceled2()) {- ReadableStreamDefaultControllerClose(- aCx, mTeeState->Branch2()->DefaultController(), aRv);+ RefPtr<ReadableStreamDefaultController> controller(+ mTeeState->Branch2()->DefaultController());+ ReadableStreamDefaultControllerClose(aCx, controller, aRv); if (aRv.Failed()) { return; }@@ -240,21 +242,24 @@ // Step {17,18}.1: If reading is true, if (aTeeState->Reading()) {- // Step {17,18}.1.1: Set readAgainForBranch1 to true.- aTeeState->SetReadAgainForBranch(1, true);+ // Step {17,18}.1.1: Set readAgainForBranch{1,2} to true.+ aTeeState->SetReadAgainForBranch(index, true); // Step {17,18}.1.1: Return a promise resolved with undefined.- return; }+ // Step {17,18}.2: Set reading to true. aTeeState->SetReading(true); // Step {17,18}.3: Let byobRequest be- // !ReadableByteStreamControllerGetBYOBRequest(branch1.[[controller]]).+ // !ReadableByteStreamControllerGetBYOBRequest(branch{1,2}.[[controller]]). RefPtr<ReadableStreamBYOBRequest> byobRequest = ReadableByteStreamControllerGetBYOBRequest(- aCx, aTeeState->Branch(index)->Controller()->AsByte());+ aCx, aTeeState->Branch(index)->Controller()->AsByte(), aRv);+ if (aRv.Failed()) {+ return;+ } // Step {17,18}.4: If byobRequest is null, perform pullWithDefaultReader. if (!byobRequest) {@@ -364,29 +369,33 @@ } JSContext* cx = jsapi.cx();- // Step 1.+ // Step 1. Set readAgainForBranch1 to false. mTeeState->SetReadAgainForBranch1(false);- // Step 2.+ // Step 2. Set readAgainForBranch2 to false. mTeeState->SetReadAgainForBranch2(false);- // Step 3.- JS::RootedObject chunk1(cx, mChunk);- JS::RootedObject chunk2(cx, mChunk);-- // Step 4.+ // Step 3. Let chunk1 and chunk2 be chunk.+ JS::Rooted<JSObject*> chunk1(cx, mChunk);+ JS::Rooted<JSObject*> chunk2(cx, mChunk);++ // Step 4. If canceled1 is false and canceled2 is false, ErrorResult rv; if (!mTeeState->Canceled1() && !mTeeState->Canceled2()) {- // Step 4.1- JS::RootedObject cloneResult(cx, CloneAsUint8Array(cx, mChunk));- // Step 4.2+ // Step 4.1. Let cloneResult be CloneAsUint8Array(chunk).+ JS::Rooted<JSObject*> cloneResult(cx, CloneAsUint8Array(cx, mChunk));++ // Step 4.2. If cloneResult is an abrupt completion, if (!cloneResult) {- // Step 4.2.1- JS::RootedValue exceptionValue(cx);+ // Step 4.2.1 Perform+ // !ReadableByteStreamControllerError(branch1.[[controller]],+ // cloneResult.[[Value]]).+ JS::Rooted<JS::Value> exceptionValue(cx); if (!JS_GetPendingException(cx, &exceptionValue)) { // Uncatchable exception, simply return. return; }+ JS_ClearPendingException(cx); ErrorResult rv; ReadableByteStreamControllerError(@@ -397,7 +406,9 @@ return; }- // Step 4.2.2+ // Step 4.2.2. Perform !+ // ReadableByteStreamControllerError(branch2.[[controller]],+ // cloneResult.[[Value]]). ReadableByteStreamControllerError( mTeeState->Branch2()->Controller()->AsByte(), exceptionValue, rv);@@ -406,7 +417,8 @@ return; }- // Step 4.2.3+ // Step 4.2.3. Resolve cancelPromise with !+ // ReadableStreamCancel(stream, cloneResult.[[Value]]). RefPtr<ReadableStream> stream(mTeeState->GetStream()); RefPtr<Promise> promise = ReadableStreamCancel(cx, stream, exceptionValue, rv);@@ -416,14 +428,17 @@ } mTeeState->CancelPromise()->MaybeResolve(promise);- // Step 4.2.4+ // Step 4.2.4. Return. return; }- // Step 4.3++ // Step 4.3. Otherwise, set chunk2 to cloneResult.[[Value]]. chunk2 = cloneResult; }- // Step 5.+ // Step 5. If canceled1 is false,+ // perform ! ReadableByteStreamControllerEnqueue(branch1.[[controller]],+ // chunk1). if (!mTeeState->Canceled1()) { ErrorResult rv; RefPtr<ReadableByteStreamController> controller(@@ -434,7 +449,10 @@ return; } }- // Step 6.++ // Step 6. If canceled2 is false,+ // perform ! ReadableByteStreamControllerEnqueue(branch2.[[controller]],+ // chunk2). if (!mTeeState->Canceled2()) { ErrorResult rv; RefPtr<ReadableByteStreamController> controller(@@ -446,12 +464,16 @@ } }- // Step 7.+ // Step 7. Set reading to false. mTeeState->SetReading(false);- // Step 8.+ // Step 8. If readAgainForBranch1 is true, perform pull1Algorithm. if (mTeeState->ReadAgainForBranch1()) { ByteStreamTeePullAlgorithm(cx, 1, MOZ_KnownLive(mTeeState), rv);+ } else if (mTeeState->ReadAgainForBranch2()) {+ // Step 9. Otherwise, if readAgainForBranch2 is true, perform+ // pull2Algorithm.+ ByteStreamTeePullAlgorithm(cx, 2, MOZ_KnownLive(mTeeState), rv); } }@@ -470,9 +492,65 @@ CycleCollectedJSContext::Get()->DispatchToMicroTask(task.forget()); }- void CloseSteps(JSContext* aCx, ErrorResult& aRv) override {}- void ErrorSteps(JSContext* aCx, JS::Handle<JS::Value> e,- ErrorResult& aRv) override {}+ MOZ_CAN_RUN_SCRIPT void CloseSteps(JSContext* aCx,+ ErrorResult& aRv) override {+ // Step numbering below is relative to Step 15.2. 'close steps' of+ // https://streams.spec.whatwg.org/#abstract-opdef-readablebytestreamtee++ // Step 1. Set reading to false.+ mTeeState->SetReading(false);++ // Step 2. If canceled1 is false, perform !+ // ReadableByteStreamControllerClose(branch1.[[controller]]).+ RefPtr<ReadableByteStreamController> branch1Controller =+ mTeeState->Branch1()->Controller()->AsByte();+ if (!mTeeState->Canceled1()) {+ ReadableByteStreamControllerClose(aCx, branch1Controller, aRv);+ if (aRv.Failed()) {+ return;+ }+ }++ // Step 3. If canceled2 is false, perform !+ // ReadableByteStreamControllerClose(branch2.[[controller]]).+ RefPtr<ReadableByteStreamController> branch2Controller =+ mTeeState->Branch2()->Controller()->AsByte();+ if (!mTeeState->Canceled2()) {+ ReadableByteStreamControllerClose(aCx, branch2Controller, aRv);+ if (aRv.Failed()) {+ return;+ }+ }++ // Step 4. If branch1.[[controller]].[[pendingPullIntos]] is not empty,+ // perform ! ReadableByteStreamControllerRespond(branch1.[[controller]], 0).+ if (!branch1Controller->PendingPullIntos().isEmpty()) {+ ReadableByteStreamControllerRespond(aCx, branch1Controller, 0, aRv);+ if (aRv.Failed()) {+ return;+ }+ }++ // Step 5. If branch2.[[controller]].[[pendingPullIntos]] is not empty,+ // perform ! ReadableByteStreamControllerRespond(branch2.[[controller]], 0).+ if (!branch2Controller->PendingPullIntos().isEmpty()) {+ ReadableByteStreamControllerRespond(aCx, branch2Controller, 0, aRv);+ if (aRv.Failed()) {+ return;+ }+ }++ // Step 6. If canceled1 is false or canceled2 is false, resolve+ // cancelPromise with undefined.+ if (!mTeeState->Canceled1() || !mTeeState->Canceled2()) {+ mTeeState->CancelPromise()->MaybeResolveWithUndefined();+ }+ }++ void ErrorSteps(JSContext* aCx, JS::Handle<JS::Value> aError,+ ErrorResult& aRv) override {+ mTeeState->SetReading(false);+ } protected: virtual ~PullWithDefaultReaderReadRequest() = default;@@ -485,23 +563,45 @@ NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION(PullWithDefaultReaderReadRequest) NS_INTERFACE_MAP_END_INHERITING(ReadRequest)+void ForwardReaderError(TeeState* aTeeState,+ ReadableStreamGenericReader* aThisReader);+ // https://streams.spec.whatwg.org/#abstract-opdef-readablebytestreamtee: // Step 15. void PullWithDefaultReader(JSContext* aCx, TeeState* aTeeState, ErrorResult& aRv) {- // Step 15.1: Not implemented until BYOB Readers are implemented.- MOZ_ASSERT(!aTeeState->GetReader()->IsBYOB());+ RefPtr<ReadableStreamGenericReader> reader = aTeeState->GetReader();++ // Step 15.1. If reader implements ReadableStreamBYOBReader,+ if (reader->IsBYOB()) {+ // Step 15.1.1. Assert: reader.[[readIntoRequests]] is empty.+ MOZ_ASSERT(reader->AsBYOB()->ReadIntoRequests().length() == 0);++ // Step 15.1.2. Perform ! ReadableStreamBYOBReaderRelease(reader).+ ReadableStreamBYOBReaderRelease(aCx, reader->AsBYOB(), aRv);+ if (aRv.Failed()) {+ return;+ }++ // Step 15.1.3. Set reader to ! AcquireReadableStreamDefaultReader(stream).+ reader =+ AcquireReadableStreamDefaultReader(aCx, aTeeState->GetStream(), aRv);+ if (aRv.Failed()) {+ return;+ }+ aTeeState->SetReader(reader);++ // Step 16.1.4. Perform forwardReaderError, given reader.+ ForwardReaderError(aTeeState, reader);+ } // Step 15.2 RefPtr<ReadRequest> readRequest = new PullWithDefaultReaderReadRequest(aTeeState); // Step 15.3- RefPtr<ReadableStreamGenericReader> reader = aTeeState->GetReader(); ReadableStreamDefaultReaderRead(aCx, reader, readRequest, aRv); }-void ForwardReaderError(TeeState* aTeeState,- ReadableStreamGenericReader* aThisReader); class PullWithBYOBReader_ReadIntoRequest final : public ReadIntoRequest { RefPtr<TeeState> mTeeState;@@ -658,7 +758,7 @@ return; } } else if (mTeeState->ReadAgainForBranch2()) {- ByteStreamTeePullAlgorithm(cx, 1, MOZ_KnownLive(mTeeState), rv);+ ByteStreamTeePullAlgorithm(cx, 2, MOZ_KnownLive(mTeeState), rv); if (rv.MaybeSetPendingException(cx)) { return; }@@ -703,16 +803,18 @@ // Step 4. if (!byobCanceled) {- ReadableByteStreamControllerClose(aCx, byobBranch->Controller()->AsByte(),- aRv);+ RefPtr<ReadableByteStreamController> controller =+ byobBranch->Controller()->AsByte();+ ReadableByteStreamControllerClose(aCx, controller, aRv); if (aRv.Failed()) { return; } } // Step 5. if (!otherCanceled) {- ReadableByteStreamControllerClose(- aCx, otherBranch->Controller()->AsByte(), aRv);+ RefPtr<ReadableByteStreamController> controller =+ otherBranch->Controller()->AsByte();+ ReadableByteStreamControllerClose(aCx, controller, aRv); if (aRv.Failed()) { return; }@@ -782,8 +884,8 @@ // Step 16.1.1 MOZ_ASSERT(aTeeState->GetDefaultReader()->ReadRequests().isEmpty());- // Step 16.1.2. Perform !ReadableStreamReaderGenericRelease(reader).- ReadableStreamReaderGenericRelease(aTeeState->GetReader(), aRv);+ // Step 16.1.2. Perform ! ReadableStreamDefaultReaderRelease(reader).+ ReadableStreamDefaultReaderRelease(aCx, aTeeState->GetDefaultReader(), aRv); if (aRv.Failed()) { return; }@@ -827,12 +929,12 @@ : mTeeState(aTeeState), mReader(aReader) {} MOZ_CAN_RUN_SCRIPT- void ResolvedCallback(JSContext* aCx, JS::Handle<JS::Value> aValue) override {- }+ void ResolvedCallback(JSContext* aCx, JS::Handle<JS::Value> aValue,+ ErrorResult& aRv) override {} MOZ_CAN_RUN_SCRIPT- virtual void RejectedCallback(JSContext* aCx,- JS::Handle<JS::Value> aValue) override {+ virtual void RejectedCallback(JSContext* aCx, JS::Handle<JS::Value> aValue,+ ErrorResult& aRv) override { // Step 14.1.1 if (mTeeState->GetReader() != mReader) { return;@@ -843,9 +945,8 @@ // !ReadableByteStreamControllerError(branch1.[[controller]], r). MOZ_ASSERT(mTeeState->Branch1()->Controller()->IsByte()); ReadableByteStreamControllerError(- mTeeState->Branch1()->Controller()->AsByte(), aValue, rv);- if (rv.MaybeSetPendingException(- aCx, "ReadableByteStreamTee: Error during forwardReaderError")) {+ mTeeState->Branch1()->Controller()->AsByte(), aValue, aRv);+ if (aRv.Failed()) { return; }@@ -853,9 +954,8 @@ // !ReadableByteStreamControllerError(branch2.[[controller]], r). MOZ_ASSERT(mTeeState->Branch2()->Controller()->IsByte()); ReadableByteStreamControllerError(- mTeeState->Branch2()->Controller()->AsByte(), aValue, rv);- if (rv.MaybeSetPendingException(- aCx, "ReadableByteStreamTee: Error during forwardReaderError")) {+ mTeeState->Branch2()->Controller()->AsByte(), aValue, aRv);+ if (aRv.Failed()) { return; }
Here's the analysis of the provided code diff for security fixes:
1. Vulnerability Existed: yes
Memory Safety Issue (Potential Use-After-Free) [File] dom/streams/ReadableStreamTee.cpp [Lines] 188-198
[Old Code]
ReadableStreamDefaultControllerClose(
aCx, mTeeState->Branch1()->DefaultController(), aRv);
[Fixed Code]
RefPtr<ReadableStreamDefaultController> controller(
mTeeState->Branch1()->DefaultController());
ReadableStreamDefaultControllerClose(aCx, controller, aRv);
The fix adds proper reference counting (RefPtr) to prevent potential use-after-free scenarios when accessing the controller.
2. Vulnerability Existed: yes
Memory Safety Issue (Potential Use-After-Free) [File] dom/streams/ReadableStreamTee.cpp [Lines] 240-264
[Old Code]
RefPtr<ReadableStreamBYOBRequest> byobRequest =
ReadableByteStreamControllerGetBYOBRequest(
aCx, aTeeState->Branch(index)->Controller()->AsByte());
[Fixed Code]
RefPtr<ReadableStreamBYOBRequest> byobRequest =
ReadableByteStreamControllerGetBYOBRequest(
aCx, aTeeState->Branch(index)->Controller()->AsByte(), aRv);
if (aRv.Failed()) {
return;
}
The fix adds error handling and proper reference counting to prevent potential use-after-free scenarios.
3. Vulnerability Existed: yes
Logic Error [File] dom/streams/ReadableStreamTee.cpp [Lines] 364-476
[Old Code]
if (mTeeState->ReadAgainForBranch1()) {
ByteStreamTeePullAlgorithm(cx, 1, MOZ_KnownLive(mTeeState), rv);
}
[Fixed Code]
if (mTeeState->ReadAgainForBranch1()) {
ByteStreamTeePullAlgorithm(cx, 1, MOZ_KnownLive(mTeeState), rv);
} else if (mTeeState->ReadAgainForBranch2()) {
ByteStreamTeePullAlgorithm(cx, 2, MOZ_KnownLive(mTeeState), rv);
}
The fix adds missing branch handling which could lead to incorrect stream processing.
4. Vulnerability Existed: yes
Memory Safety Issue (Potential Use-After-Free) [File] dom/streams/ReadableStreamTee.cpp [Lines] 703-827
[Old Code]
ReadableByteStreamControllerClose(aCx, byobBranch->Controller()->AsByte(),
aRv);
[Fixed Code]
RefPtr<ReadableByteStreamController> controller =
byobBranch->Controller()->AsByte();
ReadableByteStreamControllerClose(aCx, controller, aRv);
The fix adds proper reference counting to prevent potential use-after-free scenarios.
5. Vulnerability Existed: yes
Error Handling [File] dom/streams/ReadableStreamTee.cpp [Lines] 929-959
[Old Code]
virtual void RejectedCallback(JSContext* aCx,
JS::Handle<JS::Value> aValue) override {
[Fixed Code]
virtual void RejectedCallback(JSContext* aCx, JS::Handle<JS::Value> aValue,
ErrorResult& aRv) override {
The fix adds proper error handling to the callback function, preventing potential unhandled exceptions.
6. Vulnerability Existed: not sure
Potential Resource Leak [File] dom/streams/ReadableStreamTee.cpp [Lines] 563-591
[Old Code]
// Step 15.1: Not implemented until BYOB Readers are implemented.
MOZ_ASSERT(!aTeeState->GetReader()->IsBYOB());
[Fixed Code]
if (reader->IsBYOB()) {
// Implementation for BYOB readers
}
The fix adds proper handling for BYOB readers, but it's unclear if this was an actual security vulnerability or just missing functionality.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.hsla-clamp-3.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.hsla-clamp-3.worker.js@@ -13,14 +13,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillStyle = 'hsla(120, 100%, 200%, 1)'; ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 255,255,255,255, "50,25", "255,255,255,255");+_assertPixel(canvas, 50,25, 255,255,255,255, "50,25", "255,255,255,255"); t.done(); });
Based on the provided code diff, I'll analyze it for potential security vulnerabilities:
1. Vulnerability Existed: no
No specific vulnerability found [File] [Lines 13-14, 20]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 50,25, 255,255,255,255, "50,25", "255,255,255,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 50,25, 255,255,255,255, "50,25", "255,255,255,255");
Additional Details:
- This appears to be a simple variable renaming change from `offscreenCanvas` to `canvas`
- The functionality remains exactly the same, just with a different variable name
- No security implications are evident from this change
- The change is likely for consistency with other test cases or improved readability
- No CVEs or specific vulnerability patterns are involved in this change
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.pattern.image.string.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.pattern.image.string.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'); assert_throws_js(TypeError, function() { ctx.createPattern('../images/red.png', 'repeat'); }); t.done();
Analyzing the provided code diff:
1. Vulnerability Existed: no
No apparent security vulnerability [File] [Lines 13-14]
Old Code:
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
Fixed Code:
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
Additional Details:
- The change appears to be purely a variable name change from `offscreenCanvas` to `canvas`
- No security implications are evident in this change
- The test continues to assert the same TypeError for createPattern with an invalid image path
- The functionality remains identical, only the variable naming convention was modified
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/gfx/wr/wrench/src/main.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/gfx/wr/wrench/src/main.rs@@ -147,10 +147,7 @@ impl WindowWrapper { #[cfg(feature = "software")] fn upload_software_to_native(&self) {- match *self {- WindowWrapper::Headless(..) => return,- _ => {}- }+ if matches!(*self, WindowWrapper::Headless(..)) { return } let swgl = match self.software_gl() { Some(swgl) => swgl, None => return,@@ -277,7 +274,7 @@ WindowWrapper::Headless(_, ref gl, ref swgl) => { match swgl { #[cfg(feature = "software")]- Some(ref swgl) => Rc::new(swgl.clone()),+ Some(ref swgl) => Rc::new(*swgl), None => gl.clone(), #[cfg(not(feature = "software"))] _ => panic!(),@@ -331,89 +328,90 @@ None };- let wrapper = match *events_loop {- Some(ref events_loop) => {- let context_builder = glutin::ContextBuilder::new()- .with_gl(gl_request)- .with_vsync(vsync);- let window_builder = winit::WindowBuilder::new()- .with_title("WRench")- .with_multitouch()- .with_dimensions(LogicalSize::new(size.width as f64, size.height as f64));-- if angle {- angle::Context::with_window(- window_builder, context_builder, events_loop- ).map(|(_window, _context)| {- unsafe {- _context- .make_current()- .expect("unable to make context current!");- }-- let gl = match _context.get_api() {- glutin::Api::OpenGl => unsafe {- gl::GlFns::load_with(|symbol| _context.get_proc_address(symbol) as *const _)- },- glutin::Api::OpenGlEs => unsafe {- gl::GlesFns::load_with(|symbol| _context.get_proc_address(symbol) as *const _)- },- glutin::Api::WebGl => unimplemented!(),- };-- WindowWrapper::Angle(_window, _context, gl, sw_ctx)- }).unwrap()- } else {- let windowed_context = context_builder- .build_windowed(window_builder, events_loop)- .unwrap();-- let windowed_context = unsafe {- windowed_context+ let wrapper = if let Some(events_loop) = events_loop {+ let context_builder = glutin::ContextBuilder::new()+ .with_gl(gl_request)+ .with_vsync(vsync);+ let window_builder = winit::WindowBuilder::new()+ .with_title("WRench")+ .with_multitouch()+ .with_dimensions(LogicalSize::new(size.width as f64, size.height as f64));++ if angle {+ angle::Context::with_window(+ window_builder, context_builder, events_loop+ ).map(|(_window, _context)| {+ unsafe {+ _context .make_current()- .expect("unable to make context current!")- };-- let gl = match windowed_context.get_api() {+ .expect("unable to make context current!");+ }++ let gl = match _context.get_api() { glutin::Api::OpenGl => unsafe {- gl::GlFns::load_with(- |symbol| windowed_context.get_proc_address(symbol) as *const _- )+ gl::GlFns::load_with(|symbol| _context.get_proc_address(symbol) as *const _) }, glutin::Api::OpenGlEs => unsafe {- gl::GlesFns::load_with(- |symbol| windowed_context.get_proc_address(symbol) as *const _- )+ gl::GlesFns::load_with(|symbol| _context.get_proc_address(symbol) as *const _) }, glutin::Api::WebGl => unimplemented!(), };- WindowWrapper::WindowedContext(windowed_context, gl, sw_ctx)- }- }- None => {- let gl = match sw_ctx {- #[cfg(feature = "software")]- Some(ref sw_ctx) => Rc::new(sw_ctx.clone()),- None => {- match gl::GlType::default() {- gl::GlType::Gl => unsafe {- gl::GlFns::load_with(|symbol| {- HeadlessContext::get_proc_address(symbol) as *const _- })- },- gl::GlType::Gles => unsafe {- gl::GlesFns::load_with(|symbol| {- HeadlessContext::get_proc_address(symbol) as *const _- })- },- }- }- #[cfg(not(feature = "software"))]- _ => panic!(),+ WindowWrapper::Angle(_window, _context, gl, sw_ctx)+ }).unwrap()+ } else {+ let windowed_context = context_builder+ .build_windowed(window_builder, events_loop)+ .unwrap();++ let windowed_context = unsafe {+ windowed_context+ .make_current()+ .expect("unable to make context current!") };- WindowWrapper::Headless(HeadlessContext::new(size.width, size.height), gl, sw_ctx)- }++ let gl = match windowed_context.get_api() {+ glutin::Api::OpenGl => unsafe {+ gl::GlFns::load_with(+ |symbol| windowed_context.get_proc_address(symbol) as *const _+ )+ },+ glutin::Api::OpenGlEs => unsafe {+ gl::GlesFns::load_with(+ |symbol| windowed_context.get_proc_address(symbol) as *const _+ )+ },+ glutin::Api::WebGl => unimplemented!(),+ };++ WindowWrapper::WindowedContext(windowed_context, gl, sw_ctx)+ }+ } else {+ #[cfg_attr(not(feature = "software"), allow(unused_variables))]+ let gl = if let Some(sw_ctx) = sw_ctx {+ #[cfg(feature = "software")]+ {+ Rc::new(sw_ctx)+ }+ #[cfg(not(feature = "software"))]+ {+ unreachable!("make_software_context() should have failed if 'software' feature is not enabled")+ }+ } else {+ match gl::GlType::default() {+ gl::GlType::Gl => unsafe {+ gl::GlFns::load_with(|symbol| {+ HeadlessContext::get_proc_address(symbol) as *const _+ })+ },+ gl::GlType::Gles => unsafe {+ gl::GlesFns::load_with(|symbol| {+ HeadlessContext::get_proc_address(symbol) as *const _+ })+ },+ }+ };+ WindowWrapper::Headless(HeadlessContext::new(size.width, size.height), gl, sw_ctx) }; let gl = wrapper.gl();@@ -479,7 +477,7 @@ fn create_notifier() -> (Box<dyn RenderNotifier>, Receiver<NotifierEvent>) { let (tx, rx) = channel();- (Box::new(Notifier { tx: tx }), rx)+ (Box::new(Notifier { tx }), rx) } fn rawtest(mut wrench: Wrench, window: &mut WindowWrapper, rx: Receiver<NotifierEvent>) {@@ -499,7 +497,7 @@ } else { Path::new("reftests/reftest.list") };- let specific_reftest = subargs.value_of("REFTEST").map(|x| Path::new(x));+ let specific_reftest = subargs.value_of("REFTEST").map(Path::new); let mut reftest_options = ReftestOptions::default(); if let Some(allow_max_diff) = subargs.value_of("fuzz_tolerance") { reftest_options.allow_max_difference = allow_max_diff.parse().unwrap_or(1);@@ -541,13 +539,13 @@ if let Ok(wrench_args) = fs::read_to_string("/sdcard/wrench/args") { for line in wrench_args.lines() {- if line.starts_with("env: ") {- let envvar = &line[5..];- if let Some(ix) = envvar.find('=') {- std::env::set_var(&envvar[0..ix], &envvar[ix + 1..]);+ if let Some(envvar) = line.strip_prefix("env: ") {+ if let Some((lhs, rhs)) = envvar.split_once('=') {+ std::env::set_var(lhs, rhs); } else { std::env::set_var(envvar, ""); }+ continue; } for arg in line.split_whitespace() {@@ -562,7 +560,7 @@ }; // handle some global arguments- let res_path = args.value_of("shaders").map(|s| PathBuf::from(s));+ let res_path = args.value_of("shaders").map(PathBuf::from); let size = args.value_of("size") .map(|s| if s == "720p" { DeviceIntSize::new(1280, 720)@@ -581,24 +579,21 @@ .unwrap_or(DeviceIntSize::new(1920, 1080)); let chase_primitive = match args.value_of("chase") { Some(s) => {- match s.find(',') {- Some(_) => {- let items = s- .split(',')- .map(|s| s.parse::<f32>().unwrap())- .collect::<Vec<_>>();- let rect = LayoutRect::from_origin_and_size(- LayoutPoint::new(items[0], items[1]),- LayoutSize::new(items[2], items[3]),- );- webrender::ChasePrimitive::LocalRect(rect)- }- None => {- let id = s.parse::<usize>().unwrap();- webrender::ChasePrimitive::Id(webrender::PrimitiveDebugId(id))- }- }- },+ if s.contains(',') {+ let items = s+ .split(',')+ .map(|s| s.parse::<f32>().unwrap())+ .collect::<Vec<_>>();+ let rect = LayoutRect::from_origin_and_size(+ LayoutPoint::new(items[0], items[1]),+ LayoutSize::new(items[2], items[3]),+ );+ webrender::ChasePrimitive::LocalRect(rect)+ } else {+ let id = s.parse::<usize>().unwrap();+ webrender::ChasePrimitive::Id(webrender::PrimitiveDebugId(id))+ }+ } None => webrender::ChasePrimitive::Nothing, };@@ -640,9 +635,9 @@ ); let dim = window.get_inner_size();- let needs_frame_notifier = ["perf", "reftest", "png", "rawtest", "test_invalidation"]- .iter()- .any(|s| args.subcommand_matches(s).is_some());+ let needs_frame_notifier = args.subcommand_name().map_or(false, |name| {+ ["perf", "reftest", "png", "rawtest", "test_invalidation"].contains(&name)+ }); let (notifier, rx) = if needs_frame_notifier { let (notifier, rx) = create_notifier(); (Some(notifier), Some(rx))@@ -669,7 +664,7 @@ ); if let Some(ui_str) = args.value_of("profiler_ui") {- wrench.renderer.set_profiler_ui(&ui_str);+ wrench.renderer.set_profiler_ui(ui_str); } window.update(&mut wrench);@@ -704,7 +699,7 @@ } else if let Some(subargs) = args.subcommand_matches("reftest") { // Exit with an error code in order to ensure the CI job fails. process::exit(reftest(wrench, &mut window, subargs, rx.unwrap()) as _);- } else if let Some(_) = args.subcommand_matches("rawtest") {+ } else if args.subcommand_matches("rawtest").is_some() { rawtest(wrench, &mut window, rx.unwrap()); return; } else if let Some(subargs) = args.subcommand_matches("perf") {@@ -724,10 +719,7 @@ warmup_frames, sample_count);- let benchmark = match subargs.value_of("benchmark") {- Some(path) => path,- None => "benchmarks/benchmarks.list"- };+ let benchmark = subargs.value_of("benchmark").unwrap_or("benchmarks/benchmarks.list"); println!("Benchmark: {}", benchmark); let base_manifest = Path::new(benchmark);@@ -741,7 +733,7 @@ } harness.run(base_manifest, &filename, as_csv); return;- } else if let Some(_) = args.subcommand_matches("test_invalidation") {+ } else if args.subcommand_matches("test_invalidation").is_some() { let harness = test_invalidation::TestHarness::new( &mut wrench, &mut window,@@ -754,11 +746,11 @@ let second_filename = subargs.value_of("second_filename").unwrap(); perf::compare(first_filename, second_filename); return;- } else if let Some(_) = args.subcommand_matches("test_init") {+ } else if args.subcommand_matches("test_init").is_some() { // Wrench::new() unwraps the Renderer initialization, so if // we reach this point then we have initialized successfully. println!("Initialization successful");- } else if let Some(_) = args.subcommand_matches("test_shaders") {+ } else if args.subcommand_matches("test_shaders").is_some() { test_shaders::test_shaders(); } else { panic!("Should never have gotten here! {:?}", args);@@ -798,14 +790,10 @@ wrench.document_id = captured.document_id; Box::new(captured) as Box<dyn WrenchThing> } else {- let extension = input_path- .extension()- .expect("Tried to render with an unknown file type.")- .to_str()- .expect("Tried to render with an unknown file type.");-- match extension {- "yaml" => Box::new(YamlFrameReader::new_from_args(subargs)) as Box<dyn WrenchThing>,+ match input_path.extension().and_then(std::ffi::OsStr::to_str) {+ Some("yaml") => {+ Box::new(YamlFrameReader::new_from_args(subargs)) as Box<dyn WrenchThing>+ } _ => panic!("Tried to render with an unknown file type."), } };@@ -832,21 +820,17 @@ let mut body = |wrench: &mut Wrench, events: Vec<winit::Event>| { let mut do_frame = false;- let mut do_render = false;+ let mut do_render = !events.is_empty(); for event in events { match event {- winit::Event::Awakened => {- do_render = true;- }+ winit::Event::Awakened => {} winit::Event::WindowEvent { event, .. } => match event { winit::WindowEvent::CloseRequested => { return winit::ControlFlow::Break; } winit::WindowEvent::Refresh |- winit::WindowEvent::Focused(..) => {- do_render = true;- }+ winit::WindowEvent::Focused(..) => {} winit::WindowEvent::CursorMoved { position: LogicalPosition { x, y }, .. } => { cursor_position = WorldPoint::new(x as f32, y as f32); wrench.renderer.set_cursor_position(@@ -855,7 +839,6 @@ cursor_position.y.round() as i32, ), );- do_render = true; } winit::WindowEvent::KeyboardInput { input: winit::KeyboardInput {@@ -871,37 +854,30 @@ VirtualKeyCode::B => { debug_flags.toggle(DebugFlags::INVALIDATION_DBG); wrench.api.send_debug_cmd(DebugCommand::SetFlags(debug_flags));- do_render = true; } VirtualKeyCode::P => { debug_flags.toggle(DebugFlags::PROFILER_DBG); wrench.api.send_debug_cmd(DebugCommand::SetFlags(debug_flags));- do_render = true; } VirtualKeyCode::O => { debug_flags.toggle(DebugFlags::RENDER_TARGET_DBG); wrench.api.send_debug_cmd(DebugCommand::SetFlags(debug_flags));- do_render = true; } VirtualKeyCode::I => { debug_flags.toggle(DebugFlags::TEXTURE_CACHE_DBG); wrench.api.send_debug_cmd(DebugCommand::SetFlags(debug_flags));- do_render = true; } VirtualKeyCode::D => { debug_flags.toggle(DebugFlags::PICTURE_CACHING_DBG); wrench.api.send_debug_cmd(DebugCommand::SetFlags(debug_flags));- do_render = true; } VirtualKeyCode::Q => { debug_flags.toggle(DebugFlags::GPU_TIME_QUERIES | DebugFlags::GPU_SAMPLE_QUERIES); wrench.api.send_debug_cmd(DebugCommand::SetFlags(debug_flags));- do_render = true; } VirtualKeyCode::V => { debug_flags.toggle(DebugFlags::SHOW_OVERDRAW); wrench.api.send_debug_cmd(DebugCommand::SetFlags(debug_flags));- do_render = true; } VirtualKeyCode::G => { debug_flags.toggle(DebugFlags::GPU_CACHE_DBG);@@ -912,31 +888,32 @@ txn.set_root_pipeline(wrench.root_pipeline_id); wrench.api.send_transaction(wrench.document_id, txn);+ do_render = false; do_frame = true; } VirtualKeyCode::M => { wrench.api.notify_memory_pressure();- do_render = true; } VirtualKeyCode::L => { do_loop = !do_loop;- do_render = true; } VirtualKeyCode::Left => { thing.prev_frame();+ do_render = false; do_frame = true; } VirtualKeyCode::Right => { thing.next_frame();+ do_render = false; do_frame = true; } VirtualKeyCode::H => { show_help = !show_help;- do_render = true; } VirtualKeyCode::C => { let path = PathBuf::from("../captures/wrench"); wrench.api.save_capture(path, CaptureBits::all());+ do_render = false; } VirtualKeyCode::X => { let results = wrench.api.hit_test(@@ -948,23 +925,23 @@ for item in &results.items { println!(" • {:?}", item); }- println!("");+ println!();+ do_render = false; } VirtualKeyCode::Z => { debug_flags.toggle(DebugFlags::ZOOM_DBG); wrench.api.send_debug_cmd(DebugCommand::SetFlags(debug_flags));- do_render = true; } VirtualKeyCode::Y => { println!("Clearing all caches..."); wrench.api.send_debug_cmd(DebugCommand::ClearCaches(ClearCache::all())); do_frame = true; }- _ => {}+ _other_virtual_keycode => { do_render = false; } }- _ => {}+ _other_window_event => { do_render = false; } },- _ => {}+ _other_event => { do_render = false; } } }@@ -994,47 +971,44 @@ winit::ControlFlow::Continue };- match *events_loop {- None => {- while body(wrench, vec![winit::Event::Awakened]) == winit::ControlFlow::Continue {}- let fb_rect = FramebufferIntSize::new(size.width, size.height).into();- let pixels = wrench.renderer.read_pixels_rgba8(fb_rect);- save_flipped("screenshot.png", pixels, size);- }- Some(ref mut events_loop) => {- // We want to ensure that we:- //- // (a) Block the thread when no events are present (for CPU/battery purposes)- // (b) Don't lag the input events by having the event queue back up.- loop {- let mut pending_events = Vec::new();-- // Block the thread until at least one event arrives- // On Android, we are generally profiling when running- // wrench, and don't want to block on UI events.- if !no_block && cfg!(not(target_os = "android")) {- events_loop.run_forever(|event| {- pending_events.push(event);- winit::ControlFlow::Break- });- }-- // Collect any other pending events that are also available- events_loop.poll_events(|event| {+ if let Some(events_loop) = events_loop.as_mut() {+ // We want to ensure that we:+ //+ // (a) Block the thread when no events are present (for CPU/battery purposes)+ // (b) Don't lag the input events by having the event queue back up.+ loop {+ let mut pending_events = Vec::new();++ // Block the thread until at least one event arrives+ // On Android, we are generally profiling when running+ // wrench, and don't want to block on UI events.+ if !no_block && cfg!(not(target_os = "android")) {+ events_loop.run_forever(|event| { pending_events.push(event);+ winit::ControlFlow::Break });-- // Ensure there is at least one event present so that the- // frame gets rendered.- if pending_events.is_empty() {- pending_events.push(winit::Event::Awakened);- }-- // Process all of those pending events in the next vsync period- if body(wrench, pending_events) == winit::ControlFlow::Break {- break;- }- }- }- }-}+ }++ // Collect any other pending events that are also available+ events_loop.poll_events(|event| {+ pending_events.push(event);+ });++ // Ensure there is at least one event present so that the+ // frame gets rendered.+ if pending_events.is_empty() {+ pending_events.push(winit::Event::Awakened);+ }++ // Process all of those pending events in the next vsync period+ if body(wrench, pending_events) == winit::ControlFlow::Break {+ break;+ }+ }+ } else {+ while body(wrench, vec![winit::Event::Awakened]) == winit::ControlFlow::Continue {}+ let fb_rect = FramebufferIntSize::new(size.width, size.height).into();+ let pixels = wrench.renderer.read_pixels_rgba8(fb_rect);+ save_flipped("screenshot.png", pixels, size);+ }+}
I'll analyze the code diff for security fixes following the specified format:
1. Vulnerability Existed: yes
Memory Leak/Unsafe Dereference [gfx/wr/wrench/src/main.rs] [Lines 277-285]
[Old Code]
Some(ref swgl) => Rc::new(swgl.clone()),
[Fixed Code]
Some(ref swgl) => Rc::new(*swgl),
Details: The old code was creating unnecessary clones of swgl which could lead to memory leaks. The fixed version directly dereferences and creates a new Rc.
2. Vulnerability Existed: yes
Potential Command Injection [gfx/wr/wrench/src/main.rs] [Lines 539-547]
[Old Code]
if line.starts_with("env: ") {
let envvar = &line[5..];
if let Some(ix) = envvar.find('=') {
std::env::set_var(&envvar[0..ix], &envvar[ix + 1..]);
} else {
std::env::set_var(envvar, "");
}
[Fixed Code]
if let Some(envvar) = line.strip_prefix("env: ") {
if let Some((lhs, rhs)) = envvar.split_once('=') {
std::env::set_var(lhs, rhs);
} else {
std::env::set_var(envvar, "");
}
}
Details: The new version is more robust against malformed input and uses safer string manipulation methods.
3. Vulnerability Existed: not sure
Potential Resource Leak [gfx/wr/wrench/src/main.rs] [Lines 328-425]
[Old Code]
Complex match statement with nested unsafe blocks
[Fixed Code]
Simplified if-let structure with clearer scope for unsafe operations
Details: The restructuring makes the code flow clearer and potentially safer, but it's not certain if this was fixing a specific vulnerability.
4. Vulnerability Existed: not sure
Input Validation Improvement [gfx/wr/wrench/src/main.rs] [Lines 579-594]
[Old Code]
match s.find(',') {
Some(_) => { ... }
None => { ... }
}
[Fixed Code]
if s.contains(',') { ... } else { ... }
Details: The change makes the delimiter checking more straightforward, potentially preventing edge cases in input parsing.
5. Vulnerability Existed: not sure
Safer Path Handling [gfx/wr/wrench/src/main.rs] [Lines 790-797]
[Old Code]
let extension = input_path
.extension()
.expect("Tried to render with an unknown file type.")
.to_str()
.expect("Tried to render with an unknown file type.");
[Fixed Code]
match input_path.extension().and_then(std::ffi::OsStr::to_str) {
Some("yaml") => { ... }
}
Details: The new version handles path extensions more safely by combining the operations and avoiding separate expect calls.
Note: Many of the changes appear to be general code quality improvements rather than specific security fixes. The most clearly security-related changes are the memory leak fix and the command injection prevention.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.rgba-clamp-2.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.rgba-clamp-2.html@@ -17,14 +17,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillStyle = 'rgba(0, 255, 0, 2)'; ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });
Based on the provided diff, I'll analyze it for potential security vulnerabilities:
1. Vulnerability Existed: no
No specific vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.rgba-clamp-2.html [Lines] 17-25
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
ctx.fillStyle = '#f00';
ctx.fillStyle = 'rgba(0, 255, 0, 2)';
ctx.fillRect(0, 0, 100, 50);
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
ctx.fillStyle = '#f00';
ctx.fillStyle = 'rgba(0, 255, 0, 2)';
ctx.fillRect(0, 0, 100, 50);
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
Additional Details:
- The changes appear to be purely variable renaming (from 'offscreenCanvas' to 'canvas') and don't involve any security-related fixes.
- The test logic remains the same, just with a more concise variable name.
- No security vulnerabilities were addressed in this diff. The changes are likely for code consistency or readability improvements.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/accessible/base/nsAccUtils.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/accessible/base/nsAccUtils.cpp@@ -244,10 +244,10 @@ return nullptr; }-nsIntPoint nsAccUtils::ConvertToScreenCoords(int32_t aX, int32_t aY,- uint32_t aCoordinateType,- LocalAccessible* aAccessible) {- nsIntPoint coords(aX, aY);+LayoutDeviceIntPoint nsAccUtils::ConvertToScreenCoords(+ int32_t aX, int32_t aY, uint32_t aCoordinateType,+ LocalAccessible* aAccessible) {+ LayoutDeviceIntPoint coords(aX, aY); switch (aCoordinateType) { case nsIAccessibleCoordinateType::COORDTYPE_SCREEN_RELATIVE:@@ -278,7 +278,7 @@ break; case nsIAccessibleCoordinateType::COORDTYPE_WINDOW_RELATIVE: {- nsIntPoint coords =+ LayoutDeviceIntPoint coords = nsCoreUtils::GetScreenCoordsForWindow(aAccessible->GetNode()); *aX -= coords.x; *aY -= coords.y;@@ -286,7 +286,7 @@ } case nsIAccessibleCoordinateType::COORDTYPE_PARENT_RELATIVE: {- nsIntPoint coords = GetScreenCoordsForParent(aAccessible);+ LayoutDeviceIntPoint coords = GetScreenCoordsForParent(aAccessible); *aX -= coords.x; *aY -= coords.y; break;@@ -297,16 +297,18 @@ } }-nsIntPoint nsAccUtils::GetScreenCoordsForParent(LocalAccessible* aAccessible) {+LayoutDeviceIntPoint nsAccUtils::GetScreenCoordsForParent(+ LocalAccessible* aAccessible) { LocalAccessible* parent = aAccessible->LocalParent();- if (!parent) return nsIntPoint(0, 0);+ if (!parent) return LayoutDeviceIntPoint(0, 0); nsIFrame* parentFrame = parent->GetFrame();- if (!parentFrame) return nsIntPoint(0, 0);+ if (!parentFrame) return LayoutDeviceIntPoint(0, 0); nsRect rect = parentFrame->GetScreenRectInAppUnits();- return nsPoint(rect.X(), rect.Y())- .ToNearestPixels(parentFrame->PresContext()->AppUnitsPerDevPixel());+ nscoord appUnitsRatio = parentFrame->PresContext()->AppUnitsPerDevPixel();+ return LayoutDeviceIntPoint::FromAppUnitsToNearest(+ nsPoint(rect.X(), rect.Y()), appUnitsRatio); } bool nsAccUtils::GetLiveAttrValue(uint32_t aRule, nsAString& aValue) {
Let me analyze the code diff for security vulnerabilities:
1. Vulnerability Existed: not sure
[Potential Integer Overflow/Precision Loss] [accessible/base/nsAccUtils.cpp] [Lines 244-297]
[Old Code]
nsIntPoint coords(aX, aY);
[Fixed Code]
LayoutDeviceIntPoint coords(aX, aY);
The change involves switching from nsIntPoint to LayoutDeviceIntPoint, which might be related to better handling of coordinate precision or preventing potential integer overflows, but without more context about these types, I can't be certain if this fixes a specific vulnerability.
2. Vulnerability Existed: not sure
[Potential Coordinate System Conversion Issue] [accessible/base/nsAccUtils.cpp] [Lines 278-286]
[Old Code]
nsIntPoint coords = nsCoreUtils::GetScreenCoordsForWindow(aAccessible->GetNode());
[Fixed Code]
LayoutDeviceIntPoint coords = nsCoreUtils::GetScreenCoordsForWindow(aAccessible->GetNode());
The change in coordinate type might be addressing potential issues with coordinate system conversions, but again, without more context about the specific vulnerabilities being addressed, this is uncertain.
3. Vulnerability Existed: not sure
[Potential Precision Loss in Screen Coordinates] [accessible/base/nsAccUtils.cpp] [Lines 297-307]
[Old Code]
return nsPoint(rect.X(), rect.Y())
.ToNearestPixels(parentFrame->PresContext()->AppUnitsPerDevPixel());
[Fixed Code]
return LayoutDeviceIntPoint::FromAppUnitsToNearest(
nsPoint(rect.X(), rect.Y()), appUnitsRatio);
The new version uses a more explicit conversion method which might be more precise or prevent certain types of rounding errors, but I can't confirm if this was fixing a specific security vulnerability.
Note: The changes appear to be primarily about type safety and precision in coordinate calculations, which could potentially prevent certain types of vulnerabilities (like integer overflows or precision-related issues), but without explicit vulnerability reports or more context, I can't definitively say these were 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/toolkit/components/sessionstore/SessionStoreUtils.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/toolkit/components/sessionstore/SessionStoreUtils.h@@ -102,17 +102,17 @@ MOZ_CAN_RUN_SCRIPT_BOUNDARY static bool RestoreFormData(const GlobalObject& aGlobal, Document& aDocument, const CollectedData& aData);- static void RestoreFormData(+ MOZ_CAN_RUN_SCRIPT static void RestoreFormData( Document& aDocument, const nsString& aInnerHTML, const nsTArray<SessionStoreRestoreData::Entry>& aEntries); static void ComposeInputData(const nsTArray<CollectedInputDataValue>& aData, InputElementData& ret);- static already_AddRefed<nsISessionStoreRestoreData>+ MOZ_CAN_RUN_SCRIPT static already_AddRefed<nsISessionStoreRestoreData> ConstructSessionStoreRestoreData(const GlobalObject& aGlobal);- static already_AddRefed<Promise> InitializeRestore(+ MOZ_CAN_RUN_SCRIPT static already_AddRefed<Promise> InitializeRestore( const GlobalObject& aGlobal, CanonicalBrowsingContext& aContext, nsISessionStoreRestoreData* aData, ErrorResult& aError);
Here's the analysis of the provided code diff: 1. Vulnerability Existed: not sure [Potential Script Safety Issue] [SessionStoreUtils.h] [Lines 102, 108, 111] [Old Code] ```cpp static void RestoreFormData( static already_AddRefed<nsISessionStoreRestoreData> static already_AddRefed<Promise> InitializeRestore( ``` [Fixed Code] ```cpp MOZ_CAN_RUN_SCRIPT static void RestoreFormData( MOZ_CAN_RUN_SCRIPT static already_AddRefed<nsISessionStoreRestoreData> MOZ_CAN_RUN_SCRIPT static already_AddRefed<Promise> InitializeRestore( ``` Additional Details: The changes add MOZ_CAN_RUN_SCRIPT annotations to several functions. While not a direct vulnerability fix, this suggests these functions may run script content and needed proper annotation for safety. The absence of such annotations could potentially lead to unsafe script execution scenarios. Note: The diff shows the addition of MOZ_CAN_RUN_SCRIPT macros to several functions, which is typically done to properly annotate functions that can execute script content. While this isn't fixing a specific named vulnerability, it's improving script safety which could prevent potential security issues. Without more context about previous behavior, we can't be certain if this was fixing an actual vulnerability or just improving safety measures.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/js/src/gc/Tenuring.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/gc/Tenuring.cpp@@ -137,7 +137,14 @@ Value post; if (value.isObject()) { post = JS::ObjectValue(*onObjectEdge(&value.toObject()));- } else if (value.isString()) {+ }+#ifdef ENABLE_RECORD_TUPLE+ else if (value.isExtendedPrimitive()) {+ post =+ JS::ExtendedPrimitiveValue(*onObjectEdge(&value.toExtendedPrimitive()));+ }+#endif+ else if (value.isString()) { post = JS::StringValue(onStringEdge(value.toString())); } else if (value.isBigInt()) { post = JS::BigIntValue(onBigIntEdge(value.toBigInt()));
Here's the analysis of the provided code diff:
Vulnerability Existed: not sure
[Potential Type Confusion Vulnerability] [js/src/gc/Tenuring.cpp] [Lines 137-144]
[Old Code]
```cpp
Value post;
if (value.isObject()) {
post = JS::ObjectValue(*onObjectEdge(&value.toObject()));
} else if (value.isString()) {
```
[Fixed Code]
```cpp
Value post;
if (value.isObject()) {
post = JS::ObjectValue(*onObjectEdge(&value.toObject()));
}
#ifdef ENABLE_RECORD_TUPLE
else if (value.isExtendedPrimitive()) {
post =
JS::ExtendedPrimitiveValue(*onObjectEdge(&value.toExtendedPrimitive()));
}
#endif
else if (value.isString()) {
```
Additional Details:
1. The diff adds handling for extended primitive values when `ENABLE_RECORD_TUPLE` is defined, which appears to be a feature addition rather than a direct security fix.
2. Without more context about the JavaScript engine's internal handling of extended primitives, it's unclear if this was fixing a specific vulnerability or just adding feature support.
3. The change could potentially prevent type confusion issues if extended primitives weren't properly handled before, but this is speculative.
4. The modification follows a similar pattern to object handling, suggesting consistent treatment of extended primitives as object-like entities.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/dom/base/nsIGlobalObject.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/base/nsIGlobalObject.h@@ -219,6 +219,11 @@ already_AddRefed<mozilla::dom::Function> GetCountQueuingStrategySizeFunction(); void SetCountQueuingStrategySizeFunction(mozilla::dom::Function* aFunction);++ already_AddRefed<mozilla::dom::Function>+ GetByteLengthQueuingStrategySizeFunction();+ void SetByteLengthQueuingStrategySizeFunction(+ mozilla::dom::Function* aFunction); #endif /**@@ -253,6 +258,9 @@ #ifdef MOZ_DOM_STREAMS // https://streams.spec.whatwg.org/#count-queuing-strategy-size-function RefPtr<mozilla::dom::Function> mCountQueuingStrategySizeFunction;++ // https://streams.spec.whatwg.org/#byte-length-queuing-strategy-size-function+ RefPtr<mozilla::dom::Function> mByteLengthQueuingStrategySizeFunction; #endif };
Based on the provided code diff, I'll analyze it for potential security vulnerabilities:
1. Vulnerability Existed: no
No specific vulnerability found [File] dom/base/nsIGlobalObject.h [Lines] 219-258
[Old Code]
Only had mCountQueuingStrategySizeFunction related methods and member
[Fixed Code]
Added mByteLengthQueuingStrategySizeFunction related methods and member
Additional Details:
- The changes appear to be adding new functionality (byte length queuing strategy) to match the Streams API specification
- No security-related fixes are evident in this diff
- The changes follow the same pattern as the existing count queuing strategy implementation
- No memory management issues or unsafe operations are being introduced
This appears to be a feature addition rather than a security fix. The implementation follows the same safe RefPtr pattern used for the existing similar functionality.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.