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/dom/system/tests/ioutils/test_ioutils_read_write_utf8.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/system/tests/ioutils/test_ioutils_read_write_utf8.html@@ -27,8 +27,7 @@ add_task(async function test_read_utf8_failure() { info("Test attempt to read non-existent file (UTF8)");- const tmpDir = await PathUtils.getTempDir();- const doesNotExist = PathUtils.join(tmpDir, "does_not_exist.tmp");+ const doesNotExist = PathUtils.join(PathUtils.tempDir, "does_not_exist.tmp"); await Assert.rejects( IOUtils.readUTF8(doesNotExist), /Could not open the file at .*/,@@ -36,7 +35,7 @@ ); info("Test attempt to read invalid UTF-8");- const invalidUTF8File = PathUtils.join(tmpDir, "invalid_utf8.tmp");+ const invalidUTF8File = PathUtils.join(PathUtils.tempDir, "invalid_utf8.tmp"); // Deliberately write the invalid byte sequence to file. await IOUtils.write(invalidUTF8File, invalidUTF8);@@ -51,9 +50,8 @@ }); add_task(async function test_write_utf8_no_overwrite() {- const tmpDir = await PathUtils.getTempDir(); // Make a new file, and try to write to it with overwrites disabled.- const tmpFileName = PathUtils.join(tmpDir, "test_ioutils_write_utf8_overwrite.tmp");+ const tmpFileName = PathUtils.join(PathUtils.tempDir, "test_ioutils_write_utf8_overwrite.tmp"); const untouchableContents = "Can't touch this!\n"; await IOUtils.writeUTF8(tmpFileName, untouchableContents);@@ -90,9 +88,8 @@ add_task(async function test_write_with_backup() { info("Test backup file option with non-existing file");- const tmpDir = await PathUtils.getTempDir(); let fileContents = "Original file contents";- let destFileName = PathUtils.join(tmpDir, "test_write_utf8_with_backup_option.tmp");+ let destFileName = PathUtils.join(PathUtils.tempDir, "test_write_utf8_with_backup_option.tmp"); let backupFileName = destFileName + ".backup"; let bytesWritten = await IOUtils.writeUTF8(destFileName, fileContents, {@@ -138,11 +135,10 @@ add_task(async function test_write_with_backup_and_tmp() { info("Test backup with tmp and backup file options, non-existing destination");- const tmpDir = await PathUtils.getTempDir(); let fileContents = "Original file contents";- let destFileName = PathUtils.join(tmpDir, "test_write_utf8_with_backup_and_tmp_options.tmp");+ let destFileName = PathUtils.join(PathUtils.tempDir, "test_write_utf8_with_backup_and_tmp_options.tmp"); let backupFileName = destFileName + ".backup";- let tmpFileName = PathUtils.join(tmpDir, "temp_file.tmp");+ let tmpFileName = PathUtils.join(PathUtils.tempDir, "temp_file.tmp"); let bytesWritten = await IOUtils.writeUTF8(destFileName, fileContents, { backupFile: backupFileName,@@ -190,8 +186,7 @@ }); add_task(async function test_empty_read_and_write_utf8() {- const tmpDir = await PathUtils.getTempDir();- const tmpFileName = PathUtils.join(tmpDir, "test_ioutils_empty_utf8.tmp");+ const tmpFileName = PathUtils.join(PathUtils.tempDir, "test_ioutils_empty_utf8.tmp"); const emptyString = "" const bytesWritten = await IOUtils.writeUTF8( tmpFileName,@@ -208,8 +203,7 @@ add_task(async function test_full_read_and_write_utf8() { // Write a file. info("Test writing emoji file");- const tmpDir = await PathUtils.getTempDir();- const tmpFileName = PathUtils.join(tmpDir, "test_ioutils_emoji.tmp");+ const tmpFileName = PathUtils.join(PathUtils.tempDir, "test_ioutils_emoji.tmp"); // Make sure non-ASCII text is supported for writing and reading back. // For fun, a sampling of space-separated emoji characters from different@@ -261,8 +255,7 @@ add_task(async function test_utf8_lz4() {- const tmpDir = await PathUtils.getTempDir();- const tmpFileName = PathUtils.join(tmpDir, "test_ioutils_utf8_lz4.tmp");+ const tmpFileName = PathUtils.join(PathUtils.tempDir, "test_ioutils_utf8_lz4.tmp"); info("Test writing lz4 encoded UTF-8 string"); const emoji = "☕️ ⚧️ 😀 🖖🏿 🤠 🏳️🌈 🥠 🏴☠️ 🪐";@@ -298,9 +291,8 @@ }); add_task(async function test_utf8_lz4_osfile_compat() {- const tmpDir = await PathUtils.getTempDir();- const osfileTmpFile = PathUtils.join(tmpDir, "test_ioutils_utf8_lz4_compat_osfile.tmp");- const ioutilsTmpFile = PathUtils.join(tmpDir, "test_ioutils_utf8_lz4_compat_ioutils.tmp");+ const osfileTmpFile = PathUtils.join(PathUtils.tempDir, "test_ioutils_utf8_lz4_compat_osfile.tmp");+ const ioutilsTmpFile = PathUtils.join(PathUtils.tempDir, "test_ioutils_utf8_lz4_compat_ioutils.tmp"); info("Test OS.File and IOUtils write the same UTF-8 file with LZ4 compression enabled") const emoji = "☕️ ⚧️ 😀 🖖🏿 🤠 🏳️🌈 🥠 🏴☠️ 🪐";@@ -322,8 +314,7 @@ }); add_task(async function test_utf8_lz4_bad_call() {- const tmpDir = await PathUtils.getTempDir();- const tmpFileName = PathUtils.join(tmpDir, "test_ioutils_utf8_lz4_bad_call.tmp");+ const tmpFileName = PathUtils.join(PathUtils.tempDir, "test_ioutils_utf8_lz4_bad_call.tmp"); info("readUTF8 ignores the maxBytes option if provided"); const emoji = "☕️ ⚧️ 😀 🖖🏿 🤠 🏳️🌈 🥠 🏴☠️ 🪐";@@ -337,8 +328,7 @@ }); add_task(async function test_utf8_lz4_failure() {- const tmpDir = await PathUtils.getTempDir();- const tmpFileName = PathUtils.join(tmpDir, "test_ioutils_utf8_lz4_fail.tmp");+ const tmpFileName = PathUtils.join(PathUtils.tempDir, "test_ioutils_utf8_lz4_fail.tmp"); info("Test decompression of non-lz4 UTF-8 string"); const repeatedBytes = Uint8Array.of(...new Array(50).fill(1));
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be primarily code optimizations and simplifications, replacing repeated calls to `PathUtils.getTempDir()` with direct access to the `PathUtils.tempDir` property. Here's the analysis following your requested format: Vulnerability Existed: no [No security vulnerability found] [dom/system/tests/ioutils/test_ioutils_read_write_utf8.html] [Various lines] [Old Code: Repeated calls to PathUtils.getTempDir()] [Fixed Code: Using PathUtils.tempDir directly] The changes consist of: 1. Removing redundant async calls to get the temp directory 2. Using the static tempDir property instead 3. No security-related changes were made to file handling, path validation, or data processing These changes improve performance by eliminating unnecessary async operations but don't address any security vulnerabilities. The test cases remain the same in terms of their security properties. No other vulnerabilities were identified in the diff. The changes are purely optimization-focused rather than 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/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.hex3.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.hex3.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 = '#0f0'; ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });
Based on the provided diff, I'll analyze it for security vulnerabilities:
1. Vulnerability Existed: no
No specific vulnerability [File] [Lines 13-14, 20]
Old Code:
```javascript
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
```
Fixed Code:
```javascript
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
```
Additional Details: This appears to be a simple variable name change from 'offscreenCanvas' to 'canvas' with no security implications.
2. Vulnerability Existed: no
No specific vulnerability [File] [Line 20]
Old Code:
```javascript
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
```
Fixed Code:
```javascript
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
```
Additional Details: This is a corresponding change to match the variable name change above, with no security impact.
The changes appear to be purely cosmetic (variable renaming) with no security implications. No vulnerabilities were fixed in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.clip.destination-atop.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.clip.destination-atop.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 = '#0f0';@@ -28,8 +28,8 @@ ctx.clip(); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 50, 50);-_assertPixel(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");-_assertPixel(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255");+_assertPixel(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");+_assertPixel(canvas, 75,25, 0,255,0,255, "75,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 purely variable renaming and don't affect security aspects. Here's the analysis:
1. Vulnerability Existed: no
No security vulnerability found [testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.clip.destination-atop.html] [Lines 17-28]
Old Code:
```
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
[...]
_assertPixel(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");
_assertPixel(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255");
```
Fixed Code:
```
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
[...]
_assertPixel(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");
_assertPixel(canvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255");
```
The changes simply rename the variable `offscreenCanvas` to `canvas` and update all references to it. This is a code style/readability change rather than a security fix. No security vulnerabilities were addressed in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/neqo-http3/tests/webtransport/mod.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/neqo-http3/tests/webtransport/mod.rs@@ -7,14 +7,15 @@ mod negotiation; mod sessions; mod streams;- use neqo_common::event::Provider;+ use neqo_crypto::AuthenticationStatus; use neqo_http3::{- Error, Http3Client, Http3ClientEvent, Http3OrWebTransportStream, Http3Parameters, Http3Server,- Http3ServerEvent, Http3State, WebTransportEvent, WebTransportRequest, WebTransportServerEvent,+ features::extended_connect::SessionCloseReason, Error, Http3Client, Http3ClientEvent,+ Http3OrWebTransportStream, Http3Parameters, Http3Server, Http3ServerEvent, Http3State,+ WebTransportEvent, WebTransportRequest, WebTransportServerEvent, };-use neqo_transport::{AppError, StreamId, StreamType};+use neqo_transport::{StreamId, StreamType}; use std::cell::RefCell; use std::rc::Rc; use test_fixture::{@@ -106,6 +107,10 @@ Self { client, server } }+ pub fn new_with(mut client: Http3Client, mut server: Http3Server) -> Self {+ connect_with(&mut client, &mut server);+ Self { client, server }+ } fn negotiate_wt_session(&mut self, accept: bool) -> (StreamId, Option<WebTransportRequest>) { let wt_session_id = self .client@@ -147,7 +152,10 @@ let wt_session_negotiated_event = |e| { matches!( e,- Http3ClientEvent::WebTransport(WebTransportEvent::Session(stream_id)) if stream_id == wt_session_id+ Http3ClientEvent::WebTransport(WebTransportEvent::Session{+ stream_id,+ status+ }) if stream_id == wt_session_id && status == 200 ) }; assert!(self.client.events().any(wt_session_negotiated_event));@@ -178,14 +186,14 @@ fn session_closed_client( e: &Http3ClientEvent, id: StreamId,- expected_error: &Option<AppError>,+ expected_reason: &SessionCloseReason, ) -> bool { if let Http3ClientEvent::WebTransport(WebTransportEvent::SessionClosed { stream_id,- error,+ reason, }) = e {- *stream_id == id && error == expected_error+ *stream_id == id && reason == expected_reason } else { false }@@ -194,12 +202,12 @@ pub fn check_session_closed_event_client( &mut self, wt_session_id: StreamId,- expected_error: Option<AppError>,+ expected_reason: SessionCloseReason, ) { let mut event_found = false; while let Some(event) = self.client.next_event() {- event_found = WtTest::session_closed_client(&event, wt_session_id, &expected_error);+ event_found = WtTest::session_closed_client(&event, wt_session_id, &expected_reason); if event_found { break; }@@ -215,14 +223,14 @@ fn session_closed_server( e: &Http3ServerEvent, id: StreamId,- expected_error: &Option<AppError>,+ expected_reason: &SessionCloseReason, ) -> bool { if let Http3ServerEvent::WebTransport(WebTransportServerEvent::SessionClosed { session,- error,+ reason, }) = e {- session.stream_id() == id && error == expected_error+ session.stream_id() == id && reason == expected_reason } else { false }@@ -231,13 +239,13 @@ pub fn check_session_closed_event_server( &mut self, wt_session: &mut WebTransportRequest,- expected_error: Option<AppError>,+ expected_reeason: SessionCloseReason, ) { let event = self.server.next_event().unwrap(); assert!(WtTest::session_closed_server( &event, wt_session.stream_id(),- &expected_error+ &expected_reeason )); }@@ -345,7 +353,7 @@ expected_stop_sending_ids: &[StreamId], expected_error_stream_stop_sending: Option<u64>, expected_local: bool,- expected_session_close: Option<(StreamId, Option<u64>)>,+ expected_session_close: Option<(StreamId, SessionCloseReason)>, ) { let mut reset_ids_count = 0; let mut stop_sending_ids_count = 0;@@ -369,11 +377,11 @@ } Http3ClientEvent::WebTransport(WebTransportEvent::SessionClosed { stream_id,- error,+ reason, }) => { close_event = true;- assert_eq!(stream_id, expected_session_close.unwrap().0);- assert_eq!(expected_session_close.unwrap().1, error);+ assert_eq!(stream_id, expected_session_close.as_ref().unwrap().0);+ assert_eq!(expected_session_close.as_ref().unwrap().1, reason); } _ => {} }@@ -486,7 +494,7 @@ expected_error_stream_reset: Option<u64>, expected_stop_sending_ids: &[StreamId], expected_error_stream_stop_sending: Option<u64>,- expected_session_close: Option<(StreamId, Option<u64>)>,+ expected_session_close: Option<(StreamId, SessionCloseReason)>, ) { let mut reset_ids_count = 0; let mut stop_sending_ids_count = 0;@@ -505,11 +513,14 @@ } Http3ServerEvent::WebTransport(WebTransportServerEvent::SessionClosed { session,- error,+ reason, }) => { close_event = true;- assert_eq!(session.stream_id(), expected_session_close.unwrap().0);- assert_eq!(expected_session_close.unwrap().1, error);+ assert_eq!(+ session.stream_id(),+ expected_session_close.as_ref().unwrap().0+ );+ assert_eq!(expected_session_close.as_ref().unwrap().1, reason); } _ => {} }@@ -518,4 +529,19 @@ assert_eq!(stop_sending_ids_count, expected_stop_sending_ids.len()); assert_eq!(close_event, expected_session_close.is_some()); }-}++ pub fn session_close_frame_client(&mut self, session_id: StreamId, error: u32, message: &str) {+ self.client+ .webtransport_close_session(session_id, error, message)+ .unwrap();+ }++ pub fn session_close_frame_server(+ &mut self,+ wt_session: &mut WebTransportRequest,+ error: u32,+ message: &str,+ ) {+ wt_session.close_session(error, message).unwrap();+ }+}
Let me analyze the code diff for security fixes. Here are the observations:
1. Vulnerability Existed: not sure
[Session Status Validation] [third_party/rust/neqo-http3/tests/webtransport/mod.rs] [Lines 147-154]
[Old Code]
matches!(
e,
Http3ClientEvent::WebTransport(WebTransportEvent::Session(stream_id)) if stream_id == wt_session_id
)
[Fixed Code]
matches!(
e,
Http3ClientEvent::WebTransport(WebTransportEvent::Session{
stream_id,
status
}) if stream_id == wt_session_id && status == 200
)
2. Vulnerability Existed: not sure
[Session Close Reason Handling] [third_party/rust/neqo-http3/tests/webtransport/mod.rs] [Lines 178-186, 194-202]
[Old Code]
fn session_closed_client(
e: &Http3ClientEvent,
id: StreamId,
expected_error: &Option<AppError>,
) -> bool
[Fixed Code]
fn session_closed_client(
e: &Http3ClientEvent,
id: StreamId,
expected_reason: &SessionCloseReason,
) -> bool
3. Vulnerability Existed: not sure
[Session Close Frame Implementation] [third_party/rust/neqo-http3/tests/webtransport/mod.rs] [Lines 529-543]
[Old Code]
(Not present in old version)
[Fixed Code]
pub fn session_close_frame_client(&mut self, session_id: StreamId, error: u32, message: &str) {
self.client
.webtransport_close_session(session_id, error, message)
.unwrap();
}
pub fn session_close_frame_server(
&mut self,
wt_session: &mut WebTransportRequest,
error: u32,
message: &str,
) {
wt_session.close_session(error, message).unwrap();
}
The changes appear to be related to improved WebTransport session handling, including:
1. Adding status code validation for session negotiation
2. Replacing simple error codes with structured SessionCloseReason
3. Adding explicit session close frame methods
While these changes improve robustness, I can't definitively say they fix specific vulnerabilities without more context about the threat model.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/taskcluster/ci/l10n-bump/kind.yml+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/taskcluster/ci/l10n-bump/kind.yml@@ -72,6 +72,7 @@ default: name: Firefox l10n changesets path: browser/locales/l10n-changesets.json+ l10n-repo-url: "https://hg.mozilla.org/l10n-central/%(locale)s/json-pushes?version=2&tipsonly=1" version-path: browser/config/version.txt ignore-config: ja:
Analysis of the provided code diff:
1. Vulnerability Existed: not sure
[Potential Information Exposure] [taskcluster/ci/l10n-bump/kind.yml] [Lines 72-76]
[Old Code]
name: Firefox l10n changesets
path: browser/locales/l10n-changesets.json
version-path: browser/config/version.txt
ignore-config:
ja:
[Fixed Code]
name: Firefox l10n changesets
path: browser/locales/l10n-changesets.json
l10n-repo-url: "https://hg.mozilla.org/l10n-central/%(locale)s/json-pushes?version=2&tipsonly=1"
version-path: browser/config/version.txt
ignore-config:
ja:
Additional Details:
- The diff adds a new configuration parameter `l10n-repo-url` that points to Mozilla's Mercurial repository for localization data
- While this isn't a direct security vulnerability, exposing repository URLs could potentially aid attackers in reconnaissance
- The URL appears to be intentionally public and versioned (version=2 parameter), so this is likely not a security issue but rather a configuration improvement
- No specific vulnerability name applies here, but we're noting it for completeness
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/webrender/src/render_backend.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/gfx/wr/webrender/src/render_backend.rs@@ -10,7 +10,7 @@ use api::{DebugFlags, BlobImageHandler, Parameter, BoolParameter}; use api::{DocumentId, ExternalScrollId, HitTestResult};-use api::{IdNamespace, PipelineId, RenderNotifier};+use api::{IdNamespace, PipelineId, RenderNotifier, SampledScrollOffset}; use api::{NotificationRequest, Checkpoint, QualitySettings}; use api::{PrimitiveKeyKind, RenderReasons}; use api::units::*;@@ -393,10 +393,10 @@ FrameMsg::RequestHitTester(tx) => { tx.send(self.shared_hit_tester.clone()).unwrap(); }- FrameMsg::SetScrollOffset(id, offset) => {+ FrameMsg::SetScrollOffsets(id, offset) => { profile_scope!("SetScrollOffset");- if self.set_scroll_offset(id, offset) {+ if self.set_scroll_offsets(id, offset) { self.hit_tester_is_valid = false; self.frame_is_valid = false; }@@ -511,12 +511,12 @@ } /// Returns true if the node actually changed position or false otherwise.- pub fn set_scroll_offset(+ pub fn set_scroll_offsets( &mut self, id: ExternalScrollId,- offset: LayoutVector2D,+ offsets: Vec<SampledScrollOffset>, ) -> bool {- self.spatial_tree.set_scroll_offset(id, offset)+ self.spatial_tree.set_scroll_offsets(id, offsets) } /// Update the state of tile caches when a new scene is being swapped in to
Based on the provided code diff, I'll analyze it for security vulnerabilities:
1. Vulnerability Existed: not sure
[Potential Parameter Injection] [gfx/wr/webrender/src/render_backend.rs] [Lines 393-399, 511-517]
[Old Code]
FrameMsg::SetScrollOffset(id, offset) => {
if self.set_scroll_offset(id, offset) {
...
pub fn set_scroll_offset(&mut self, id: ExternalScrollId, offset: LayoutVector2D) -> bool {
self.spatial_tree.set_scroll_offset(id, offset)
[Fixed Code]
FrameMsg::SetScrollOffsets(id, offset) => {
if self.set_scroll_offsets(id, offset) {
...
pub fn set_scroll_offsets(&mut self, id: ExternalScrollId, offsets: Vec<SampledScrollOffset>) -> bool {
self.spatial_tree.set_scroll_offsets(id, offsets)
Additional Details: The change involves modifying how scroll offsets are handled, moving from a single offset to a vector of sampled offsets. While this appears to be a functional improvement, it could potentially address security issues related to scroll offset handling, though no specific vulnerability is evident from the diff alone.
2. Vulnerability Existed: no
[No specific vulnerability found] [gfx/wr/webrender/src/render_backend.rs] [Lines 10]
[Old Code]
use api::{IdNamespace, PipelineId, RenderNotifier};
[Fixed Code]
use api::{IdNamespace, PipelineId, RenderNotifier, SampledScrollOffset};
Additional Details: This is simply an addition of an import statement to support the new functionality and doesn't indicate any security fix.
The main change appears to be a functional improvement in scroll offset handling rather than a direct security fix. The modification from handling a single offset to multiple sampled offsets could potentially make the system more robust against certain types of input, but there's no clear evidence of a specific vulnerability being addressed.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/CSS2/floats/floats-in-table-caption-001.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/CSS2/floats/floats-in-table-caption-001.html@@ -3,7 +3,6 @@ <link rel="author" title="David Grogan" href="[email protected]"> <link rel="help" href="https://www.w3.org/TR/CSS22/tables.html#model"> <link rel="match" href="floats-in-table-caption-001-ref.html">-<meta name="flags" content="" /> <meta name="assert" content="Basic floats are honored inside a caption" /> <title> Caption block containers are rendered same as normal block boxes
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 ("flags") which doesn't affect security.
Additional notes:
- The diff shows removal of a non-functional meta tag that wasn't serving any purpose
- No actual code changes that could affect security were made
- This appears to be a cleanup change rather than a security fix
- No known vulnerabilities are associated with empty meta tags
The change is simply:
Old Code: `<meta name="flags" content="" />`
Fixed Code: (removed line)
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-color/t424-hsl-values-b-4.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-color/t424-hsl-values-b-4.html@@ -6,7 +6,6 @@ <link rel="author" title="Intel" href="http://www.intel.com"> <link rel="help" href="http://www.w3.org/TR/css3-color/#hsl-color" /> <link rel="match" href="t424-hsl-values-b-4-ref.html" />-<meta name="flags" content="" /> <meta name="assert" content="Implementation of algorithm for converting hsl() colors to rgb() colors." /> <style> table { border-spacing: 0; padding: 0; border: none; }
Let me analyze the provided code diff for potential security vulnerabilities. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/css/css-color/t424-hsl-values-b-4.html [Lines 6] [Old Code] <meta name="flags" content="" /> [Fixed Code] (removed line) Additional Details: - The change simply removes an empty meta tag with a "flags" attribute - This appears to be a cleanup change rather than a security fix - No known vulnerability is associated with this change - The modification doesn't affect any security-related functionality Vulnerability Existed: no No security vulnerability fixed [File] testing/web-platform/tests/css/css-color/t424-hsl-values-b-4.html [Old Code] (entire file context) [Fixed Code] (entire file context) Additional Details: - The diff shows only one line being removed (an empty meta tag) - No security-relevant changes were made to the actual test logic or HTML structure - The test appears to be for color conversion functionality, not security features - No XSS, injection, or other web security issues are addressed by this change The change appears to be minor cleanup rather than addressing any security concerns. The removed meta tag was empty and not serving any apparent purpose.
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/xpconnect/src/xpcprivate.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/xpconnect/src/xpcprivate.h@@ -2243,10 +2243,12 @@ bool FileReader : 1; bool FormData : 1; bool Headers : 1;+ bool IOUtils : 1; bool InspectorUtils : 1; bool MessageChannel : 1; bool Node : 1; bool NodeFilter : 1;+ bool PathUtils : 1; bool Performance : 1; bool PromiseDebugging : 1; bool Range : 1;@@ -2259,6 +2261,9 @@ bool WebSocket : 1; bool Window : 1; bool XMLSerializer : 1;+#ifdef MOZ_DOM_STREAMS+ bool ReadableStream : 1;+#endif // Ad-hoc property names we implement. bool atob : 1;@@ -2266,6 +2271,7 @@ bool caches : 1; bool crypto : 1; bool fetch : 1;+ bool storage : 1; bool structuredClone : 1; bool indexedDB : 1; bool isSecureContext : 1;
Based on the provided diff, I don't see any clear security vulnerabilities being fixed. The changes appear to be feature additions rather than security fixes. Here's the analysis following your requested format: Vulnerability Existed: no Feature Addition [File] js/xpconnect/src/xpcprivate.h [Lines 2243-2271] [Old Code] (bool fields without IOUtils, PathUtils, storage, etc.) [Fixed Code] Added new boolean flags for IOUtils, PathUtils, storage, and ReadableStream Vulnerability Existed: no Feature Addition [File] js/xpconnect/src/xpcprivate.h [Lines 2266-2271] [Old Code] (bool fields without storage) [Fixed Code] Added storage boolean flag Vulnerability Existed: no Feature Addition [File] js/xpconnect/src/xpcprivate.h [Lines 2259-2261] [Old Code] (bool fields without ReadableStream) [Fixed Code] Added ReadableStream boolean flag under MOZ_DOM_STREAMS conditional The changes are simply adding new feature flags to the structure, which is typical for adding new web platform features. There are no obvious security fixes in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/typenum/src/lib.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/typenum/src/lib.rs@@ -59,7 +59,7 @@ ) )] #![cfg_attr(feature = "cargo-clippy", deny(clippy::missing_inline_in_public_items))]-#![doc(html_root_url = "https://docs.rs/typenum/1.14.0")]+#![doc(html_root_url = "https://docs.rs/typenum/1.15.0")] // For debugging macros: // #![feature(trace_macros)]@@ -103,16 +103,19 @@ /// A potential output from `Cmp`, this is the type equivalent to the enum variant /// `core::cmp::Ordering::Greater`. #[derive(Eq, PartialEq, Ord, PartialOrd, Clone, Copy, Hash, Debug, Default)]+#[cfg_attr(feature = "scale_info", derive(scale_info::TypeInfo))] pub struct Greater; /// A potential output from `Cmp`, this is the type equivalent to the enum variant /// `core::cmp::Ordering::Less`. #[derive(Eq, PartialEq, Ord, PartialOrd, Clone, Copy, Hash, Debug, Default)]+#[cfg_attr(feature = "scale_info", derive(scale_info::TypeInfo))] pub struct Less; /// A potential output from `Cmp`, this is the type equivalent to the enum variant /// `core::cmp::Ordering::Equal`. #[derive(Eq, PartialEq, Ord, PartialOrd, Clone, Copy, Hash, Debug, Default)]+#[cfg_attr(feature = "scale_info", derive(scale_info::TypeInfo))] pub struct Equal; /// Returns `core::cmp::Ordering::Greater`
Based on the provided diff, I don't see any security vulnerabilities being fixed. The changes appear to be version updates and feature additions rather than security patches. Here's the analysis:
1. Vulnerability Existed: no
Version Update [File] [Lines 59]
Old Code: #![doc(html_root_url = "https://docs.rs/typenum/1.14.0")]
Fixed Code: #![doc(html_root_url = "https://docs.rs/typenum/1.15.0")]
2. Vulnerability Existed: no
Feature Addition [File] [Lines 103-118]
Old Code: #[derive(Eq, PartialEq, Ord, PartialOrd, Clone, Copy, Hash, Debug, Default)]
Fixed Code: #[derive(Eq, PartialEq, Ord, PartialOrd, Clone, Copy, Hash, Debug, Default)]
#[cfg_attr(feature = "scale_info", derive(scale_info::TypeInfo))]
The changes consist of:
1. Updating the documentation URL to reflect a version bump from 1.14.0 to 1.15.0
2. Adding scale_info::TypeInfo derivation for Greater, Less, and Equal structs when the "scale_info" feature is enabled
Neither of these changes appear to address any security vulnerabilities. They are routine maintenance and feature addition updates.
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-backgrounds/background-clip-004.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-backgrounds/background-clip-004.html@@ -7,7 +7,6 @@ <link rel="reviewer" title="Gérard Talbot" href="http://www.gtalbot.org/BrowserBugsSection/css21testsuite/"> <!-- 2012-11-09 --> <link rel="help" href="http://www.w3.org/TR/css3-background/#the-background-clip" title="3.7. Painting Area: the 'background-clip' property"> <link rel="match" href="reference/background-clip-004-ref.html">- <meta name="flags" content=""> <meta name="assert" content="Background-clip with 'padding-box' implies to paint the background within (clipped to) the padding box."> <style> #test-overlapped-red {
Analyzing the provided code diff for security fixes: 1. Vulnerability Existed: no No specific vulnerability found File: testing/web-platform/tests/css/css-backgrounds/background-clip-004.html Lines: 7 Old Code: `<meta name="flags" content="">` Fixed Code: (line removed) Additional Details: This appears to be a removal of an empty meta tag for test flags, which doesn't indicate any security vulnerability being fixed. It's likely just a cleanup of unnecessary markup. No other vulnerabilities were identified in this diff. The change appears to be a minor HTML cleanup 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/fill-and-stroke-styles/2d.pattern.basic.canvas.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.pattern.basic.canvas.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,15 +29,15 @@ var pattern = ctx.createPattern(offscreenCanvas2, 'no-repeat'); ctx.fillStyle = pattern; ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 50,1, 0,255,0,255, "50,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 1,25, 0,255,0,255, "1,25", "0,255,0,255");-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");-_assertPixel(offscreenCanvas, 98,25, 0,255,0,255, "98,25", "0,255,0,255");-_assertPixel(offscreenCanvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");-_assertPixel(offscreenCanvas, 50,48, 0,255,0,255, "50,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, 50,1, 0,255,0,255, "50,1", "0,255,0,255");+_assertPixel(canvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");+_assertPixel(canvas, 1,25, 0,255,0,255, "1,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 98,25, 0,255,0,255, "98,25", "0,255,0,255");+_assertPixel(canvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");+_assertPixel(canvas, 50,48, 0,255,0,255, "50,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 find any security vulnerabilities. The changes appear to be purely variable name refactoring (from `offscreenCanvas` to `canvas`) and corresponding updates to the assertions. Here's the analysis: 1. Vulnerability Existed: no No security vulnerability found File: testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.pattern.basic.canvas.html Lines: 17-48 Old Code: Used variable name `offscreenCanvas` Fixed Code: Changed variable name to `canvas` The changes are consistent throughout the file, only affecting variable naming and not introducing or fixing any security-related issues. The functionality remains 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/third_party/rust/bitreader/src/lib.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/bitreader/src/lib.rs@@ -50,6 +50,7 @@ cfg_if::cfg_if!{ if #[cfg(feature = "std")] { extern crate std;+ use std::cmp::min; use std::prelude::v1::*; use std::fmt; use std::error::Error;@@ -57,6 +58,7 @@ } else { use core::result; use core::fmt;+ use core::cmp::min; } }@@ -69,6 +71,9 @@ /// Position from the start of the slice, counted as bits instead of bytes position: u64, relative_offset: u64,++ /// Length this reader is allowed to read from the slice, counted as bits instead of bytes.+ length: u64, } impl<'a> BitReader<'a> {@@ -79,6 +84,7 @@ bytes: bytes, position: 0, relative_offset: 0,+ length: bytes.len() as u64 * 8, } }@@ -109,6 +115,45 @@ bytes: self.bytes, position: self.position, relative_offset: self.position,+ length: self.length - self.position,+ }+ }++ /// Returns a copy of current BitReader, with the difference that its position() returns+ /// positions relative to the position of the original BitReader at the construction time, and+ /// will not allow reading more than len bits. After construction, both readers are otherwise + // completely independent, except of course for sharing the same source data.+ ///+ /// ```+ /// use bitreader::BitReader;+ /// use bitreader::BitReaderError;+ ///+ /// let bytes = &[0b11110000, 0b00001111];+ /// let mut original = BitReader::new(bytes);+ /// assert_eq!(original.read_u8(4).unwrap(), 0b1111);+ /// assert_eq!(original.position(), 4);+ ///+ /// let mut relative = original.relative_reader_atmost(8);+ /// assert_eq!(relative.position(), 0);+ ///+ /// assert_eq!(original.read_u8(8).unwrap(), 0);+ /// assert_eq!(relative.read_u8(8).unwrap(), 0);+ ///+ /// assert_eq!(original.position(), 12);+ /// assert_eq!(relative.position(), 8);+ ///+ /// assert_eq!(relative.read_u8(8).unwrap_err(), BitReaderError::NotEnoughData{+ /// position: 8,+ /// length: 8,+ /// requested: 8+ /// });+ /// ```+ pub fn relative_reader_atmost(&self, len: u64) -> BitReader<'a> {+ BitReader {+ bytes: self.bytes,+ position: self.position,+ relative_offset: self.position,+ length: min(self.length - self.position, len), } }@@ -130,9 +175,9 @@ let requested = output_bytes.len() as u64 * 8; if requested > self.remaining() { Err(BitReaderError::NotEnoughData {- position: self.position,- length: (self.bytes.len() * 8) as u64,- requested: requested,+ position: self.position(),+ length: self.length,+ requested, }) } else { for byte in output_bytes.iter_mut() {@@ -221,10 +266,10 @@ /// Skip arbitrary number of bits. However, you can skip at most to the end of the byte slice. pub fn skip(&mut self, bit_count: u64) -> Result<()> { let end_position = self.position + bit_count;- if end_position > self.bytes.len() as u64 * 8 {+ if end_position > (self.relative_offset + self.length) { return Err(BitReaderError::NotEnoughData {- position: self.position,- length: (self.bytes.len() * 8) as u64,+ position: self.position(),+ length: self.length, requested: bit_count, }); }@@ -239,8 +284,7 @@ /// Returns the number of bits not yet read from the underlying slice. pub fn remaining(&self) -> u64 {- let total_bits = self.bytes.len() as u64 * 8;- total_bits - self.position+ self.length - self.position } /// Helper to make sure the "bit cursor" is exactly at the beginning of a byte, or at specific@@ -291,10 +335,10 @@ } let start_position = self.position; let end_position = self.position + bit_count as u64;- if end_position > self.bytes.len() as u64 * 8 {+ if end_position > (self.relative_offset + self.length) { return Err(BitReaderError::NotEnoughData {- position: self.position,- length: (self.bytes.len() * 8) as u64,+ position: self.position(),+ length: self.length, requested: bit_count as u64, }); }@@ -322,8 +366,13 @@ pub enum BitReaderError { /// Requested more bits than there are left in the byte slice at the current position. NotEnoughData {+ /// Current posititon in bits relative to the beginning of the reader. position: u64,++ /// Total readable length in bits of the underlaying slice. length: u64,++ /// Bits requested to be read. requested: u64, }, /// Requested more bits than the returned variable can hold, for example more than 8 bits when
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: yes Buffer Overflow Prevention [File] third_party/rust/bitreader/src/lib.rs [Lines] 69, 79, 84, 115, 130-134, 221-226, 266-270, 291-296, 335-340 [Old Code] The original code calculated remaining bits based solely on the byte slice length without any bounds checking against a maximum allowed length. Various operations could potentially read beyond intended boundaries. [Fixed Code] Added a `length` field to track allowed read length in bits. Modified all operations to check against this length rather than just the byte slice length. Added `min()` operations to prevent overflows. 2. Vulnerability Existed: yes Integer Overflow Prevention [File] third_party/rust/bitreader/src/lib.rs [Lines] 130-134, 221-226, 266-270, 291-296, 335-340 [Old Code] Calculations like `self.bytes.len() * 8` could potentially overflow if the slice length was very large. [Fixed Code] Replaced with bounded length checks using the new `length` field and `min()` operations to prevent integer overflows. 3. Vulnerability Existed: not sure Potential Information Leak [File] third_party/rust/bitreader/src/lib.rs [Lines] 115-148 [Old Code] No explicit bounds checking in relative reader creation. [Fixed Code] Added `relative_reader_atmost()` with explicit length limiting to prevent potential information leaks through unbounded relative readers. The main security improvements appear to be: 1) Adding bounds checking to prevent buffer overflows 2) Preventing integer overflows in bit position calculations 3) Adding explicit length limits for relative readers The changes introduce a length tracking mechanism and consistently use it for bounds checking throughout the reader operations, significantly improving the security of the bit reading operations.
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/intl/lwbrk/LineBreaker.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/intl/lwbrk/LineBreaker.cpp@@ -400,10 +400,10 @@ /* BREAK_BEFORE = 5, [BB] */ CLASS_OPEN_LIKE_CHARACTER, /* MANDATORY_BREAK = 6, [BK] */ CLASS_CHARACTER, /* CONTINGENT_BREAK = 7, [CB] */ CLASS_CHARACTER,- /* CLOSE_PUNCTUATION = 8, [CL] */ CLASS_CHARACTER,+ /* CLOSE_PUNCTUATION = 8, [CL] */ CLASS_CLOSE_LIKE_CHARACTER, /* COMBINING_MARK = 9, [CM] */ CLASS_CHARACTER, /* CARRIAGE_RETURN = 10, [CR] */ CLASS_BREAKABLE,- /* EXCLAMATION = 11, [EX] */ CLASS_CHARACTER,+ /* EXCLAMATION = 11, [EX] */ CLASS_CLOSE_LIKE_CHARACTER, /* GLUE = 12, [GL] */ CLASS_NON_BREAKABLE, /* HYPHEN = 13, [HY] */ CLASS_CHARACTER, /* IDEOGRAPHIC = 14, [ID] */ CLASS_BREAKABLE,@@ -412,8 +412,8 @@ /* LINE_FEED = 17, [LF] */ CLASS_BREAKABLE, /* NONSTARTER = 18, [NS] */ CLASS_CLOSE_LIKE_CHARACTER, /* NUMERIC = 19, [NU] */ CLASS_NUMERIC,- /* OPEN_PUNCTUATION = 20, [OP] */ CLASS_CHARACTER,- /* POSTFIX_NUMERIC = 21, [PO] */ CLASS_CHARACTER,+ /* OPEN_PUNCTUATION = 20, [OP] */ CLASS_OPEN_LIKE_CHARACTER,+ /* POSTFIX_NUMERIC = 21, [PO] */ CLASS_CLOSE_LIKE_CHARACTER, /* PREFIX_NUMERIC = 22, [PR] */ CLASS_CHARACTER, /* QUOTATION = 23, [QU] */ CLASS_CHARACTER, /* COMPLEX_CONTEXT = 24, [SA] */ CLASS_CHARACTER,@@ -564,20 +564,10 @@ } if (0xff00 == h) { if (l <= 0x0060) { // Fullwidth ASCII variant- // Fullwidth comma and period are exceptions to our map-to-ASCII- // behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=1595428- if (l + 0x20 == ',' || l + 0x20 == '.') {- return CLASS_CLOSE;- }- // Also special-case fullwidth left/right white parenthesis,- // which do not fit the pattern of mapping to the ASCII block- if (l == 0x005f) {- return CLASS_OPEN;- }- if (l == 0x0060) {- return CLASS_CLOSE;- }- return GETCLASSFROMTABLE(gLBClass00, (l + 0x20));+ // Previously, we treated Fullwidth chars the same as their ASCII+ // counterparts, but UAX#14 (LineBreak.txt) disagrees with this and+ // treats many of them as ideograph-like.+ return sUnicodeLineBreakToClass[cls]; } if (l < 0x00a0) { // Halfwidth Katakana variants switch (l) {@@ -1090,10 +1080,10 @@ if (aWordBreak == WordBreakRule::BreakAll) { // For break-all, we don't need to run a dictionary-based breaking // algorithm, we just allow breaks between all grapheme clusters.- ClusterIterator ci(aChars + cur, end - cur);- while (!ci.AtEnd()) {- ci.Next();- aBreakBefore[ci - aChars] = true;+ GraphemeClusterBreakIteratorUtf16 ci(+ Span<const char16_t>(aChars + cur, end - cur));+ while (Maybe<uint32_t> pos = ci.Next()) {+ aBreakBefore[cur + *pos] = true; } } else { ComplexBreaker::GetBreaks(aChars + cur, end - cur, aBreakBefore + cur);
Analyzing the provided code diff for security fixes:
1. Vulnerability Existed: not sure
[Potential Unicode Line Break Handling Issue] [intl/lwbrk/LineBreaker.cpp] [Lines 564-574]
[Old Code]
```
if (0xff00 == h) {
if (l <= 0x0060) { // Fullwidth ASCII variant
// Fullwidth comma and period are exceptions to our map-to-ASCII
// behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=1595428
if (l + 0x20 == ',' || l + 0x20 == '.') {
return CLASS_CLOSE;
}
// Also special-case fullwidth left/right white parenthesis,
// which do not fit the pattern of mapping to the ASCII block
if (l == 0x005f) {
return CLASS_OPEN;
}
if (l == 0x0060) {
return CLASS_CLOSE;
}
return GETCLASSFROMTABLE(gLBClass00, (l + 0x20));
```
[Fixed Code]
```
if (0xff00 == h) {
if (l <= 0x0060) { // Fullwidth ASCII variant
// Previously, we treated Fullwidth chars the same as their ASCII
// counterparts, but UAX#14 (LineBreak.txt) disagrees with this and
// treats many of them as ideograph-like.
return sUnicodeLineBreakToClass[cls];
```
2. Vulnerability Existed: not sure
[Potential Grapheme Cluster Handling Issue] [intl/lwbrk/LineBreaker.cpp] [Lines 1090-1096]
[Old Code]
```
ClusterIterator ci(aChars + cur, end - cur);
while (!ci.AtEnd()) {
ci.Next();
aBreakBefore[ci - aChars] = true;
}
```
[Fixed Code]
```
GraphemeClusterBreakIteratorUtf16 ci(
Span<const char16_t>(aChars + cur, end - cur));
while (Maybe<uint32_t> pos = ci.Next()) {
aBreakBefore[cur + *pos] = true;
}
```
3. Vulnerability Existed: not sure
[Potential Line Break Classification Issue] [intl/lwbrk/LineBreaker.cpp] [Lines 400-423]
[Old Code]
```
/* CLOSE_PUNCTUATION = 8, [CL] */ CLASS_CHARACTER,
/* EXCLAMATION = 11, [EX] */ CLASS_CHARACTER,
/* OPEN_PUNCTUATION = 20, [OP] */ CLASS_CHARACTER,
/* POSTFIX_NUMERIC = 21, [PO] */ CLASS_CHARACTER,
```
[Fixed Code]
```
/* CLOSE_PUNCTUATION = 8, [CL] */ CLASS_CLOSE_LIKE_CHARACTER,
/* EXCLAMATION = 11, [EX] */ CLASS_CLOSE_LIKE_CHARACTER,
/* OPEN_PUNCTUATION = 20, [OP] */ CLASS_OPEN_LIKE_CHARACTER,
/* POSTFIX_NUMERIC = 21, [PO] */ CLASS_CLOSE_LIKE_CHARACTER,
```
Note: While these changes appear to be correctness fixes related to Unicode line breaking behavior and grapheme cluster handling, I cannot definitively determine if they were addressing security vulnerabilities or just general correctness issues. The changes align better with Unicode standards (UAX#14) and improve grapheme cluster handling, which could potentially affect security-sensitive text processing scenarios.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp@@ -878,4 +878,57 @@ return policy; }+/* static */ UniquePtr<SandboxBroker::Policy>+SandboxBrokerPolicyFactory::GetUtilityProcessPolicy(int aPid) {+ auto policy = MakeUnique<SandboxBroker::Policy>();++ policy->AddPath(rdonly, "/dev/urandom");+ policy->AddPath(rdonly, "/proc/cpuinfo");+ policy->AddPath(rdonly, "/proc/meminfo");+ policy->AddDir(rdonly, "/sys/devices/cpu");+ policy->AddDir(rdonly, "/sys/devices/system/cpu");+ policy->AddDir(rdonly, "/lib");+ policy->AddDir(rdonly, "/lib64");+ policy->AddDir(rdonly, "/usr/lib");+ policy->AddDir(rdonly, "/usr/lib32");+ policy->AddDir(rdonly, "/usr/lib64");+ policy->AddDir(rdonly, "/usr/share");+ policy->AddDir(rdonly, "/usr/local/share");+ policy->AddDir(rdonly, "/etc");++ // glibc will try to stat64("/") while populating nsswitch database+ // https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/nss_database.c;h=cf0306adc47f12d9bc761ab1b013629f4482b7e6;hb=9826b03b747b841f5fc6de2054bf1ef3f5c4bdf3#l396+ // denying will make getaddrinfo() return ENONAME+ policy->AddDir(access, "/");++ AddLdconfigPaths(policy.get());++ // Utility process sandbox needs to allow shmem in order to support+ // profiling. See Bug 1626385.+ AddSharedMemoryPaths(policy.get(), aPid);++ // Bug 1647957: memory reporting.+ AddMemoryReporting(policy.get(), aPid);++ // Firefox binary dir.+ // Note that unlike the previous cases, we use NS_GetSpecialDirectory+ // instead of GetSpecialSystemDirectory. The former requires a working XPCOM+ // system, which may not be the case for some tests. For querying for the+ // location of XPCOM things, we can use it anyway.+ nsCOMPtr<nsIFile> ffDir;+ nsresult rv = NS_GetSpecialDirectory(NS_GRE_DIR, getter_AddRefs(ffDir));+ if (NS_SUCCEEDED(rv)) {+ nsAutoCString tmpPath;+ rv = ffDir->GetNativePath(tmpPath);+ if (NS_SUCCEEDED(rv)) {+ policy->AddDir(rdonly, tmpPath.get());+ }+ }++ if (policy->IsEmpty()) {+ policy = nullptr;+ }+ return policy;+}+ } // namespace mozilla
Based on the provided code diff, I'll analyze it for security vulnerabilities: 1. Vulnerability Existed: not sure [Potential Path Access Control Vulnerability] [security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp] [Lines 878-931] [Old Code: No utility process policy existed] [Fixed Code: Added GetUtilityProcessPolicy with specific path access controls] 2. Vulnerability Existed: not sure [Potential Information Disclosure Vulnerability] [security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp] [Lines 881-887] [Old Code: No access to system files] [Fixed Code: Added read-only access to /proc/cpuinfo, /proc/meminfo, and other system files] 3. Vulnerability Existed: not sure [Potential Shared Memory Vulnerability] [security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp] [Lines 896-897] [Old Code: No shared memory access] [Fixed Code: Added shared memory paths for profiling support] Note: The changes appear to be adding new functionality (utility process sandbox policy) rather than fixing existing vulnerabilities. The security implications are: 1. The new policy carefully controls access to system resources (read-only where appropriate) 2. It adds necessary access for specific features (profiling, memory reporting) 3. It maintains security by using the sandbox broker pattern to restrict access Without seeing the actual vulnerabilities being fixed (just new code being added), I can't definitively say these are security fixes, but the changes do implement security controls for a new feature.
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/wasm/WasmOpIter.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/wasm/WasmOpIter.h@@ -721,6 +721,9 @@ // end of the function body. bool controlStackEmpty() const { return controlStack_.empty(); }+ // Return the depth of the control stack.+ size_t controlStackDepth() const { return controlStack_.length(); }+ // Find the innermost control item of a specific kind, starting to search from // a certain relative depth, and returning true if such innermost control item // is found. The relative depth of the found item is returned via a parameter.
Analyzing the provided code diff, here's the security analysis:
Vulnerability Existed: not sure
[Potential Stack Depth Information Leak] [js/src/wasm/WasmOpIter.h] [Lines 721-724]
[Old Code]
bool controlStackEmpty() const { return controlStack_.empty(); }
[Fixed Code]
bool controlStackEmpty() const { return controlStack_.empty(); }
// Return the depth of the control stack.
size_t controlStackDepth() const { return controlStack_.length(); }
Additional Details:
The diff adds a new method `controlStackDepth()` that exposes the length of the control stack. While this isn't a direct vulnerability, exposing stack depth information could potentially be used in some attack scenarios where an attacker might use stack depth information to guide an exploit. However, without more context about how this information is used, it's difficult to determine if this constitutes an actual security vulnerability. The change appears to be adding functionality rather than fixing a specific security issue.
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/widget/gtk/DMABufLibWrapper.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/widget/gtk/DMABufLibWrapper.h@@ -29,6 +29,7 @@ namespace widget { typedef struct gbm_device* (*CreateDeviceFunc)(int);+typedef void (*DestroyDeviceFunc)(struct gbm_device*); typedef struct gbm_bo* (*CreateFunc)(struct gbm_device*, uint32_t, uint32_t, uint32_t, uint32_t); typedef struct gbm_bo* (*CreateWithModifiersFunc)(struct gbm_device*, uint32_t,@@ -61,6 +62,10 @@ StaticMutexAutoLock lockDRI(sDRILock); return sCreateDevice(fd); };+ static void DestroyDevice(struct gbm_device* gdm) {+ StaticMutexAutoLock lockDRI(sDRILock);+ return sDestroyDevice(gdm);+ }; static struct gbm_bo* Create(struct gbm_device* gbm, uint32_t width, uint32_t height, uint32_t format, uint32_t flags) {@@ -130,6 +135,7 @@ private: static CreateDeviceFunc sCreateDevice;+ static DestroyDeviceFunc sDestroyDevice; static CreateFunc sCreate; static CreateWithModifiersFunc sCreateWithModifiers; static GetModifierFunc sGetModifier;@@ -162,21 +168,19 @@ class nsDMABufDevice { public: nsDMABufDevice();+ ~nsDMABufDevice(); gbm_device* GetGbmDevice();- // Returns -1 if we fails to gbm device file descriptor.- int GetGbmDeviceFd(); // Use dmabuf for WebRender general web content bool IsDMABufTexturesEnabled();- // Use dmabuf for video playback- bool IsDMABufVideoEnabled(); // Use dmabuf for VA-API video playback bool IsDMABufVAAPIEnabled(); // Use dmabuf for WebGL content bool IsDMABufWebGLEnabled(); void DisableDMABufWebGL();+ int GetDRMFd(); GbmFormat* GetGbmFormat(bool aHasAlpha); GbmFormat* GetExactGbmFormat(int aFormat); void ResetFormatsModifiers();@@ -193,8 +197,8 @@ GbmFormat mXRGBFormat; GbmFormat mARGBFormat;+ int mDRMFd; gbm_device* mGbmDevice;- int mGbmFd; bool mInitialized; };
Here's the analysis of the provided code diff following the specified format: 1. Vulnerability Existed: not sure [Potential Resource Leak] [widget/gtk/DMABufLibWrapper.h] [Lines 29,61,130,135,168,193,197] [Old Code] - No explicit destruction function for gbm_device - No destructor for nsDMABufDevice class - mGbmDevice and mGbmFd members managed separately [Fixed Code] - Added DestroyDeviceFunc typedef and sDestroyDevice member - Added destructor for nsDMABufDevice class - Replaced mGbmFd with mDRMFd and removed GetGbmDeviceFd() - Added proper device destruction capability 2. Vulnerability Existed: not sure [Potential File Descriptor Leak] [widget/gtk/DMABufLibWrapper.h] [Lines 168,193,197] [Old Code] - Separate mGbmFd member that could potentially leak - No clear ownership of file descriptors [Fixed Code] - Removed mGbmFd member - Added GetDRMFd() method - Better encapsulation of file descriptor management 3. Vulnerability Existed: not sure [Potential Race Condition] [widget/gtk/DMABufLibWrapper.h] [Lines 61,62] [Old Code] - Only CreateDevice had mutex protection [Fixed Code] - Added mutex protection for DestroyDevice function - More consistent thread safety Note: While these changes appear to improve resource management and thread safety, without more context about the actual usage patterns, we can't be certain if these were fixing actual vulnerabilities or just improving code quality. The changes suggest potential issues with resource leaks and thread safety were addressed.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.gradient.basic.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.gradient.basic.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 gradient = ctx.createLinearGradient(0, 0, 100, 0); gradient.addColorStop(0, '#f00');@@ -29,7 +29,7 @@ ctx.shadowOffsetY = 50; ctx.fillStyle = gradient; ctx.fillRect(0, -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 diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming without any security implications. Here's the analysis:
Vulnerability Existed: no
No vulnerability found [File] [Lines 17-18, 29]
[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 from `offscreenCanvas` to `canvas` for consistency or readability purposes. There are no security-related modifications in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.transform.2.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.transform.2.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -22,7 +22,7 @@ ctx.shadowColor = '#0f0'; ctx.rotate(Math.PI) ctx.fillRect(-100, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });
Based on the provided diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming and don't affect security. Here's the analysis:
1. Vulnerability Existed: no
Variable Renaming [File] [Lines 13-14, 22]
[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` for consistency or clarity, but this doesn't represent a security fix. No security vulnerabilities were addressed in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/devtools/client/inspector/rules/test/browser_rules_media-queries.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/inspector/rules/test/browser_rules_media-queries.js@@ -3,8 +3,7 @@ "use strict";-// Tests that we correctly display appropriate media query titles in the-// rule view.+// Tests that we correctly display appropriate media query information in the rule view. const TEST_URI = URL_ROOT + "doc_media_queries.html";@@ -19,10 +18,12 @@ is(elementStyle.rules.length, 3, "Should have 3 rules."); is(elementStyle.rules[0].title, inline, "check rule 0 title");+ is(elementStyle.rules[1].title, inline + ":9", "check rule 1 title");+ is(elementStyle.rules[2].title, inline + ":2", "check rule 2 title");+ is(- elementStyle.rules[1].title,- inline + ":9 @media screen and (min-width: 1px)",- "check rule 1 title"+ getRuleViewAncestorRulesDataTextByIndex(view, 1),+ "@media screen and (min-width: 1px)",+ "Media queries information are displayed" );- is(elementStyle.rules[2].title, inline + ":2", "check rule 2 title"); });
Based on the provided diff, this appears to be a test file modification rather than a security fix. Here's the analysis following your requested format: Vulnerability Existed: no No security vulnerability found [File] devtools/client/inspector/rules/test/browser_rules_media-queries.js [Lines] 3-23 [Old Code] // Tests that we correctly display appropriate media query titles in the // rule view. ... is(elementStyle.rules[1].title, inline + ":9 @media screen and (min-width: 1px)", "check rule 1 title" ); [Fixed Code] // Tests that we correctly display appropriate media query information in the rule view. ... is(elementStyle.rules[1].title, inline + ":9", "check rule 1 title"); is(elementStyle.rules[2].title, inline + ":2", "check rule 2 title"); is( getRuleViewAncestorRulesDataTextByIndex(view, 1), "@media screen and (min-width: 1px)", "Media queries information are displayed" ); The changes appear to be: 1. Updating test comments to be more accurate 2. Refactoring how media query information is tested (splitting the test into separate assertions) 3. Using a different method (getRuleViewAncestorRulesDataTextByIndex) to verify media query information No security vulnerabilities were identified in this change - it's purely a test improvement/refactoring.
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.