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/gfx/2d/Swizzle.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/gfx/2d/Swizzle.h@@ -47,6 +47,27 @@ const IntSize& aSize); /**+ * Flips rows of source and swizzles it to destination. Source and destination+ * may be the same to swizzle in-place; this will fail if it cannot allocate a+ * temporary buffer.+ */+GFX2D_API bool SwizzleYFlipData(const uint8_t* aSrc, int32_t aSrcStride,+ SurfaceFormat aSrcFormat, uint8_t* aDst,+ int32_t aDstStride, SurfaceFormat aDstFormat,+ const IntSize& aSize);++/**+ * Flips rows of source and premultiplies/swizzles it to destination. Source and+ * destination may be the same to premultiply/swizzle in-place; this will fail+ * if it cannot allocate a temporary buffer.+ */+GFX2D_API bool PremultiplyYFlipData(const uint8_t* aSrc, int32_t aSrcStride,+ SurfaceFormat aSrcFormat, uint8_t* aDst,+ int32_t aDstStride,+ SurfaceFormat aDstFormat,+ const IntSize& aSize);++/** * Swizzles source and writes it to destination. Source and destination may be * the same to swizzle in-place. */
Based on the provided diff, I don't see any clear security vulnerabilities being fixed. The changes appear to be adding new functionality (YFlip operations) rather than fixing existing security issues. Here's the analysis following your requested format: Vulnerability Existed: no No security vulnerability found in diff [File] gfx/2d/Swizzle.h [Lines] 47-69 [Old Code] (No previous functions for YFlip operations) [Fixed Code] Added new functions: - SwizzleYFlipData() - PremultiplyYFlipData() The changes are purely additive functionality for image manipulation operations (flipping and swizzling/premultiplying), with proper documentation about potential allocation failures. There are no apparent 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/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.invalidstring.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.invalidstring.worker.js@@ -13,15 +13,15 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50); ctx.fillStyle = '#0f0'; ctx.fillStyle = 'invalid'; 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 fixes: 1. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.invalidstring.worker.js [Lines] 13-23 [Old Code] ```javascript 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] ```javascript 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"); ``` Additional Details: The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) with no security implications. The test logic remains the same, just with more consistent variable naming. This appears to be a code style/consistency change rather than a security fix. The test continues to verify the same behavior (that invalid fillStyle values don't affect the previously set valid value).
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/async-task/tests/join.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/async-task/tests/join.rs@@ -82,7 +82,7 @@ let guard = Guard(Box::new(0)); move |runnable: Runnable| {- &guard;+ let _ = &guard; runnable.schedule(); $sched.fetch_add(1, Ordering::SeqCst); }
Let me analyze the code diff for security fixes. Vulnerability Existed: not sure [Potential Resource Leak or Drop Order Issue] [third_party/rust/async-task/tests/join.rs] [Lines 82-86] [Old Code] let guard = Guard(Box::new(0)); move |runnable: Runnable| { &guard; runnable.schedule(); $sched.fetch_add(1, Ordering::SeqCst); } [Fixed Code] let guard = Guard(Box::new(0)); move |runnable: Runnable| { let _ = &guard; runnable.schedule(); $sched.fetch_add(1, Ordering::SeqCst); } Additional Details: The change appears to be related to how a guard reference is handled in a closure. The original code had a bare reference `&guard` which might be optimized away by the compiler, potentially causing the guard to be dropped earlier than intended. The fixed code explicitly binds the reference to `_` to ensure it's kept alive throughout the closure execution. While this doesn't appear to be a direct security vulnerability, it could potentially lead to resource management issues if the guard's lifetime is critical for safety.
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/generic/DocAccessible.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/accessible/generic/DocAccessible.h@@ -110,6 +110,17 @@ * Return DOM document type. */ void DocType(nsAString& aType) const;++ /**+ * Adds an entry to mQueuedCacheUpdates indicating aAcc requires+ * a cache update on domain aNewDomain. If we've already queued an update+ * for aAcc, aNewDomain is or'd with the existing domain(s)+ * and the map is updated. Otherwise, the entry is simply inserted.+ * This function also schedules processing on the controller.+ * Note that this CANNOT be used for anything which fires events, since events+ * must be fired after their associated cache update.+ */+ void QueueCacheUpdate(LocalAccessible* aAcc, uint64_t aNewDomain); /** * Return virtual cursor associated with the document.@@ -336,17 +347,15 @@ void ContentInserted(nsIContent* aStartChildNode, nsIContent* aEndChildNode); /**+ * @see nsAccessibilityService::ScheduleAccessibilitySubtreeUpdate+ */+ void ScheduleTreeUpdate(nsIContent* aContent);++ /** * Update the tree on content removal. */ void ContentRemoved(LocalAccessible* aAccessible); void ContentRemoved(nsIContent* aContentNode);-- /*- * Add the given accessible to mMaybeBoundsChanged so we- * can (later) check if its bounds have changed, and update- * the cache appropriately.- */- void MarkForBoundsProcessing(LocalAccessible* aAcc); /** * Updates accessible tree when rendered text is changed.@@ -491,12 +500,20 @@ void ProcessInvalidationList(); /**+ * Process mPendingUpdates+ */+ void ProcessPendingUpdates();++ /** * Called from NotificationController to process this doc's- * mMaybeBoundsChanged list. Sends a cache update for each acc in this- * doc whose bounds have changed since reflow.- */- void ProcessBoundsChanged();-+ * mQueuedCacheUpdates list. For each acc in the map, this function+ * sends a cache update with its corresponding CacheDomain.+ */+ void ProcessQueuedCacheUpdates();++ /**+ * Only works in content process documents.+ */ bool IsAccessibleBeingMoved(LocalAccessible* aAcc) { return mMovedAccessibles.Contains(aAcc); }@@ -719,6 +736,11 @@ mARIAOwnsHash; /**+ * Keeps a list of pending subtrees to update post-refresh.+ */+ nsTArray<RefPtr<nsIContent>> mPendingUpdates;++ /** * Used to process notification from core and accessible events. */ RefPtr<NotificationController> mNotificationController;@@ -729,8 +751,8 @@ void SetRoleMapEntryForDoc(dom::Element* aElement); /**- * This must be called whenever an Accessible is moved if the cache is- * enabled. It keeps track of Accessibles moved during this tick.+ * This must be called whenever an Accessible is moved in a content process.+ * It keeps track of Accessibles moved during this tick. */ void TrackMovedAccessible(LocalAccessible* aAcc);@@ -740,11 +762,17 @@ DocAccessibleChild* mIPCDoc; nsTHashSet<RefPtr<LocalAccessible>> mMaybeBoundsChanged;- // A set of Accessibles moved during this tick. Only used if the cache is- // enabled.++ // A hash map between LocalAccessibles and CacheDomains, tracking+ // cache updates that have been queued during the current tick+ // but not yet sent.+ nsTHashMap<RefPtr<LocalAccessible>, uint64_t> mQueuedCacheUpdates;++ // A set of Accessibles moved during this tick. Only used in content+ // processes. nsTHashSet<RefPtr<LocalAccessible>> mMovedAccessibles;- // A set of Accessibles inserted during this tick. Only used if the cache is- // enabled. This is needed to prevent insertions + moves of the same+ // A set of Accessibles inserted during this tick. Only used in content+ // processes. This is needed to prevent insertions + moves of the same // Accessible in the same tick from being tracked as moves. nsTHashSet<RefPtr<LocalAccessible>> mInsertedAccessibles; };
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: not sure [Cache Update Management] [accessible/generic/DocAccessible.h] [Lines 110, 336-354, 491-502, 719-743] [Old Code] Uses mMaybeBoundsChanged and ProcessBoundsChanged() for bounds processing [Fixed Code] Introduces mQueuedCacheUpdates and ProcessQueuedCacheUpdates() for more comprehensive cache update management 2. Vulnerability Existed: not sure [Accessible Tree Update Management] [accessible/generic/DocAccessible.h] [Lines 336-354, 719] [Old Code] No explicit handling of pending subtree updates [Fixed Code] Adds mPendingUpdates array and ScheduleTreeUpdate() function for better subtree update management 3. Vulnerability Existed: not sure [Documentation Clarification] [accessible/generic/DocAccessible.h] [Lines 491-502, 719-743] [Old Code] Unclear documentation about cache-related functionality and process boundaries [Fixed Code] Added clearer documentation about content process limitations and cache update behavior The changes appear to be primarily architectural improvements rather than direct security fixes, but they could potentially prevent race conditions or inconsistent state issues in accessibility handling. The main changes involve: 1. Replacing the bounds-specific tracking with a more general cache update queuing system 2. Adding explicit handling for pending subtree updates 3. Clarifying documentation about process boundaries and update behavior While these changes improve robustness, I couldn't identify any specific, named vulnerabilities being addressed. The modifications seem focused on improving maintainability and correctness of the accessibility cache update system.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/pixel-manipulation/2d.imageData.put.wrongtype.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/pixel-manipulation/2d.imageData.put.wrongtype.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); var imgdata = { width: 1, height: 1, data: [255, 0, 0, 255] }; assert_throws_js(TypeError, function() { ctx.putImageData(imgdata, 0, 0); });
Analyzing the provided code diff for security fixes: 1. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/pixel-manipulation/2d.imageData.put.wrongtype.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 Details: - The change appears to be a simple variable renaming from `offscreenCanvas` to `canvas` - The functionality remains exactly the same - No security implications are visible in this change - The test continues to verify that putImageData throws a TypeError when given incorrect input types
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/proc-macro2/build.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/proc-macro2/build.rs@@ -58,7 +58,8 @@ process::exit(1); }- let semver_exempt = cfg!(procmacro2_semver_exempt);+ let docs_rs = env::var_os("DOCS_RS").is_some();+ let semver_exempt = cfg!(procmacro2_semver_exempt) || docs_rs; if semver_exempt { // https://github.com/dtolnay/proc-macro2/issues/147 println!("cargo:rustc-cfg=procmacro2_semver_exempt");
Here's the analysis of the provided code diff: Vulnerability Existed: not sure Potential Information Leak or Insecure Configuration [File] third_party/rust/proc-macro2/build.rs [Lines] 58 [Old Code] `let semver_exempt = cfg!(procmacro2_semver_exempt);` [Fixed Code] `let docs_rs = env::var_os("DOCS_RS").is_some();` `let semver_exempt = cfg!(procmacro2_semver_exempt) || docs_rs;` Additional Details: The change introduces a new condition (`docs_rs`) that affects when the `procmacro2_semver_exempt` configuration flag is set. While this doesn't appear to be a direct security vulnerability, it could potentially affect security-related behavior if: 1. The `DOCS_RS` environment variable can be manipulated by an attacker 2. The `semver_exempt` flag affects security-critical functionality Without more context about how this flag is used, it's difficult to determine if this constitutes a security fix or just a functional change. The comment references issue #147 which might provide more context about the security implications.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/netwerk/test/perf/perftest_http3_cloudflareblog.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/netwerk/test/perf/perftest_http3_cloudflareblog.js@@ -4,7 +4,7 @@ /* eslint-env node */ /*-Ensure the `--firefox.preference=network.http.http3.enabled:true` is+Ensure the `--firefox.preference=network.http.http3.enable:true` is set for this test. */
Based on the provided diff, I'll analyze it for security vulnerabilities: 1. Vulnerability Existed: no Preference Name Change [netwerk/test/perf/perftest_http3_cloudflareblog.js] [Lines 4] Old Code: `Ensure the \`--firefox.preference=network.http.http3.enabled:true\` is` Fixed Code: `Ensure the \`--firefox.preference=network.http.http3.enable:true\` is` Additional Details: - This appears to be a simple change in a preference name from "network.http.http3.enabled" to "network.http.http3.enable" - The change is in a test file comment, not in actual executable code - No security vulnerability is apparent in this change, just a correction of a preference name in documentation - The change doesn't indicate any security fix, just a configuration note update for testing HTTP3 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/geckodriver/src/marionette.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/geckodriver/src/marionette.rs@@ -37,6 +37,8 @@ use std::sync::Mutex; use std::thread; use std::time;+use url::{Host, Url};+use webdriver::capabilities::BrowserCapabilities; use webdriver::command::WebDriverCommand::{ AcceptAlert, AddCookie, CloseWindow, DeleteCookie, DeleteCookies, DeleteSession, DismissAlert, ElementClear, ElementClick, ElementSendKeys, ExecuteAsyncScript, ExecuteScript, Extension,@@ -83,6 +85,8 @@ pub(crate) host: String, pub(crate) port: Option<u16>, pub(crate) websocket_port: u16,+ pub(crate) allow_hosts: Vec<Host>,+ pub(crate) allow_origins: Vec<Url>, /// Brings up the Browser Toolbox when starting Firefox, /// letting you debug internals.@@ -110,8 +114,8 @@ session_id: Option<String>, new_session_parameters: &NewSessionParameters, ) -> WebDriverResult<MarionetteConnection> {+ let mut fx_capabilities = FirefoxCapabilities::new(self.settings.binary.as_ref()); let (capabilities, options) = {- let mut fx_capabilities = FirefoxCapabilities::new(self.settings.binary.as_ref()); let mut capabilities = new_session_parameters .match_browser(&mut fx_capabilities)? .ok_or_else(|| {@@ -122,7 +126,7 @@ })?; let options = FirefoxOptions::from_capabilities(- fx_capabilities.chosen_binary,+ fx_capabilities.chosen_binary.clone(), &self.settings, &mut capabilities, )?;@@ -134,14 +138,38 @@ } let marionette_host = self.settings.host.to_owned();- let marionette_port = self- .settings- .port- .unwrap_or(get_free_port(&marionette_host)?);-- let websocket_port = match options.use_websocket {- true => Some(self.settings.websocket_port),- false => None,+ let marionette_port = match self.settings.port {+ Some(port) => port,+ None => {+ // If we're launching Firefox Desktop version 95 or later, and there's no port+ // specified, we can pass 0 as the port and later read it back from+ // the profile.+ let can_use_profile: bool = options.android.is_none()+ && !self.settings.connect_existing+ && fx_capabilities+ .browser_version(&capabilities)+ .map(|opt_v| {+ opt_v+ .map(|v| {+ fx_capabilities+ .compare_browser_version(&v, ">=95")+ .unwrap_or(false)+ })+ .unwrap_or(false)+ })+ .unwrap_or(false);+ if can_use_profile {+ 0+ } else {+ get_free_port(&marionette_host)?+ }+ }+ };++ let websocket_port = if options.use_websocket {+ Some(self.settings.websocket_port)+ } else {+ None }; let browser = if options.android.is_some() {@@ -159,18 +187,22 @@ options, marionette_port, websocket_port,+ self.settings.allow_hosts.to_owned(),+ self.settings.allow_origins.to_owned(), )?) } else if !self.settings.connect_existing { Browser::Local(LocalBrowser::new( options, marionette_port,+ self.settings.allow_hosts.to_owned(),+ self.settings.allow_origins.to_owned(), self.settings.jsdebugger, )?) } else {- Browser::Existing+ Browser::Existing(marionette_port) }; let session = MarionetteSession::new(session_id, capabilities);- MarionetteConnection::new(marionette_host, marionette_port, browser, session)+ MarionetteConnection::new(marionette_host, browser, session) } fn close_connection(&mut self, wait_for_shutdown: bool) {@@ -430,13 +462,10 @@ "Failed to interpret script timeout duration as u64" ), };- // Check for the spec-compliant "pageLoad", but also for "page load",- // which was sent by Firefox 52 and earlier. let page_load = try_opt!( try_opt!( resp.result- .get("pageLoad")- .or_else(|| resp.result.get("page load")),+ .get("pageLoad"), ErrorStatus::UnknownError, "Missing field: pageLoad" )@@ -740,7 +769,7 @@ flags: vec![AppStatus::eForceQuit], }, )),- Browser::Existing => Some(Command::WebDriver(+ Browser::Existing(_) => Some(Command::WebDriver( MarionetteWebDriverCommand::DeleteSession, )), },@@ -1101,11 +1130,10 @@ impl MarionetteConnection { fn new( host: String,- port: u16, mut browser: Browser, session: MarionetteSession, ) -> WebDriverResult<MarionetteConnection> {- let stream = match MarionetteConnection::connect(&host, port, &mut browser) {+ let stream = match MarionetteConnection::connect(&host, &mut browser) { Ok(stream) => stream, Err(e) => { if let Err(e) = browser.close(true) {@@ -1121,16 +1149,15 @@ }) }- fn connect(host: &str, port: u16, browser: &mut Browser) -> WebDriverResult<TcpStream> {+ fn connect(host: &str, browser: &mut Browser) -> WebDriverResult<TcpStream> { let timeout = time::Duration::from_secs(60); let poll_interval = time::Duration::from_millis(100); let now = time::Instant::now(); debug!(- "Waiting {}s to connect to browser on {}:{}",+ "Waiting {}s to connect to browser on {}", timeout.as_secs(), host,- port ); loop {@@ -1144,19 +1171,30 @@ } }- match MarionetteConnection::try_connect(host, port) {- Ok(stream) => {- debug!("Connection to Marionette established on {}:{}.", host, port);- return Ok(stream);- }- Err(e) => {- if now.elapsed() < timeout {- trace!("{}. Retrying in {:?}", e.to_string(), poll_interval);- thread::sleep(poll_interval);- } else {- return Err(WebDriverError::new(ErrorStatus::Timeout, e.to_string()));+ let last_err;++ if let Some(port) = browser.marionette_port() {+ match MarionetteConnection::try_connect(host, port) {+ Ok(stream) => {+ debug!("Connection to Marionette established on {}:{}.", host, port);+ return Ok(stream);+ }+ Err(e) => {+ let err_str = e.to_string();+ last_err = Some(err_str); } }+ } else {+ last_err = Some("Failed to read marionette port".into());+ }+ if now.elapsed() < timeout {+ trace!("Retrying in {:?}", poll_interval);+ thread::sleep(poll_interval);+ } else {+ return Err(WebDriverError::new(+ ErrorStatus::Timeout,+ last_err.unwrap_or_else(|| "Unknown error".into()),+ )); } } }
I'll analyze the code diff and provide the security findings following the specified format. Vulnerability Existed: yes Insufficient Origin/Host Validation [File] testing/geckodriver/src/marionette.rs [Lines] 83-85, 187-190 [Old Code] No previous validation for allowed hosts/origins [Fixed Code] Added allow_hosts and allow_origins fields to settings and browser creation: pub(crate) allow_hosts: Vec<Host>, pub(crate) allow_origins: Vec<Url>, ... Browser::Local(LocalBrowser::new( options, marionette_port, self.settings.allow_hosts.to_owned(), self.settings.allow_origins.to_owned(), self.settings.jsdebugger, )?) Vulnerability Existed: yes Information Leak Through Error Messages [File] testing/geckodriver/src/marionette.rs [Lines] 1141-1153 [Old Code] Detailed error messages including host and port information [Fixed Code] Simplified error messages without exposing internal details: debug!("Waiting {}s to connect to browser on {}", timeout.as_secs(), host); Vulnerability Existed: not sure Potential Race Condition in Port Handling [File] testing/geckodriver/src/marionette.rs [Lines] 134-166 [Old Code] Simple port assignment without version checks [Fixed Code] Added version-specific port handling logic with additional checks: if can_use_profile { 0 } else { get_free_port(&marionette_host)? } Vulnerability Existed: yes Session Management Vulnerability [File] testing/geckodriver/src/marionette.rs [Lines] 199-201 [Old Code] Browser::Existing without port tracking [Fixed Code] Browser::Existing(marionette_port) - now tracks port for existing connections Vulnerability Existed: yes Removed Deprecated/Insecure Field [File] testing/geckodriver/src/marionette.rs [Lines] 462-470 [Old Code] Support for legacy "page load" timeout field [Fixed Code] Only uses spec-compliant "pageLoad" field: try_opt!( resp.result .get("pageLoad"),
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/js/src/jit-test/tests/stream/bug-1513266.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/jit-test/tests/stream/bug-1513266.js@@ -1,11 +1,11 @@-// |jit-test| --no-ion; --no-baseline; skip-if: !('oomTest' in this)+// |jit-test| --no-ion; --no-baseline; skip-if: !('oomTest' in this && this.hasOwnProperty("ReadableStream")) ignoreUnhandledRejections(); function test() { let controller; let stream = new ReadableStream({- start(c) {}+ start(c) { } }); stream.getReader(); drainJobQueue();@@ -13,4 +13,4 @@ // Force lazy parsing to happen before oomTest starts (see `help(oomTest)`). test();-oomTest(test, {verbose: true, keepFailing: false});+oomTest(test, { verbose: true, keepFailing: false });
Here's the analysis following the required format: 1. Vulnerability Existed: not sure [Potential Feature Detection Issue] [js/src/jit-test/tests/stream/bug-1513266.js] [Lines 1] Old Code: `// |jit-test| --no-ion; --no-baseline; skip-if: !('oomTest' in this)` Fixed Code: `// |jit-test| --no-ion; --no-baseline; skip-if: !('oomTest' in this && this.hasOwnProperty("ReadableStream"))` Additional Details: The change adds a check for ReadableStream existence before running the test. While not a security vulnerability per se, it prevents potential runtime errors in environments where ReadableStream isn't available. 2. Vulnerability Existed: no [Code Style Change] [js/src/jit-test/tests/stream/bug-1513266.js] [Lines 5] Old Code: ` start(c) {}` Fixed Code: ` start(c) { }` Additional Details: This appears to be purely a whitespace/style change with no security implications. 3. Vulnerability Existed: no [Code Style Change] [js/src/jit-test/tests/stream/bug-1513266.js] [Lines 13] Old Code: `oomTest(test, {verbose: true, keepFailing: false});` Fixed Code: `oomTest(test, { verbose: true, keepFailing: false });` Additional Details: This is purely a formatting change (added spaces) with no security implications.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/security/sandbox/test/browser_sandbox_test.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/security/sandbox/test/browser_sandbox_test.js@@ -14,23 +14,14 @@ // GPU process might not run depending on the platform, so we need it to be // the last one of the list to allow the remainingTests logic below to work // as expected.- //- // Skip GPU tests for now because they don't actually run anything and they- // trigger some shutdown hang on Windows- // FIXME: Bug XXX- var processTypes = ["tab", "socket", "rdd", "gmplugin", "gpu"];+ var processTypes = ["tab", "socket", "rdd", "gmplugin", "utility", "gpu"]; // A callback called after each test-result. let sandboxTestResult = (subject, topic, data) => {- let { testid, shouldPermit, wasPermitted, message } = JSON.parse(data);+ let { testid, passed, message } = JSON.parse(data); ok(- shouldPermit == wasPermitted,- "Test " +- testid +- " was " +- (wasPermitted ? "" : "not ") +- "permitted. | " +- message+ passed,+ "Test " + testid + (passed ? " passed: " : " failed: ") + message ); }; Services.obs.addObserver(sandboxTestResult, "sandbox-test-result");
Here's the analysis following the requested format: 1. Vulnerability Existed: not sure [Potentially Incomplete Sandbox Test Coverage] [security/sandbox/test/browser_sandbox_test.js] [Lines 14-23] [Old Code] // Skip GPU tests for now because they don't actually run anything and they // trigger some shutdown hang on Windows // FIXME: Bug XXX var processTypes = ["tab", "socket", "rdd", "gmplugin", "gpu"]; [Fixed Code] var processTypes = ["tab", "socket", "rdd", "gmplugin", "utility", "gpu"]; Additional Details: The change adds "utility" to the process types being tested and removes comments about skipped GPU tests. This might indicate improved test coverage, but it's unclear if this was fixing a specific security vulnerability. 2. Vulnerability Existed: not sure [Potentially Insecure Test Result Handling] [security/sandbox/test/browser_sandbox_test.js] [Lines 25-33] [Old Code] let { testid, shouldPermit, wasPermitted, message } = JSON.parse(data); ok( shouldPermit == wasPermitted, "Test " + testid + " was " + (wasPermitted ? "" : "not ") + "permitted. | " + message ); [Fixed Code] let { testid, passed, message } = JSON.parse(data); ok( passed, "Test " + testid + (passed ? " passed: " : " failed: ") + message ); Additional Details: The test result handling was simplified, but it's unclear if this was fixing a specific security vulnerability or just improving test clarity. The change might indicate a more robust test verification approach. Note: Without additional context about the threat model and specific vulnerabilities being addressed, it's difficult to definitively identify security vulnerabilities in these changes. The modifications appear to be test improvements rather than direct security fixes.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.css-color-4-rgb-5.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.css-color-4-rgb-5.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 = 'rgb(0 255 0 / 0.2)'; ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,51, "50,25", "0,255,0,51");+_assertPixel(canvas, 50,25, 0,255,0,51, "50,25", "0,255,0,51"); t.done(); });
Analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely cosmetic/refactoring changes (variable renaming) rather than security fixes. Here's the analysis following the requested format: Vulnerability Existed: no [No security vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.css-color-4-rgb-5.html] [Lines 17-25] [Old Code] var offscreenCanvas = new OffscreenCanvas(100, 50); var ctx = offscreenCanvas.getContext('2d'); _assertPixel(offscreenCanvas, 50,25, 0,255,0,51, "50,25", "0,255,0,51"); [Fixed Code] var canvas = new OffscreenCanvas(100, 50); var ctx = canvas.getContext('2d'); _assertPixel(canvas, 50,25, 0,255,0,51, "50,25", "0,255,0,51"); The changes only involve: 1. Renaming the variable `offscreenCanvas` to `canvas` 2. Updating the references to this variable in the subsequent lines 3. The actual functionality and security implications remain unchanged No CVE or specific vulnerability name applies here as this is not a security-related 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/widget/GfxDriverInfo.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/widget/GfxDriverInfo.h@@ -392,11 +392,13 @@ bool mGpu2; };-#define GFX_DRIVER_VERSION(a, b, c, d) \- ((uint64_t(a) << 48) | (uint64_t(b) << 32) | (uint64_t(c) << 16) | \- uint64_t(d))+inline uint64_t DriverVersion(uint32_t a, uint32_t b, uint32_t c, uint32_t d) {+ return (uint64_t(a) << 48) | (uint64_t(b) << 32) | (uint64_t(c) << 16) |+ uint64_t(d);+} inline uint64_t V(uint32_t a, uint32_t b, uint32_t c, uint32_t d) {+#ifdef XP_WIN // We make sure every driver number is padded by 0s, this will allow us the // easiest 'compare as if decimals' approach. See ParseDriverVersion for a // more extensive explanation of this approach.@@ -409,7 +411,8 @@ while (d > 0 && d < 1000) { d *= 10; }- return GFX_DRIVER_VERSION(a, b, c, d);+#endif+ return DriverVersion(a, b, c, d); } // All destination string storage needs to have at least 5 bytes available.@@ -482,7 +485,7 @@ uint64_t* aNumericVersion) { *aNumericVersion = 0;-#if defined(XP_WIN) || defined(MOZ_WIDGET_GTK)+#ifndef ANDROID int a, b, c, d; char aStr[8], bStr[8], cStr[8], dStr[8]; /* honestly, why do I even bother */@@ -490,9 +493,11 @@ bStr, cStr, dStr)) return false;+# ifdef XP_WIN PadDriverDecimal(bStr); PadDriverDecimal(cStr); PadDriverDecimal(dStr);+# endif a = atoi(aStr); b = atoi(bStr);@@ -504,18 +509,14 @@ if (c < 0 || c > 0xffff) return false; if (d < 0 || d > 0xffff) return false;- *aNumericVersion = GFX_DRIVER_VERSION(a, b, c, d);- MOZ_ASSERT(*aNumericVersion != GfxDriverInfo::allDriverVersions);- return true;-#elif defined(ANDROID)+ *aNumericVersion = DriverVersion(a, b, c, d);+#else // Can't use aVersion.ToInteger() because that's not compiled into our code // unless we have XPCOM_GLUE_AVOID_NSPR disabled. *aNumericVersion = atoi(NS_LossyConvertUTF16toASCII(aVersion).get());+#endif MOZ_ASSERT(*aNumericVersion != GfxDriverInfo::allDriverVersions); return true;-#else- return false;-#endif } } // namespace widget
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: not sure Integer Overflow Vulnerability [widget/GfxDriverInfo.h] [Lines 392-395, 409-411] Old Code: #define GFX_DRIVER_VERSION(a, b, c, d) \ ((uint64_t(a) << 48) | (uint64_t(b) << 32) | (uint64_t(c) << 16) | \ uint64_t(d)) Fixed Code: inline uint64_t DriverVersion(uint32_t a, uint32_t b, uint32_t c, uint32_t d) { return (uint64_t(a) << 48) | (uint64_t(b) << 32) | (uint64_t(c) << 16) | uint64_t(d); } Details: The macro was replaced with an inline function with explicit uint32_t parameters, which might prevent potential integer overflow issues by ensuring proper type handling. 2. Vulnerability Existed: not sure Platform-Specific Code Isolation [widget/GfxDriverInfo.h] [Lines 409-411, 482-509] Old Code: #ifdef XP_WIN // Windows-specific padding code #endif return GFX_DRIVER_VERSION(a, b, c, d); Fixed Code: #ifdef XP_WIN // Windows-specific padding code #endif return DriverVersion(a, b, c, d); Details: The changes better isolate platform-specific code and use the new DriverVersion function consistently. 3. Vulnerability Existed: not sure Input Validation Improvement [widget/GfxDriverInfo.h] [Lines 482-509] Old Code: #if defined(XP_WIN) || defined(MOZ_WIDGET_GTK) // Parsing and validation code #elif defined(ANDROID) // Android-specific code #else return false; #endif Fixed Code: #ifndef ANDROID // Parsing and validation code # ifdef XP_WIN // Windows-specific padding # endif #else // Android-specific code #endif Details: The logic was reorganized to be more clear about platform-specific handling, which might improve input validation consistency. Note: While these changes appear to improve code safety and organization, it's not clear if they were specifically addressing known vulnerabilities or just general code improvements. The switch from a macro to a function and the platform logic reorganization could potentially prevent certain types of issues, but without more context about the specific threats being addressed, we can't be certain.
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/jpeg-xl/lib/jxl/dec_xyb.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/jpeg-xl/lib/jxl/dec_xyb.h@@ -41,6 +41,11 @@ Status Set(const CodecMetadata& metadata, const ColorEncoding& default_enc); bool all_default_opsin = true; bool color_encoding_is_original = false;+ // Luminances of color_encoding's primaries, used for the HLG inverse OOTF.+ // Default to sRGB's.+ float luminances[3] = {0.2126, 0.7152, 0.0722};+ // Also used for the HLG inverse OOTF.+ float intensity_target; }; // Converts `inout` (not padded) from opsin to linear sRGB in-place. Called from
Here's the analysis of the provided code diff: Vulnerability Existed: not sure [Potential Missing Initialization] [third_party/jpeg-xl/lib/jxl/dec_xyb.h] [Lines 41-46] [Old Code] ``` bool all_default_opsin = true; bool color_encoding_is_original = false; ``` [Fixed Code] ``` bool all_default_opsin = true; bool color_encoding_is_original = false; // Luminances of color_encoding's primaries, used for the HLG inverse OOTF. // Default to sRGB's. float luminances[3] = {0.2126, 0.7152, 0.0722}; // Also used for the HLG inverse OOTF. float intensity_target; ``` Additional Details: 1. The diff adds new member variables to a class, including an uninitialized `float intensity_target`. While not necessarily a security vulnerability, uninitialized variables can lead to undefined behavior. 2. The change appears to be adding functionality for HLG (Hybrid Log-Gamma) color space handling rather than fixing a security issue. 3. Without more context about how `intensity_target` is used, it's difficult to determine if this could lead to security issues. Note: I couldn't identify any clear security vulnerabilities in this diff, but I'm providing the analysis in the requested format for the most suspicious aspect (uninitialized variable).
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-over.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-over.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 following your requested format: Vulnerability Existed: no No security vulnerability found [testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.clip.destination-over.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 only involve renaming the variable from `offscreenCanvas` to `canvas` and updating the references accordingly. There are no security implications to these changes.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/dom/base/RangeBoundary.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/base/RangeBoundary.h@@ -183,7 +183,9 @@ if (mParent) { DetermineOffsetFromReference();- return mOffset;+ if (mOffset.isSome()) {+ return mOffset;+ } } return Some(kFallbackOffset);@@ -202,6 +204,13 @@ MOZ_ASSERT(mParent); MOZ_ASSERT(mRef); MOZ_ASSERT(mRef->GetParentNode() == mParent);+ MOZ_ASSERT(mOffset.isNothing());++ if (mRef->IsBeingRemoved()) {+ // ComputeIndexOf would return nothing because mRef has already been+ // removed from the child node chain of mParent.+ return;+ } const Maybe<uint32_t> index = mParent->ComputeIndexOf(mRef); MOZ_ASSERT(*index != UINT32_MAX);@@ -230,7 +239,10 @@ } if (Ref()) {- return Ref()->GetParentNode() == Container();+ // XXX mRef refers previous sibling of pointing child. Therefore, it+ // seems odd that this becomes invalid due to its removal. Should we+ // change RangeBoundaryBase to refer child at offset directly?+ return Ref()->GetParentNode() == Container() && !Ref()->IsBeingRemoved(); } MOZ_ASSERT(mOffset.isSome());
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: yes Null Pointer Dereference [File] dom/base/RangeBoundary.h [Lines] 183-187 [Old Code] ```cpp if (mParent) { DetermineOffsetFromReference(); return mOffset; } ``` [Fixed Code] ```cpp if (mParent) { DetermineOffsetFromReference(); if (mOffset.isSome()) { return mOffset; } } ``` The fix adds a check for mOffset being Some() before returning it, preventing potential null pointer dereference. 2. Vulnerability Existed: yes Use-After-Free [File] dom/base/RangeBoundary.h [Lines] 202-207 [Old Code] ```cpp MOZ_ASSERT(mParent); MOZ_ASSERT(mRef); MOZ_ASSERT(mRef->GetParentNode() == mParent); ``` [Fixed Code] ```cpp MOZ_ASSERT(mParent); MOZ_ASSERT(mRef); MOZ_ASSERT(mRef->GetParentNode() == mParent); MOZ_ASSERT(mOffset.isNothing()); if (mRef->IsBeingRemoved()) { // ComputeIndexOf would return nothing because mRef has already been // removed from the child node chain of mParent. return; } ``` The fix adds a check for IsBeingRemoved() to prevent use-after-free when mRef has been removed from the DOM. 3. Vulnerability Existed: yes Use-After-Free [File] dom/base/RangeBoundary.h [Lines] 230-233 [Old Code] ```cpp if (Ref()) { return Ref()->GetParentNode() == Container(); } ``` [Fixed Code] ```cpp if (Ref()) { // XXX mRef refers previous sibling of pointing child. Therefore, it // seems odd that this becomes invalid due to its removal. Should we // change RangeBoundaryBase to refer child at offset directly? return Ref()->GetParentNode() == Container() && !Ref()->IsBeingRemoved(); } ``` The fix adds a check for IsBeingRemoved() to prevent use-after-free when the reference node has been removed from the DOM. The changes appear to address potential security vulnerabilities related to null pointer dereferences and use-after-free scenarios when DOM nodes are being removed or manipulated. The fixes add proper checks before accessing node properties and references.
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.radial.cone.front.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.gradient.radial.cone.front.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);@@ -23,15 +23,15 @@ g.addColorStop(1, '#0f0'); ctx.fillStyle = g; 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(); });
Based on 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 updating the corresponding references in the `_assertPixel` calls. Here's the analysis: Vulnerability Existed: no No security vulnerability found [File] [Lines 13-23,25-33] [Old Code] var offscreenCanvas = new OffscreenCanvas(100, 50); var ctx = offscreenCanvas.getContext('2d'); ... _assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255"); [Fixed Code] var canvas = new OffscreenCanvas(100, 50); var ctx = canvas.getContext('2d'); ... _assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255"); This appears to be a simple refactoring change with no security implications. 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/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.roundrect.2.radii.2.double.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.2.radii.2.double.html@@ -17,18 +17,18 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50); ctx.roundRect(0, 0, 100, 50, [0, 20]); ctx.fillStyle = '#0f0'; ctx.fill();-_assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 98,1, 255,0,0,255, "98,1", "255,0,0,255");-_assertPixel(offscreenCanvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255");-_assertPixel(offscreenCanvas, 1,48, 255,0,0,255, "1,48", "255,0,0,255");+_assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");+_assertPixel(canvas, 98,1, 255,0,0,255, "98,1", "255,0,0,255");+_assertPixel(canvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255");+_assertPixel(canvas, 1,48, 255,0,0,255, "1,48", "255,0,0,255"); t.done(); });
After analyzing the provided code diff, I don't find any security vulnerabilities. The changes appear to be purely cosmetic/refactoring changes where a variable name was changed from `offscreenCanvas` to `canvas`, with all corresponding references updated accordingly. Here's the structured response: Vulnerability Existed: no [No security vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.roundrect.2.radii.2.double.html] [Lines 17-31] [Old Code: var offscreenCanvas = new OffscreenCanvas(100, 50); ... _assertPixel(offscreenCanvas, 1,48, 255,0,0,255, "1,48", "255,0,0,255");] [Fixed Code: var canvas = new OffscreenCanvas(100, 50); ... _assertPixel(canvas, 1,48, 255,0,0,255, "1,48", "255,0,0,255");] The changes are purely variable naming improvements and don't affect security in any way. The functionality remains identical, just with a more concise 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/devtools/server/actors/thread.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/server/actors/thread.js@@ -28,6 +28,9 @@ const { WatchpointMap, } = require("devtools/server/actors/utils/watchpoint-map");+const {+ isHiddenSource,+} = require("devtools/server/actors/utils/sources-manager"); const { logEvent } = require("devtools/server/actors/utils/logEvent");@@ -935,7 +938,7 @@ packet.why = reason; if (!sourceActor) {- // If the frame location is in a source that not pass the 'allowSource'+ // If the frame location is in a source that not pass the 'isHiddenSource' // check and thus has no actor, we do not bother pausing. return undefined; }@@ -2066,7 +2069,7 @@ * @returns true, if the source was added; false otherwise. */ _addSource(source) {- if (!this.sourcesManager.allowSource(source)) {+ if (isHiddenSource(source)) { return false; }
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: not sure [Potential Information Leakage] [devtools/server/actors/thread.js] [Lines 935-938, 2066-2069] [Old Code] ```javascript if (!sourceActor) { // If the frame location is in a source that not pass the 'allowSource' // check and thus has no actor, we do not bother pausing. return undefined; } ``` ```javascript if (!this.sourcesManager.allowSource(source)) { return false; } ``` [Fixed Code] ```javascript if (!sourceActor) { // If the frame location is in a source that not pass the 'isHiddenSource' // check and thus has no actor, we do not bother pausing. return undefined; } ``` ```javascript if (isHiddenSource(source)) { return false; } ``` Additional Details: The change replaces 'allowSource' with 'isHiddenSource' check, which appears to be a more precise way to handle hidden sources. While not clearly a security vulnerability, this could potentially prevent information leakage by more accurately identifying and excluding hidden sources from being processed. The comment change suggests this was a conceptual improvement in source filtering.
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/geckodriver/src/logging.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/geckodriver/src/logging.rs@@ -219,8 +219,6 @@ use std::str::FromStr; use std::sync::Mutex;- use chrono;- use log; use mozprofile::preferences::{Pref, PrefValue}; lazy_static! {
Analysis of the code diff: 1. Vulnerability Existed: no Dependency Cleanup [File] [Lines 219-221] [Old Code] use chrono; use log; [Fixed Code] (removed unused dependencies) Additional Details: - The diff shows removal of two unused dependencies (`chrono` and `log`). This appears to be a code cleanup rather than a security fix. - There are no clear security vulnerabilities being addressed in this change. - The modification is simply removing unused imports which doesn't impact security. - No CVE or known vulnerability is associated with 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.paint.repeat.coord1.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.paint.repeat.coord1.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);@@ -37,10 +37,10 @@ ctx.fillStyle = pattern; ctx.translate(-128, -78); ctx.fillRect(128, 78, 100, 50);- _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_fail); }).then(t_pass, t_fail);
After analyzing the provided code diff, here's my assessment: Vulnerability Existed: no Variable Renaming [File] [Lines 17-18, 37-40] [Old Code] var offscreenCanvas = new OffscreenCanvas(100, 50); var ctx = offscreenCanvas.getContext('2d'); _assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255"); [Fixed Code] var canvas = new OffscreenCanvas(100, 50); var ctx = canvas.getContext('2d'); _assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255"); The changes appear to be purely cosmetic, renaming the variable `offscreenCanvas` to `canvas` for consistency or clarity. There are no security-related changes in this diff, and no vulnerabilities are being addressed. The functionality remains exactly the same, only the variable name has changed.
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.