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/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/WebRequest.java+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/WebRequest.java@@ -40,6 +40,12 @@ */ public final @CacheMode int cacheMode;+ /**+ * If true, do not use newer protocol features that might have interop problems on the Internet.+ * Intended only for use with critical infrastructure.+ */+ public final boolean beConservative;+ /** The value of the Referer header for this request. */ public final @Nullable String referrer;@@ -52,7 +58,7 @@ CACHE_MODE_FORCE_CACHE, CACHE_MODE_ONLY_IF_CACHED })- /* package */ @interface CacheMode {};+ public @interface CacheMode {}; /** Default cache mode. Normal caching rules apply. */ public static final int CACHE_MODE_DEFAULT = 1;@@ -103,6 +109,7 @@ method = builder.mMethod; cacheMode = builder.mCacheMode; referrer = builder.mReferrer;+ beConservative = builder.mBeConservative; if (builder.mBody != null) { body = builder.mBody.asReadOnlyBuffer();@@ -117,6 +124,7 @@ /* package */ String mMethod = "GET"; /* package */ int mCacheMode = CACHE_MODE_DEFAULT; /* package */ String mReferrer;+ /* package */ boolean mBeConservative; /** * Construct a Builder instance with the specified URI.@@ -215,6 +223,18 @@ return this; }+ /**+ * Set the beConservative property.+ *+ * @param beConservative If true, do not use newer protocol features that might have interop+ * problems on the Internet. Intended only for use with critical infrastructure.+ * @return This Builder instance.+ */+ public @NonNull Builder beConservative(final boolean beConservative) {+ mBeConservative = beConservative;+ return this;+ }+ /** @return A {@link WebRequest} constructed with the values from this Builder instance. */ public @NonNull WebRequest build() { if (mUri == null) {
Here's the analysis following the requested format: 1. Vulnerability Existed: not sure [Potential Information Leak] [mobile/android/geckoview/src/main/java/org/mozilla/geckoview/WebRequest.java] [Lines 40-58] [Old Code: @interface CacheMode was package-private] [Fixed Code: @interface CacheMode is now public] Note: While not clearly a security vulnerability, changing the visibility of CacheMode from package-private to public could potentially expose more information than intended. However, this might be intentional to allow broader usage. 2. Vulnerability Existed: no [New Feature Addition] [mobile/android/geckoview/src/main/java/org/mozilla/geckoview/WebRequest.java] [Lines throughout] [Old Code: No beConservative field] [Fixed Code: Added beConservative field and related methods] Note: This appears to be a new feature addition rather than a security fix. The beConservative flag allows for more controlled protocol usage but doesn't appear to fix a specific vulnerability. The diff primarily shows feature additions (beConservative flag) and a visibility change (CacheMode annotation), but doesn't clearly indicate any security vulnerability fixes. The changes seem focused on functionality expansion rather than security patching.
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/views/rule-editor.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/inspector/rules/views/rule-editor.js@@ -135,6 +135,38 @@ this.updateSourceLink();+ if (this.rule.domRule.ancestorData.length > 0) {+ const parts = this.rule.domRule.ancestorData.map(ancestorData => {+ if (ancestorData.type == "layer") {+ return `@layer${ancestorData.value ? " " + ancestorData.value : ""}`;+ }+ if (ancestorData.type == "media") {+ return `@media ${ancestorData.value}`;+ }+ // We shouldn't get here as `type` can only be set to "layer" or "media", but just+ // in case, let's return an empty string.+ console.warn("Unknown ancestor data type:", ancestorData.type);+ return ``;+ });++ // We force the string to be LTR in CSS, but as @ is listed as having neutral+ // directionality and starting a string with this char would default to RTL for that+ // character (when in RTL locale), and then the next char (`m` of `media`, or `l` of `layer`)+ // would start a new LTR visual run, since it is strongly LTR (through `direction` CSS property).+ // To have the `@` properly displayed, we force LTR with \u202A+ const title = `${parts.join("\n").replaceAll("@", "\u202A@")}`;++ this.ancestorDataEl = createChild(this.element, "ul", {+ class: "ruleview-rule-ancestor-data theme-link",+ title,+ });+ for (const part of parts) {+ createChild(this.ancestorDataEl, "li", {+ textContent: part,+ });+ }+ }+ const code = createChild(this.element, "div", { class: "ruleview-code", });@@ -301,10 +333,6 @@ if (line > 0) { sourceTextContent += ":" + line; title += ":" + line;- }- if (this.rule.mediaText) {- sourceTextContent += " @" + this.rule.mediaText;- title += " @" + this.rule.mediaText; } const sourceLabel = this.element.querySelector(
Here's the analysis following the required format: 1. Vulnerability Existed: not sure [Potential XSS Vulnerability] [devtools/client/inspector/rules/views/rule-editor.js] [Lines 135-170] [Old Code: No handling of ancestor data] [Fixed Code: Added handling of ancestor data with proper escaping and LTR direction control] 2. Vulnerability Existed: yes [Information Disclosure] [devtools/client/inspector/rules/views/rule-editor.js] [Lines 301-306] [Old Code: Included mediaText in source label without proper escaping] [Fixed Code: Removed mediaText inclusion in source label] Additional Details: 1. The first change adds handling for ancestor data with proper escaping (using \u202A for LTR direction control) which suggests there might have been a potential XSS or display manipulation vulnerability, though it's not explicitly stated. The console.warn for unknown types also suggests input validation concerns. 2. The second change clearly removes the inclusion of mediaText in the source label, which could have exposed sensitive information in the UI. This appears to be a deliberate security fix for information disclosure. Note: While the changes appear security-related, without more context about the threat model and how these values are used, we can't be certain about all vulnerabilities. The changes do show improved security practices in handling potentially untrusted data.
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/framework/devtools.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/framework/devtools.js@@ -57,6 +57,7 @@ const FORBIDDEN_IDS = new Set(["toolbox", ""]); const MAX_ORDINAL = 99;+const POPUP_DEBUG_PREF = "devtools.popups.debug"; /** * DevTools is a class that represents a set of developer tools, it holds a@@ -583,6 +584,25 @@ tab, { toolId, hostType, startTime, raise, reason, hostOptions } = {} ) {+ // Popups are debugged via the toolbox of their opener document/tab.+ // So avoid opening dedicated toolbox for them.+ if (+ tab.linkedBrowser.browsingContext.opener &&+ Services.prefs.getBoolPref(POPUP_DEBUG_PREF)+ ) {+ const openerTab = tab.ownerGlobal.gBrowser.getTabForBrowser(+ tab.linkedBrowser.browsingContext.opener.embedderElement+ );+ const openerDescriptor = await TabDescriptorFactory.getDescriptorForTab(+ openerTab+ );+ if (this.getToolboxForDescriptor(openerDescriptor)) {+ console.log(+ "Can't open a toolbox for this document as this is debugged from its opener tab"+ );+ return;+ }+ } const descriptor = await TabDescriptorFactory.createDescriptorForTab(tab); return this.showToolbox(descriptor, { toolId,
Based on the provided code diff, here's the security analysis:
Vulnerability Existed: not sure
[Potential Popup Debugging Security Issue] [devtools/client/framework/devtools.js] [Lines 583-608]
[Old Code]
tab,
{ toolId, hostType, startTime, raise, reason, hostOptions } = {}
) {
const descriptor = await TabDescriptorFactory.createDescriptorForTab(tab);
return this.showToolbox(descriptor, {
toolId,
[Fixed Code]
tab,
{ toolId, hostType, startTime, raise, reason, hostOptions } = {}
) {
// Popups are debugged via the toolbox of their opener document/tab.
// So avoid opening dedicated toolbox for them.
if (
tab.linkedBrowser.browsingContext.opener &&
Services.prefs.getBoolPref(POPUP_DEBUG_PREF)
) {
const openerTab = tab.ownerGlobal.gBrowser.getTabForBrowser(
tab.linkedBrowser.browsingContext.opener.embedderElement
);
const openerDescriptor = await TabDescriptorFactory.getDescriptorForTab(
openerTab
);
if (this.getToolboxForDescriptor(openerDescriptor)) {
console.log(
"Can't open a toolbox for this document as this is debugged from its opener tab"
);
return;
}
}
const descriptor = await TabDescriptorFactory.createDescriptorForTab(tab);
Additional Details:
The change adds a check to prevent opening duplicate toolboxes for popup windows when they're being debugged from their opener tab. While this doesn't appear to fix a specific known vulnerability, it could potentially prevent:
1. Resource exhaustion from duplicate debugging sessions
2. Confusion in debugging contexts
3. Potential information leakage between debugging sessions
However, without more context about the specific threat model, it's difficult to classify this as a definitive security fix. The change appears to be more about improving debugging workflow and resource management than addressing a specific security vulnerability.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/ash/src/extensions/khr/mod.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/ash/src/extensions/khr/mod.rs@@ -6,6 +6,7 @@ pub use self::display::Display; pub use self::display_swapchain::DisplaySwapchain; pub use self::draw_indirect_count::DrawIndirectCount;+pub use self::dynamic_rendering::DynamicRendering; pub use self::external_fence_fd::ExternalFenceFd; pub use self::external_memory_fd::ExternalMemoryFd; pub use self::external_semaphore_fd::ExternalSemaphoreFd;@@ -13,7 +14,9 @@ pub use self::get_physical_device_properties2::GetPhysicalDeviceProperties2; pub use self::maintenance1::Maintenance1; pub use self::maintenance3::Maintenance3;+pub use self::maintenance4::Maintenance4; pub use self::pipeline_executable_properties::PipelineExecutableProperties;+pub use self::present_wait::PresentWait; pub use self::push_descriptor::PushDescriptor; pub use self::ray_tracing_pipeline::RayTracingPipeline; pub use self::surface::Surface;@@ -33,6 +36,7 @@ mod display; mod display_swapchain; mod draw_indirect_count;+mod dynamic_rendering; mod external_fence_fd; mod external_memory_fd; mod external_semaphore_fd;@@ -40,7 +44,9 @@ mod get_physical_device_properties2; mod maintenance1; mod maintenance3;+mod maintenance4; mod pipeline_executable_properties;+mod present_wait; mod push_descriptor; mod ray_tracing_pipeline; mod surface;
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be adding new module exports and declarations for additional Vulkan extension functionality. Here's the analysis following your requested format: Vulnerability Existed: no [No security vulnerability found] [third_party/rust/ash/src/extensions/khr/mod.rs] [Lines 6,13,14,33,40,44] [Old code was missing several module exports] [Fixed code adds new module exports for additional Vulkan extensions] The changes include: 1. Adding DynamicRendering export and module 2. Adding Maintenance4 export and module 3. Adding PresentWait export and module These appear to be feature additions rather than security fixes. The diff shows the Rust ash crate (Vulkan bindings) adding support for newer Vulkan extensions (KHR_dynamic_rendering, KHR_maintenance4, and KHR_present_wait) between Firefox 97 and 98 releases. No CVE or known vulnerability patterns are being addressed here - this is simply expanding the API surface to support more Vulkan functionality.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/mediaqueries/relative-units-001.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/mediaqueries/relative-units-001.html@@ -7,7 +7,6 @@ <link rel="help" href="https://www.w3.org/TR/css3-mediaqueries/#units"> <link rel="help" href="https://www.w3.org/TR/mediaqueries-4/#units"> <link rel="match" href="reference/ref-green-body.xht">- <meta name="flags" content=""> <meta name="assert" content="Font-relative length units (such as 'rem') in media queries should be calculated based on the initial value of 'font-size', not based on author style declarations, such as: html { font-size: 200%; }"> <style> :root {
Analysis of the provided code diff: 1. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/css/mediaqueries/relative-units-001.html [Lines] 7 [Old Code] <meta name="flags" content=""> [Fixed Code] (line removed) Additional Details: This appears to be a test file modification where an empty meta tag was removed. There's no security implication to this change. 2. Vulnerability Existed: not sure Potential HTML meta tag misuse [File] testing/web-platform/tests/css/mediaqueries/relative-units-001.html [Lines] 7 [Old Code] <meta name="flags" content=""> [Fixed Code] (line removed) Additional Details: While not clearly a security issue, the removal of an empty meta tag might indicate cleanup of potentially problematic markup, though this is speculative. Note: The diff shows only minor test file modifications with no clear security implications. The changes appear to be test infrastructure improvements rather than security fixes.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/layout/generic/nsIFrame.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/layout/generic/nsIFrame.h@@ -599,6 +599,7 @@ mForceDescendIntoIfVisible(false), mBuiltDisplayList(false), mFrameIsModified(false),+ mHasModifiedDescendants(false), mHasOverrideDirtyRegion(false), mMayHaveWillChangeBudget(false), mIsPrimaryFrame(false),@@ -4893,6 +4894,11 @@ mFrameIsModified = aFrameIsModified; }+ bool HasModifiedDescendants() const { return mHasModifiedDescendants; }+ void SetHasModifiedDescendants(const bool aHasModifiedDescendants) {+ mHasModifiedDescendants = aHasModifiedDescendants;+ }+ bool HasOverrideDirtyRegion() const { return mHasOverrideDirtyRegion; } void SetHasOverrideDirtyRegion(const bool aHasDirtyRegion) { mHasOverrideDirtyRegion = aHasDirtyRegion;@@ -5128,8 +5134,22 @@ */ bool mBuiltDisplayList : 1;+ /**+ * True if the frame has been marked modified by+ * |MarkNeedsDisplayItemRebuild()|, usually due to a style change or reflow.+ */ bool mFrameIsModified : 1;+ /**+ * True if the frame has modified descendants. Set before display list+ * preprocessing and only used during partial display list builds.+ */+ bool mHasModifiedDescendants : 1;++ /**+ * Used by merging based retained display lists to restrict the dirty area+ * during partial display list builds.+ */ bool mHasOverrideDirtyRegion : 1; /**
Analyzing the provided code diff, I don't see any clear security vulnerabilities being fixed. The changes appear to be adding functionality related to tracking frame modifications and display list building rather than addressing security issues. Here's the analysis following your requested format: Vulnerability Existed: no No security vulnerability found [File] nsIFrame.h [Lines] 599, 4893-4896, 5128-5134 [Old Code] (No previous tracking of modified descendants) [Fixed Code] Added mHasModifiedDescendants flag and related methods to track frame modifications The changes include: 1. Adding a new mHasModifiedDescendants boolean member variable 2. Adding getter/setter methods for this variable 3. Adding documentation comments explaining the purpose of the new flag These changes appear to be functional improvements rather than security fixes, likely related to optimizing display list building and partial updates. There's no indication of any security vulnerability being addressed in this diff. If I were to speculate about potential security implications, the changes could theoretically help prevent some types of rendering issues that might lead to information disclosure, but there's no clear evidence this was the motivation for the change. The commit appears to be purely functional in nature.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.roundrect.4.radii.3.dompointinit.worker.js+++ /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.4.radii.3.dompointinit.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 @@ ctx.fill(); // bottom-right corner-_assertPixel(offscreenCanvas, 79,48, 255,0,0,255, "79,48", "255,0,0,255");-_assertPixel(offscreenCanvas, 58,48, 0,255,0,255, "58,48", "0,255,0,255");-_assertPixel(offscreenCanvas, 98,39, 255,0,0,255, "98,39", "255,0,0,255");-_assertPixel(offscreenCanvas, 98,28, 0,255,0,255, "98,28", "0,255,0,255");+_assertPixel(canvas, 79,48, 255,0,0,255, "79,48", "255,0,0,255");+_assertPixel(canvas, 58,48, 0,255,0,255, "58,48", "0,255,0,255");+_assertPixel(canvas, 98,39, 255,0,0,255, "98,39", "255,0,0,255");+_assertPixel(canvas, 98,28, 0,255,0,255, "98,28", "0,255,0,255"); // other corners-_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(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"); t.done(); });
After analyzing the provided code diff, I can identify the following potential security issues: 1. Vulnerability Existed: no The changes in this diff appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and don't indicate any security fixes. The functionality remains the same, just with a different variable name. 2. Vulnerability Existed: no The changes in the `_assertPixel` calls are simply updating the variable name to match the renamed canvas variable. No security implications are present in these changes. The diff shows no actual security fixes - it's just a refactoring of variable names for better consistency or readability. The test functionality remains identical, just using a different variable name (`canvas` instead of `offscreenCanvas`). No known vulnerabilities (like XSS, injection, etc.) are being addressed in this change, and the changes don't introduce any new security concerns.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/ash/src/entry.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/ash/src/entry.rs@@ -2,41 +2,146 @@ use crate::prelude::*; use crate::vk; use crate::RawPtr;-use std::error::Error; use std::ffi::CStr;-use std::fmt;+#[cfg(feature = "loaded")]+use std::ffi::OsStr; use std::mem; use std::os::raw::c_char; use std::os::raw::c_void; use std::ptr;--/// Holds a custom type `L` to load symbols from (usually a handle to a `dlopen`ed library),-/// the [`vkGetInstanceProcAddr`][vk::StaticFn::get_instance_proc_addr()] loader function from-/// this library (in [`vk::StaticFn`]), and Vulkan's "entry point" functions (resolved with `NULL`-/// `instance`) as listed in [`vkGetInstanceProcAddr`'s description].-///-/// [`vkGetInstanceProcAddr`'s description]: https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkGetInstanceProcAddr.html#_description+#[cfg(feature = "loaded")]+use std::sync::Arc;++#[cfg(feature = "loaded")]+use libloading::Library;++/// Holds the Vulkan functions independent of a particular instance #[derive(Clone)]-pub struct EntryCustom<L> {+pub struct Entry { static_fn: vk::StaticFn, entry_fn_1_0: vk::EntryFnV1_0, entry_fn_1_1: vk::EntryFnV1_1, entry_fn_1_2: vk::EntryFnV1_2,- lib: L,+ #[cfg(feature = "loaded")]+ _lib_guard: Option<Arc<Library>>, } /// Vulkan core 1.0 #[allow(non_camel_case_types)]-impl<L> EntryCustom<L> {- pub fn new_custom<Load>(- mut lib: L,- mut load: Load,- ) -> std::result::Result<Self, MissingEntryPoint>- where- Load: FnMut(&mut L, &::std::ffi::CStr) -> *const c_void,- {- // Bypass the normal StaticFn::load so we can return an error- let static_fn = vk::StaticFn::load_checked(|name| load(&mut lib, name))?;+impl Entry {+ /// Load default Vulkan library for the current platform+ ///+ /// Prefer this over [`linked`](Self::linked) when your application can gracefully handle+ /// environments that lack Vulkan support, and when the build environment might not have Vulkan+ /// development packages installed (e.g. the Vulkan SDK, or Ubuntu's `libvulkan-dev`).+ ///+ /// # Safety+ /// `dlopen`ing native libraries is inherently unsafe. The safety guidelines+ /// for [`Library::new()`] and [`Library::get()`] apply here.+ ///+ /// ```no_run+ /// use ash::{vk, Entry};+ /// # fn main() -> Result<(), Box<dyn std::error::Error>> {+ /// let entry = unsafe { Entry::load()? };+ /// let app_info = vk::ApplicationInfo {+ /// api_version: vk::make_api_version(0, 1, 0, 0),+ /// ..Default::default()+ /// };+ /// let create_info = vk::InstanceCreateInfo {+ /// p_application_info: &app_info,+ /// ..Default::default()+ /// };+ /// let instance = unsafe { entry.create_instance(&create_info, None)? };+ /// # Ok(()) }+ /// ```+ #[cfg(feature = "loaded")]+ #[cfg_attr(docsrs, doc(cfg(feature = "loaded")))]+ pub unsafe fn load() -> Result<Self, LoadingError> {+ #[cfg(windows)]+ const LIB_PATH: &str = "vulkan-1.dll";++ #[cfg(all(+ unix,+ not(any(target_os = "macos", target_os = "ios", target_os = "android"))+ ))]+ const LIB_PATH: &str = "libvulkan.so.1";++ #[cfg(target_os = "android")]+ const LIB_PATH: &str = "libvulkan.so";++ #[cfg(any(target_os = "macos", target_os = "ios"))]+ const LIB_PATH: &str = "libvulkan.dylib";++ Self::load_from(LIB_PATH)+ }++ /// Load entry points from a Vulkan loader linked at compile time+ ///+ /// Compared to [`load`](Self::load), this is infallible, but requires that the build+ /// environment have Vulkan development packages installed (e.g. the Vulkan SDK, or Ubuntu's+ /// `libvulkan-dev`), and prevents the resulting binary from starting in environments that do not+ /// support Vulkan.+ ///+ /// Note that instance/device functions are still fetched via `vkGetInstanceProcAddr` and+ /// `vkGetDeviceProcAddr` for maximum performance.+ ///+ /// ```no_run+ /// use ash::{vk, Entry};+ /// # fn main() -> Result<(), Box<dyn std::error::Error>> {+ /// let entry = Entry::linked();+ /// let app_info = vk::ApplicationInfo {+ /// api_version: vk::make_api_version(0, 1, 0, 0),+ /// ..Default::default()+ /// };+ /// let create_info = vk::InstanceCreateInfo {+ /// p_application_info: &app_info,+ /// ..Default::default()+ /// };+ /// let instance = unsafe { entry.create_instance(&create_info, None)? };+ /// # Ok(()) }+ /// ```+ #[cfg(feature = "linked")]+ #[cfg_attr(docsrs, doc(cfg(feature = "linked")))]+ pub fn linked() -> Self {+ // Sound because we're linking to Vulkan, which provides a vkGetInstanceProcAddr that has+ // defined behavior in this use.+ unsafe {+ Self::from_static_fn(vk::StaticFn {+ get_instance_proc_addr: vkGetInstanceProcAddr,+ })+ }+ }++ /// Load Vulkan library at `path`+ ///+ /// # Safety+ /// `dlopen`ing native libraries is inherently unsafe. The safety guidelines+ /// for [`Library::new()`] and [`Library::get()`] apply here.+ #[cfg(feature = "loaded")]+ #[cfg_attr(docsrs, doc(cfg(feature = "loaded")))]+ pub unsafe fn load_from(path: impl AsRef<OsStr>) -> Result<Self, LoadingError> {+ let lib = Library::new(path)+ .map_err(LoadingError::LibraryLoadFailure)+ .map(Arc::new)?;++ let static_fn = vk::StaticFn::load_checked(|name| {+ lib.get(name.to_bytes_with_nul())+ .map(|symbol| *symbol)+ .unwrap_or(ptr::null_mut())+ })?;++ Ok(Self {+ _lib_guard: Some(lib),+ ..Self::from_static_fn(static_fn)+ })+ }++ /// Load entry points based on an already-loaded [`vk::StaticFn`]+ ///+ /// # Safety+ /// `static_fn` must contain valid function pointers that comply with the semantics specified by+ /// Vulkan 1.0, which must remain valid for at least the lifetime of the returned [`Entry`].+ pub unsafe fn from_static_fn(static_fn: vk::StaticFn) -> Self { let load_fn = |name: &std::ffi::CStr| unsafe { mem::transmute(static_fn.get_instance_proc_addr(vk::Instance::null(), name.as_ptr())) };@@ -44,13 +149,14 @@ let entry_fn_1_1 = vk::EntryFnV1_1::load(load_fn); let entry_fn_1_2 = vk::EntryFnV1_2::load(load_fn);- Ok(EntryCustom {+ Self { static_fn, entry_fn_1_0, entry_fn_1_1, entry_fn_1_2,- lib,- })+ #[cfg(feature = "loaded")]+ _lib_guard: None,+ } } pub fn fp_v1_0(&self) -> &vk::EntryFnV1_0 {@@ -65,7 +171,7 @@ /// ```no_run /// # use ash::{Entry, vk}; /// # fn main() -> Result<(), Box<dyn std::error::Error>> {- /// let entry = unsafe { Entry::new() }?;+ /// let entry = Entry::linked(); /// match entry.try_enumerate_instance_version()? { /// // Vulkan 1.1+ /// Some(version) => {@@ -107,7 +213,7 @@ &self, create_info: &vk::InstanceCreateInfo, allocation_callbacks: Option<&vk::AllocationCallbacks>,- ) -> Result<Instance, InstanceError> {+ ) -> VkResult<Instance> { let mut instance = mem::zeroed(); self.entry_fn_1_0 .create_instance(@@ -115,8 +221,7 @@ allocation_callbacks.as_raw_ptr(), &mut instance, )- .result()- .map_err(InstanceError::VkError)?;+ .result()?; Ok(Instance::load(&self.static_fn, instance)) }@@ -154,7 +259,7 @@ /// Vulkan core 1.1 #[allow(non_camel_case_types)]-impl<L> EntryCustom<L> {+impl Entry { pub fn fp_v1_1(&self) -> &vk::EntryFnV1_1 { &self.entry_fn_1_1 }@@ -175,28 +280,19 @@ /// Vulkan core 1.2 #[allow(non_camel_case_types)]-impl<L> EntryCustom<L> {+impl Entry { pub fn fp_v1_2(&self) -> &vk::EntryFnV1_2 { &self.entry_fn_1_2 } }-#[derive(Clone, Debug)]-pub enum InstanceError {- LoadError(Vec<&'static str>),- VkError(vk::Result),-}--impl fmt::Display for InstanceError {- fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {- match self {- InstanceError::LoadError(e) => write!(f, "{}", e.join("; ")),- InstanceError::VkError(e) => write!(f, "{}", e),- }- }-}--impl Error for InstanceError {}+#[cfg(feature = "linked")]+#[cfg_attr(docsrs, doc(cfg(feature = "linked")))]+impl Default for Entry {+ fn default() -> Self {+ Self::linked()+ }+} impl vk::StaticFn { pub fn load_checked<F>(mut _f: F) -> Result<Self, MissingEntryPoint>@@ -206,7 +302,7 @@ // TODO: Make this a &'static CStr once CStr::from_bytes_with_nul_unchecked is const static ENTRY_POINT: &[u8] = b"vkGetInstanceProcAddr\0";- Ok(vk::StaticFn {+ Ok(Self { get_instance_proc_addr: unsafe { let cname = CStr::from_bytes_with_nul_unchecked(ENTRY_POINT); let val = _f(cname);@@ -228,3 +324,50 @@ } } impl std::error::Error for MissingEntryPoint {}++#[cfg(feature = "linked")]+extern "system" {+ fn vkGetInstanceProcAddr(instance: vk::Instance, name: *const c_char)+ -> vk::PFN_vkVoidFunction;+}++#[cfg(feature = "loaded")]+mod loaded {+ use std::error::Error;+ use std::fmt;++ use super::*;++ #[derive(Debug)]+ #[cfg_attr(docsrs, doc(cfg(feature = "loaded")))]+ pub enum LoadingError {+ LibraryLoadFailure(libloading::Error),+ MissingEntryPoint(MissingEntryPoint),+ }++ impl fmt::Display for LoadingError {+ fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {+ match self {+ LoadingError::LibraryLoadFailure(err) => fmt::Display::fmt(err, f),+ LoadingError::MissingEntryPoint(err) => fmt::Display::fmt(err, f),+ }+ }+ }++ impl Error for LoadingError {+ fn source(&self) -> Option<&(dyn Error + 'static)> {+ Some(match self {+ LoadingError::LibraryLoadFailure(err) => err,+ LoadingError::MissingEntryPoint(err) => err,+ })+ }+ }++ impl From<MissingEntryPoint> for LoadingError {+ fn from(err: MissingEntryPoint) -> Self {+ Self::MissingEntryPoint(err)+ }+ }+}+#[cfg(feature = "loaded")]+pub use self::loaded::*;
I'll analyze the code diff for security vulnerabilities. Here's my analysis: Vulnerability Existed: not sure Potential DLL Hijacking [File] third_party/rust/ash/src/entry.rs [Lines related to library loading] [Old Code] The old code didn't show explicit library loading mechanisms [Fixed Code] The new code includes explicit library loading with paths for different platforms (vulkan-1.dll, libvulkan.so.1, etc.) Additional Details: - The change adds platform-specific library paths which could help prevent DLL hijacking by being explicit about expected library names - However, without seeing the old implementation, I can't be certain if this was fixing an existing vulnerability or just improving the code Vulnerability Existed: not sure Unsafe Library Loading [File] third_party/rust/ash/src/entry.rs [Lines related to unsafe blocks] [Old Code] The old code had custom loading mechanisms that aren't shown in the diff [Fixed Code] The new code uses libloading crate with proper error handling and safety documentation Additional Details: - The new code properly marks unsafe operations and documents safety requirements - It adds better error handling through the LoadingError enum - This appears to be an improvement in safety, but without seeing the old implementation, I can't confirm if it was fixing a specific vulnerability Vulnerability Existed: not sure Memory Safety in Function Pointer Loading [File] third_party/rust/ash/src/entry.rs [Lines related to get_instance_proc_addr] [Old Code] Previous implementation details not shown [Fixed Code] New implementation includes checked loading and proper null pointer handling Additional Details: - The new code includes load_checked() function that validates function pointers - It properly handles null pointer cases when loading symbols - This improves memory safety but may not be fixing a specific known vulnerability Note: The diff shows significant improvements in safety and error handling, but without seeing the exact vulnerabilities in the old code or security advisories related to this change, I can't definitively state what specific vulnerabilities were fixed. The changes appear to be proactive safety improvements rather than fixes for known vulnerabilities.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/syn/src/stmt.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/syn/src/stmt.rs@@ -50,7 +50,7 @@ pub mod parsing { use super::*; use crate::parse::discouraged::Speculative;- use crate::parse::{Parse, ParseStream, Result};+ use crate::parse::{Parse, ParseBuffer, ParseStream, Result}; use proc_macro2::TokenStream; impl Block {@@ -152,6 +152,7 @@ } fn parse_stmt(input: ParseStream, allow_nosemi: bool) -> Result<Stmt> {+ let begin = input.fork(); let mut attrs = input.call(Attribute::parse_outer)?; // brace-style macros; paren and bracket macros get parsed as@@ -169,7 +170,7 @@ } if input.peek(Token![let]) {- stmt_local(input, attrs)+ stmt_local(input, attrs, begin) } else if input.peek(Token![pub]) || input.peek(Token![crate]) && !input.peek2(Token![::]) || input.peek(Token![extern])@@ -222,9 +223,7 @@ }))) }- fn stmt_local(input: ParseStream, attrs: Vec<Attribute>) -> Result<Stmt> {- let begin = input.fork();-+ fn stmt_local(input: ParseStream, attrs: Vec<Attribute>, begin: ParseBuffer) -> Result<Stmt> { let let_token: Token![let] = input.parse()?; let mut pat: Pat = pat::parsing::multi_pat_with_leading_vert(input)?;
Analyzing the provided code diff, I don't see any clear security vulnerabilities being fixed. The changes appear to be primarily refactoring and code organization improvements. However, I'll analyze it according to the requested format:
1. Vulnerability Existed: no
No specific vulnerability [third_party/rust/syn/src/stmt.rs] [Lines 50,152,170,222-223]
Old Code: `use crate::parse::{Parse, ParseStream, Result};` and related function signatures
Fixed Code: Added `ParseBuffer` to imports and modified function signatures to accept `begin` parameter
The main changes are:
1. Adding `ParseBuffer` to the imports
2. Moving the `input.fork()` call earlier in `parse_stmt` and passing it to `stmt_local`
3. Modifying `stmt_local` to accept the `begin` parameter rather than creating it internally
These changes appear to be about code organization and potentially performance (avoiding redundant forking), but I don't see any security implications in this diff. There are no changes to security-critical operations like input validation, memory management, or access control.
No known vulnerability patterns (e.g., injection, XSS, memory safety issues) are being addressed here. The changes seem to be internal API improvements to the Rust parser implementation.
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/src/task.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/async-task/src/task.rs@@ -124,18 +124,56 @@ pub async fn cancel(self) -> Option<T> { let mut this = self; this.set_canceled();-- struct Fut<T>(Task<T>);-- impl<T> Future for Fut<T> {- type Output = Option<T>;-- fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {- self.0.poll_task(cx)- }- }-- Fut(this).await+ this.fallible().await+ }++ /// Converts this task into a [`FallibleTask`].+ ///+ /// Like [`Task`], a fallible task will poll the task's output until it is+ /// completed or cancelled due to its [`Runnable`][`super::Runnable`] being+ /// dropped without being run. Resolves to the task's output when completed,+ /// or [`None`] if it didn't complete.+ ///+ /// # Examples+ ///+ /// ```+ /// use smol::{future, Executor};+ /// use std::thread;+ ///+ /// let ex = Executor::new();+ ///+ /// // Spawn a future onto the executor.+ /// let task = ex.spawn(async {+ /// println!("Hello from a task!");+ /// 1 + 2+ /// })+ /// .fallible();+ ///+ /// // Run an executor thread.+ /// thread::spawn(move || future::block_on(ex.run(future::pending::<()>())));+ ///+ /// // Wait for the task's output.+ /// assert_eq!(future::block_on(task), Some(3));+ /// ```+ ///+ /// ```+ /// use smol::future;+ ///+ /// // Schedule function which drops the runnable without running it.+ /// let schedule = move |runnable| drop(runnable);+ ///+ /// // Create a task with the future and the schedule function.+ /// let (runnable, task) = async_task::spawn(async {+ /// println!("Hello from a task!");+ /// 1 + 2+ /// }, schedule);+ /// runnable.schedule();+ ///+ /// // Wait for the task's output.+ /// assert_eq!(future::block_on(task.fallible()), None);+ /// ```+ pub fn fallible(self) -> FallibleTask<T> {+ FallibleTask { task: self } } /// Puts the task in canceled state.@@ -351,6 +389,12 @@ } } }++ fn header(&self) -> &Header {+ let ptr = self.ptr.as_ptr();+ let header = ptr as *const Header;+ unsafe { &*header }+ } } impl<T> Drop for Task<T> {@@ -373,11 +417,101 @@ impl<T> fmt::Debug for Task<T> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {- let ptr = self.ptr.as_ptr();- let header = ptr as *const Header;- f.debug_struct("Task")- .field("header", unsafe { &(*header) })+ .field("header", self.header()) .finish() } }++/// A spawned task with a fallible response.+///+/// This type behaves like [`Task`], however it produces an `Option<T>` when+/// polled and will return `None` if the executor dropped its+/// [`Runnable`][`super::Runnable`] without being run.+///+/// This can be useful to avoid the panic produced when polling the `Task`+/// future if the executor dropped its `Runnable`.+#[must_use = "tasks get canceled when dropped, use `.detach()` to run them in the background"]+pub struct FallibleTask<T> {+ task: Task<T>,+}++impl<T> FallibleTask<T> {+ /// Detaches the task to let it keep running in the background.+ ///+ /// # Examples+ ///+ /// ```+ /// use smol::{Executor, Timer};+ /// use std::time::Duration;+ ///+ /// let ex = Executor::new();+ ///+ /// // Spawn a deamon future.+ /// ex.spawn(async {+ /// loop {+ /// println!("I'm a daemon task looping forever.");+ /// Timer::after(Duration::from_secs(1)).await;+ /// }+ /// })+ /// .fallible()+ /// .detach();+ /// ```+ pub fn detach(self) {+ self.task.detach()+ }++ /// Cancels the task and waits for it to stop running.+ ///+ /// Returns the task's output if it was completed just before it got canceled, or [`None`] if+ /// it didn't complete.+ ///+ /// While it's possible to simply drop the [`Task`] to cancel it, this is a cleaner way of+ /// canceling because it also waits for the task to stop running.+ ///+ /// # Examples+ ///+ /// ```+ /// use smol::{future, Executor, Timer};+ /// use std::thread;+ /// use std::time::Duration;+ ///+ /// let ex = Executor::new();+ ///+ /// // Spawn a deamon future.+ /// let task = ex.spawn(async {+ /// loop {+ /// println!("Even though I'm in an infinite loop, you can still cancel me!");+ /// Timer::after(Duration::from_secs(1)).await;+ /// }+ /// })+ /// .fallible();+ ///+ /// // Run an executor thread.+ /// thread::spawn(move || future::block_on(ex.run(future::pending::<()>())));+ ///+ /// future::block_on(async {+ /// Timer::after(Duration::from_secs(3)).await;+ /// task.cancel().await;+ /// });+ /// ```+ pub async fn cancel(self) -> Option<T> {+ self.task.cancel().await+ }+}++impl<T> Future for FallibleTask<T> {+ type Output = Option<T>;++ fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {+ self.task.poll_task(cx)+ }+}++impl<T> fmt::Debug for FallibleTask<T> {+ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {+ f.debug_struct("FallibleTask")+ .field("header", self.task.header())+ .finish()+ }+}
Let me analyze the code diff for potential security vulnerabilities: 1. Vulnerability Existed: not sure [Potential Unsafe Pointer Dereference] [third_party/rust/async-task/src/task.rs] [Lines 351-373] [Old Code] - No explicit header() method, direct unsafe pointer dereference in Debug impl [Fixed Code] + Added header() method that performs unsafe pointer dereference + Now used consistently in Debug implementations 2. Vulnerability Existed: yes [Potential Task Cancellation Race Condition] [third_party/rust/async-task/src/task.rs] [Lines 124-126] [Old Code] - Directly polled task after setting canceled flag [Fixed Code] + Uses new fallible() method which provides safer cancellation handling + Introduces FallibleTask type for more robust cancellation handling 3. Vulnerability Existed: not sure [Potential Memory Safety Issue] [third_party/rust/async-task/src/task.rs] [Lines 389-393] [Old Code] - No header() method existed [Fixed Code] + Added header() method with unsafe pointer cast and dereference + Could potentially be unsafe if ptr is invalid The main security-related changes appear to be: 1. The introduction of safer task cancellation handling through FallibleTask 2. Consolidation of unsafe pointer operations into a single method 3. More robust error handling for dropped runnables While these changes improve safety, I can't definitively say whether they fix specific known vulnerabilities without more context about previous issues. The changes appear to be proactive improvements rather than fixes for known security bugs.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/layout/generic/nsIScrollableFrame.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/layout/generic/nsIScrollableFrame.h@@ -143,9 +143,8 @@ /** * Return the width for non-disappearing scrollbars. */- virtual nscoord GetNondisappearingScrollbarWidth(- nsPresContext* aPresContext, gfxContext* aRC,- mozilla::WritingMode aWM) = 0;+ static nscoord GetNondisappearingScrollbarWidth(nsPresContext*,+ mozilla::WritingMode); /** * Get the layout size of this frame. * Note that this is a value which is not expanded by the minimum scale size.@@ -374,12 +373,6 @@ virtual bool IsScrollingActive() = 0; /**- * The same as IsScrollingActive but minimal display ports are not considered- * active.- */- virtual bool IsScrollingActiveNotMinimalDisplayPort() = 0;-- /** * Returns true if this scroll frame might be scrolled * asynchronously by the compositor. */@@ -433,7 +426,13 @@ * Returns the current generation counter for the scrollframe. This counter * increments every time the scroll position is set. */- virtual mozilla::ScrollGeneration CurrentScrollGeneration() const = 0;+ virtual mozilla::MainThreadScrollGeneration CurrentScrollGeneration()+ const = 0;+ /**+ * The APZ scroll generation associated with the last APZ scroll offset for+ * which we processed a repaint request.+ */+ virtual mozilla::APZScrollGeneration ScrollGenerationOnApz() const = 0; /** * LastScrollDestination returns the destination of the most recently * requested smooth scroll animation.@@ -457,7 +456,8 @@ * animation. */ virtual void ResetScrollInfoIfNeeded(- const mozilla::ScrollGeneration& aGeneration,+ const mozilla::MainThreadScrollGeneration& aGeneration,+ const mozilla::APZScrollGeneration& aGenerationOnApz, mozilla::APZScrollAnimationType aAPZScrollAnimationType) = 0; /** * Determine whether it is desirable to be able to asynchronously scroll this
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: not sure [Potential Type Safety Issue] [File: nsIScrollableFrame.h] [Lines: 433-434] [Old Code] virtual mozilla::ScrollGeneration CurrentScrollGeneration() const = 0; [Fixed Code] virtual mozilla::MainThreadScrollGeneration CurrentScrollGeneration() const = 0; 2. Vulnerability Existed: not sure [Potential Race Condition] [File: nsIScrollableFrame.h] [Lines: 457-458] [Old Code] virtual void ResetScrollInfoIfNeeded(const mozilla::ScrollGeneration& aGeneration, mozilla::APZScrollAnimationType aAPZScrollAnimationType) = 0; [Fixed Code] virtual void ResetScrollInfoIfNeeded(const mozilla::MainThreadScrollGeneration& aGeneration, const mozilla::APZScrollGeneration& aGenerationOnApz, mozilla::APZScrollAnimationType aAPZScrollAnimationType) = 0; 3. Vulnerability Existed: not sure [Potential Information Leak] [File: nsIScrollableFrame.h] [Lines: 374-379] [Old Code] virtual bool IsScrollingActiveNotMinimalDisplayPort() = 0; [Fixed Code] [Removed function] Notes: - The changes appear to be related to scroll generation handling and synchronization between main thread and APZ (Asynchronous Pan/Zoom) - The introduction of separate MainThreadScrollGeneration and APZScrollGeneration types suggests potential fixes for race conditions or synchronization issues - The removal of IsScrollingActiveNotMinimalDisplayPort() might indicate a security-related simplification of the API - Without more context about the implementation details, it's difficult to determine if these were actual security vulnerabilities or just architectural improvements
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.roundrect.newsubpath.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.newsubpath.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'; ctx.fillRect(0, 0, 100, 50);@@ -29,7 +29,7 @@ ctx.lineTo(-50, 25); ctx.roundRect(200, 25, 1, 1, [0]); ctx.stroke();-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });
Based on the provided code diff, I'll analyze it for security vulnerabilities:
1. Vulnerability Existed: no
No security vulnerability found [File] [Lines 17-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 appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) with no security implications. The functionality remains identical, and there are no security-related patterns being modified. This seems to be a code style/readability change 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/layout/reftests/css-grid/grid-fragmentation-024.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/layout/reftests/css-grid/grid-fragmentation-024.html@@ -23,7 +23,7 @@ -ms-column-fill: auto; -webkit-column-fill: auto; column-fill: auto;- border: 2px dashed;+ border: 2px solid salmon; margin-bottom: 5px; }
Based on the provided code diff, this appears to be a visual test case change rather than a security fix. Here's the analysis: Vulnerability Existed: no [Visual Test Update] [layout/reftests/css-grid/grid-fragmentation-024.html] [Lines 23] [Old Code] border: 2px dashed; [Fixed Code] border: 2px solid salmon; Additional Details: - The change modifies the border style from dashed to solid and adds a color (salmon) - This appears to be purely a visual/rendering test update with no security implications - No known vulnerability is being addressed by this change - The modification is likely for better visual clarity in test results There are no security vulnerabilities being fixed in this diff. The change is cosmetic in nature, affecting only how the test case is displayed rather than any security-related functionality.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.canvas.alpha.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.canvas.alpha.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 offscreenCanvas2 = new OffscreenCanvas(100, 50); var ctx2 = offscreenCanvas2.getContext('2d');@@ -29,7 +29,7 @@ ctx.shadowOffsetY = 50; ctx.shadowColor = '#00f'; ctx.drawImage(offscreenCanvas2, 0, -50);-_assertPixelApprox(offscreenCanvas, 50,25, 127,0,127,255, "50,25", "127,0,127,255", 2);+_assertPixelApprox(canvas, 50,25, 127,0,127,255, "50,25", "127,0,127,255", 2); t.done(); });
Based on the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming and don't involve any security-related modifications.
Here's the analysis following your requested format:
Vulnerability Existed: no
[No security vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.canvas.alpha.html] [Lines 17-29]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixelApprox(offscreenCanvas, 50,25, 127,0,127,255, "50,25", "127,0,127,255", 2);
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixelApprox(canvas, 50,25, 127,0,127,255, "50,25", "127,0,127,255", 2);
The changes are:
1. Renaming variable `offscreenCanvas` to `canvas`
2. Updating the variable name in the `_assertPixelApprox` call
3. No security implications in 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/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.uncovered.pattern.destination-atop.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.uncovered.pattern.destination-atop.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = 'rgba(0, 255, 255, 0.5)';@@ -33,7 +33,7 @@ createImageBitmap(response).then(bitmap => { ctx.fillStyle = ctx.createPattern(bitmap, 'no-repeat'); ctx.fillRect(0, 50, 100, 50);- _assertPixelApprox(offscreenCanvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0", 5);+ _assertPixelApprox(canvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0", 5); }, t_fail); }).then(t_pass, t_fail);
After analyzing the provided code diff, here's the security assessment:
Vulnerability Existed: no
[No specific vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.uncovered.pattern.destination-atop.worker.js] [Lines 13-14, 33]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixelApprox(offscreenCanvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0", 5);
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixelApprox(canvas, 50,25, 0,0,0,0, "50,25", "0,0,0,0", 5);
The changes appear to be purely cosmetic/refactoring, renaming the variable from 'offscreenCanvas' to 'canvas' for consistency or clarity. There are no security-related changes in this diff. The functionality remains the same, only the variable name has been updated.
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.svg-1.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.svg-1.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 = 'gray'; ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 128,128,128,255, "50,25", "128,128,128,255");+_assertPixel(canvas, 50,25, 128,128,128,255, "50,25", "128,128,128,255"); t.done(); });
Based on the provided diff, I'll analyze it for potential security vulnerabilities:
1. Vulnerability Existed: no
No specific vulnerability found [File] [Lines 17-25]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
ctx.fillStyle = '#f00';
ctx.fillStyle = 'gray';
ctx.fillRect(0, 0, 100, 50);
_assertPixel(offscreenCanvas, 50,25, 128,128,128,255, "50,25", "128,128,128,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
ctx.fillStyle = '#f00';
ctx.fillStyle = 'gray';
ctx.fillRect(0, 0, 100, 50);
_assertPixel(canvas, 50,25, 128,128,128,255, "50,25", "128,128,128,255");
The changes appear to be purely cosmetic/refactoring, renaming the variable `offscreenCanvas` to `canvas` and updating the corresponding references. There's no indication of any security vulnerability being fixed in this change. The functionality remains exactly the same, just with a different variable name.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.css-color-4-hsl-6.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-hsl-6.html@@ -17,14 +17,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillStyle = 'hsl(120deg, 100.0%, 50.0%)'; 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 don't see any security-related changes. The changes appear to be purely variable renaming and don't involve any security fixes. Here's the analysis following your 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-hsl-6.html] [Lines 17-25]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes are:
1. Renamed variable `offscreenCanvas` to `canvas`
2. Updated the variable name in the `_assertPixel` call
These changes don't appear to address any security vulnerabilities but rather improve code consistency or readability.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/browser/app/profile/firefox.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/app/profile/firefox.js@@ -123,6 +123,18 @@ // How many times we should let an elevation prompt fail before prompting the user to // download a fresh installer. pref("app.update.elevation.promptMaxAttempts", 2);++#ifdef NIGHTLY_BUILD+ // Whether to delay popup notifications when an update is available and+ // suppress them when an update is installed and waiting for user to restart.+ // If set to true, these notifications will immediately be shown as banners in+ // the app menu and as badges on the app menu button. Update available+ // notifications will not create popup prompts until a week has passed without+ // the user installing the update. Update restart notifications will not+ // create popup prompts at all. This doesn't affect update notifications+ // triggered by errors/failures or manual install prompts.+ pref("app.update.suppressPrompts", false);+#endif // If set to true, a message will be displayed in the hamburger menu while // an update is being downloaded.@@ -490,6 +502,9 @@ // Comma-separated list of client variants to send to Merino pref("browser.urlbar.merino.clientVariants", "");+// Whether best match results are enabled in the urlbar.+pref("browser.urlbar.bestMatch.enabled", true);+ pref("browser.altClickSave", false); // Enable logging downloads operations to the Console.@@ -532,6 +547,13 @@ // Controls whether to open the downloads panel every time a download begins. // The first download ever run in a new profile will still open the panel. pref("browser.download.alwaysOpenPanel", true);++// Determines the behavior of the "Delete" item in the downloads context menu.+// Valid values are 0, 1, and 2.+// 0 - Don't remove the download from session list or history.+// 1 - Remove the download from session list, but not history.+// 2 - Remove the download from both session list and history.+pref("browser.download.clearHistoryOnDelete", 0); #ifndef XP_MACOSX pref("browser.helperApps.deleteTempFileOnExit", true);@@ -545,6 +567,9 @@ pref("browser.helperApps.showOpenOptionForPdfJS", true); pref("browser.helperApps.showOpenOptionForViewableInternally", true);+// search engine removal URL+pref("browser.search.searchEngineRemoval", "https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/search-engine-removal");+ // search engines URL pref("browser.search.searchEnginesURL", "https://addons.mozilla.org/%LOCALE%/firefox/search-engines/");@@ -568,6 +593,19 @@ // Enables the display of the Mozilla VPN banner in private browsing windows pref("browser.privatebrowsing.vpnpromourl", "https://vpn.mozilla.org/?utm_source=firefox-browser&utm_medium=firefox-%CHANNEL%-browser&utm_campaign=private-browsing-vpn-link");++// Whether the user is opted-in to privacy segmentation.+pref("browser.privacySegmentation.enabled", false);++// Use dark theme variant for PBM windows. This is only supported if the theme+// sets darkTheme data.+pref("browser.theme.dark-private-windows", false);++// Controls visibility of the privacy segmentation preferences section.+pref("browser.privacySegmentation.preferences.show", false);++// Suffix for the SUMO learn more link for the privacy segmentation checkbox.+pref("browser.privacySegmentation.preferences.learnMoreURLSuffix", "data-features"); pref("browser.sessionhistory.max_entries", 50);@@ -959,7 +997,7 @@ #else pref("browser.preferences.experimental", false); #endif-pref("browser.preferences.moreFromMozilla", false);+pref("browser.preferences.moreFromMozilla", true); pref("browser.preferences.experimental.hidden", false); pref("browser.preferences.defaultPerformanceSettings.enabled", true);@@ -981,57 +1019,6 @@ pref("layout.spellcheckDefault", 1); pref("browser.send_pings", false);--// At startup, if the handler service notices that the version number in the-// region.properties file is newer than the version number in the handler-// service datastore, it will add any new handlers it finds in the prefs (as-// seeded by this file) to its datastore.-pref("gecko.handlerService.defaultHandlersVersion", "chrome://browser-region/locale/region.properties");--// The default set of web-based protocol handlers shown in the application-// selection dialog for webcal: ; I've arbitrarily picked 4 default handlers-// per protocol, but if some locale wants more than that (or defaults for some-// protocol not currently listed here), we should go ahead and add those.--// webcal-pref("gecko.handlerService.schemes.webcal.0.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.webcal.0.uriTemplate", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.webcal.1.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.webcal.1.uriTemplate", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.webcal.2.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.webcal.2.uriTemplate", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.webcal.3.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.webcal.3.uriTemplate", "chrome://browser-region/locale/region.properties");--// mailto-pref("gecko.handlerService.schemes.mailto.0.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.mailto.0.uriTemplate", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.mailto.1.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.mailto.1.uriTemplate", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.mailto.2.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.mailto.2.uriTemplate", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.mailto.3.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.mailto.3.uriTemplate", "chrome://browser-region/locale/region.properties");--// irc-pref("gecko.handlerService.schemes.irc.0.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.irc.0.uriTemplate", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.irc.1.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.irc.1.uriTemplate", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.irc.2.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.irc.2.uriTemplate", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.irc.3.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.irc.3.uriTemplate", "chrome://browser-region/locale/region.properties");--// ircs-pref("gecko.handlerService.schemes.ircs.0.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.ircs.0.uriTemplate", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.ircs.1.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.ircs.1.uriTemplate", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.ircs.2.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.ircs.2.uriTemplate", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.ircs.3.name", "chrome://browser-region/locale/region.properties");-pref("gecko.handlerService.schemes.ircs.3.uriTemplate", "chrome://browser-region/locale/region.properties"); pref("browser.geolocation.warning.infoURL", "https://www.mozilla.org/%LOCALE%/firefox/geolocation/"); pref("browser.xr.warning.infoURL", "https://www.mozilla.org/%LOCALE%/firefox/xr/");@@ -1142,6 +1129,9 @@ // selects "Forget About This Site". pref("places.forgetThisSite.clearByBaseDomain", true);+// Whether to warm up network connections for places: menus and places: toolbar.+pref("browser.places.speculativeConnect.enabled", true);+ // Controls behavior of the "Add Exception" dialog launched from SSL error pages // 0 - don't pre-populate anything // 1 - pre-populate site URL, but don't fetch certificate@@ -1192,6 +1182,10 @@ // The number of recently selected folders in the edit bookmarks dialog. pref("browser.bookmarks.editDialog.maxRecentFolders", 7);++// By default the Edit Bookmark dialog is instant-apply. This feature pref will allow to+// just save on Accept, once the project is complete.+pref("browser.bookmarks.editDialog.delayedApply.enabled", false); pref("dom.ipc.plugins.flash.disable-protected-mode", false);@@ -1491,7 +1485,7 @@ // this page over http opens us up to a man-in-the-middle attack that we'd rather not face. If you are a downstream // repackager of this code using an alternate snippet url, please keep your users safe pref("browser.newtabpage.activity-stream.asrouter.providers.snippets", "{\"id\":\"snippets\",\"enabled\":false,\"type\":\"remote\",\"url\":\"https://snippets.cdn.mozilla.net/%STARTPAGE_VERSION%/%NAME%/%VERSION%/%APPBUILDID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/\",\"updateCycleInMs\":14400000}");-pref("browser.newtabpage.activity-stream.asrouter.providers.messaging-experiments", "{\"id\":\"messaging-experiments\",\"enabled\":true,\"type\":\"remote-experiments\",\"messageGroups\":[\"cfr\",\"aboutwelcome\",\"infobar\",\"spotlight\",\"moments-page\"],\"updateCycleInMs\":3600000}");+pref("browser.newtabpage.activity-stream.asrouter.providers.messaging-experiments", "{\"id\":\"messaging-experiments\",\"enabled\":true,\"type\":\"remote-experiments\",\"messageGroups\":[\"cfr\",\"aboutwelcome\",\"infobar\",\"spotlight\",\"moments-page\",\"pbNewtab\"],\"updateCycleInMs\":3600000}"); // ASRouter user prefs pref("browser.newtabpage.activity-stream.asrouter.userprefs.cfr.addons", true);@@ -1509,7 +1503,11 @@ // These prefs control if Discovery Stream is enabled. pref("browser.newtabpage.activity-stream.discoverystream.enabled", true); pref("browser.newtabpage.activity-stream.discoverystream.hardcoded-basic-layout", false);+// A preset compact layout, similar to setting a collection of prefs to build a complete layout. pref("browser.newtabpage.activity-stream.discoverystream.compactLayout.enabled", false);+pref("browser.newtabpage.activity-stream.discoverystream.hybridLayout.enabled", false);+pref("browser.newtabpage.activity-stream.discoverystream.hideCardBackground.enabled", false);+pref("browser.newtabpage.activity-stream.discoverystream.fourCardLayout.enabled", false); pref("browser.newtabpage.activity-stream.discoverystream.loadMore.enabled", false); pref("browser.newtabpage.activity-stream.discoverystream.lastCardMessage.enabled", false); pref("browser.newtabpage.activity-stream.discoverystream.newFooterSection.enabled", false);@@ -1524,7 +1522,7 @@ pref("browser.newtabpage.activity-stream.discoverystream.newSponsoredLabel.enabled", false); pref("browser.newtabpage.activity-stream.discoverystream.essentialReadsHeader.enabled", false); pref("browser.newtabpage.activity-stream.discoverystream.editorsPicksHeader.enabled", false);-pref("browser.newtabpage.activity-stream.discoverystream.spoc-positions", "2,4,11,20");+pref("browser.newtabpage.activity-stream.discoverystream.spoc-positions", "1,5,7,11,18,20"); pref("browser.newtabpage.activity-stream.discoverystream.spocs-endpoint", ""); pref("browser.newtabpage.activity-stream.discoverystream.spocs-endpoint-query", "");@@ -1561,6 +1559,9 @@ // The pref controls if search hand-off is enabled for Activity Stream. pref("browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar", true);++// This pref controls the visibility of Colorway Closet settings in the customize panel+pref("browser.newtabpage.activity-stream.colorway-closet.enabled", false); pref("browser.newtabpage.activity-stream.logowordmark.alwaysVisible", true);@@ -1879,6 +1880,10 @@ // Disable the mobile promotion by default. pref("browser.contentblocking.report.show_mobile_app", true);+// Locales in which Send to Device emails are supported+// The most recent list of supported locales can be found at https://github.com/mozilla/bedrock/blob/6a08c876f65924651554decc57b849c00874b4e7/bedrock/settings/base.py#L963+pref("browser.send_to_device_locales", "de,en-GB,en-US,es-AR,es-CL,es-ES,es-MX,fr,id,pl,pt-BR,ru,zh-TW");+ // Avoid advertising in certain regions. Comma separated string of two letter ISO 3166-1 country codes. // We're currently blocking all of Ukraine (ua), but would prefer to block just Crimea (ua-43). Currently, the Mozilla Location Service APIs used by Region.jsm only exposes the country, not the subdivision. pref("browser.vpn_promo.disallowed_regions", "ae,by,cn,cu,iq,ir,kp,om,ru,sd,sy,tm,tr,ua");@@ -2157,6 +2162,12 @@ // AMO only serves language packs for release and beta versions. pref("intl.multilingual.downloadEnabled", false); #endif+// With the preference enabled below, switching the browser language will do a live+// reload rather than requiring a restart. Enable bidirectional below as well to allow+// live reloading when switching between LTR and RTL languages.+pref("intl.multilingual.liveReload", false);+pref("intl.multilingual.liveReloadBidirectional", false);+ // Simulate conditions that will happen when the browser // is running with Fission enabled. This is meant to assist@@ -2239,6 +2250,10 @@ // In DevTools, create a target for each frame (i.e. not only for top-level document and // remote frames). pref("devtools.every-frame-target.enabled", true);++// Controls the hability to debug popups from the same DevTools+// of the original tab the popups are coming from+pref("devtools.popups.debug", false); // Toolbox Button preferences pref("devtools.command-button-pick.enabled", true);@@ -2276,11 +2291,7 @@ // Enable the inline CSS compatiblity warning in inspector rule view pref("devtools.inspector.ruleview.inline-compatibility-warning.enabled", false); // Enable the compatibility tool in the inspector.-#if defined(NIGHTLY_BUILD) || defined(MOZ_DEV_EDITION) pref("devtools.inspector.compatibility.enabled", true);-#else-pref("devtools.inspector.compatibility.enabled", false);-#endif // Enable overflow debugging in the inspector. pref("devtools.overflow.debugging.enabled", true);@@ -2388,6 +2399,13 @@ // Enable the Application panel pref("devtools.application.enabled", true);+// Enable the custom formatters feature+// TODO remove once the custom formatters feature is stable (see bug 1734614)+pref("devtools.custom-formatters", false);+// This preference represents the user's choice to enable the custom formatters feature.+// While the preference above will be removed once the feature is stable, this one is menat to stay.+pref("devtools.custom-formatters.enabled", false);+ // The default Network Monitor UI settings pref("devtools.netmonitor.panes-network-details-width", 550); pref("devtools.netmonitor.panes-network-details-height", 450);@@ -2515,12 +2533,8 @@ // Display an onboarding UI for the Editor mode. pref("devtools.webconsole.input.editorOnboarding", true);-// Enable the new performance recording panel in Nightly and Beta/DevEdition builds.-#if defined(NIGHTLY_BUILD) || defined(MOZ_DEV_EDITION)- pref("devtools.performance.new-panel-enabled", true);-#else- pref("devtools.performance.new-panel-enabled", false);-#endif+// Enable the new performance panel in all channels of Firefox.+pref("devtools.performance.new-panel-enabled", true); // Enable message grouping in the console, true by default pref("devtools.webconsole.groupWarningMessages", true);
After analyzing the provided code diff, I don't find any clear security vulnerabilities being fixed. The changes appear to be primarily feature additions, preference modifications, and configuration updates rather than security patches. Here's my analysis: 1. Vulnerability Existed: no No specific vulnerability - File: browser/app/profile/firefox.js The changes are mostly preference additions/modifications without security implications 2. Vulnerability Existed: no No specific vulnerability - File: browser/app/profile/firefox.js The diff shows new features being added (like privacy segmentation, dark theme for private windows) rather than security fixes 3. Vulnerability Existed: no No specific vulnerability - File: browser/app/profile/firefox.js The changes to messaging-experiments and discoverystream configurations appear to be feature updates The diff shows numerous changes, but they are primarily: - New preference additions - Default value changes - Feature flag additions - Configuration updates - UI/UX improvements None of these changes appear to address specific security vulnerabilities. The modifications seem focused on adding new functionality, improving existing features, and adjusting default behaviors rather than patching security issues. If there were security fixes in this diff, they would likely be more clearly marked or accompanied by security-related comments, which I don't see in this case. The changes appear to be part of normal feature development and maintenance between Firefox versions 97 and 98. Would you like me to examine any specific part of the diff more closely for potential 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/browser/base/content/browser.css+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/base/content/browser.css@@ -200,14 +200,6 @@ max-width: 0.1px; min-width: 0.1px; visibility: hidden;-}--.tab-icon-image[fadein],-.tab-close-button[fadein],-.tabbrowser-tab[fadein]::after,-.tab-background[fadein] {- /* This transition is only wanted for opening tabs. */- transition: visibility 0ms 25ms; } .tab-icon-pending:not([fadein]),
Analysis of the provided CSS diff:
1. Vulnerability Existed: not sure
[Potential Styling Timing Attack] [browser/base/content/browser.css] [Lines 200-208]
[Old Code]
.tab-icon-image[fadein],
.tab-close-button[fadein],
.tabbrowser-tab[fadein]::after,
.tab-background[fadein] {
/* This transition is only wanted for opening tabs. */
transition: visibility 0ms 25ms;
}
[Fixed Code]
[Removed entirely]
Additional Details:
- The removed code was related to visibility transitions for tab elements with the fadein attribute
- While this doesn't appear to be a direct security vulnerability, removing timing-related CSS transitions could potentially mitigate timing-based attacks where an attacker might infer information based on rendering timing
- Without more context about how these transitions were used, it's difficult to determine if this was an actual security fix or just a styling change
- The comment suggests these transitions were only meant for opening tabs, so their removal might be part of a larger UI/security improvement
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/js/src/jit/x86/Assembler-x86.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/jit/x86/Assembler-x86.h@@ -473,11 +473,11 @@ masm.shrdl_irr(imm.value, src.encoding(), dest.encoding()); }- void vhaddpd(FloatRegister src, FloatRegister dest) {+ void vhaddpd(FloatRegister rhs, FloatRegister lhsDest) { MOZ_ASSERT(HasSSE3());- MOZ_ASSERT(src.size() == 16);- MOZ_ASSERT(dest.size() == 16);- masm.vhaddpd_rr(src.encoding(), dest.encoding());+ MOZ_ASSERT(rhs.size() == 16);+ MOZ_ASSERT(lhsDest.size() == 16);+ masm.vhaddpd_rr(rhs.encoding(), lhsDest.encoding(), lhsDest.encoding()); } void fild(const Operand& src) {
Analyzing the provided code diff for security fixes:
1. Vulnerability Existed: not sure
Potential Parameter Naming Confusion [js/src/jit/x86/Assembler-x86.h] [Lines 473-477]
Old Code:
void vhaddpd(FloatRegister src, FloatRegister dest) {
MOZ_ASSERT(HasSSE3());
MOZ_ASSERT(src.size() == 16);
MOZ_ASSERT(dest.size() == 16);
masm.vhaddpd_rr(src.encoding(), dest.encoding());
}
Fixed Code:
void vhaddpd(FloatRegister rhs, FloatRegister lhsDest) {
MOZ_ASSERT(HasSSE3());
MOZ_ASSERT(rhs.size() == 16);
MOZ_ASSERT(lhsDest.size() == 16);
masm.vhaddpd_rr(rhs.encoding(), lhsDest.encoding(), lhsDest.encoding());
}
Additional Details:
- The change appears to be primarily about parameter naming clarification (src→rhs, dest→lhsDest) and adding an extra parameter to the masm.vhaddpd_rr call.
- While this improves code clarity, it's unclear if this fixes an actual security vulnerability or just prevents potential misuse.
- The change could potentially prevent parameter confusion bugs, but there's no clear evidence of an actual vulnerability being fixed.
2. Vulnerability Existed: not sure
Potential Incorrect Instruction Usage [js/src/jit/x86/Assembler-x86.h] [Lines 473-477]
Old Code:
masm.vhaddpd_rr(src.encoding(), dest.encoding());
Fixed Code:
masm.vhaddpd_rr(rhs.encoding(), lhsDest.encoding(), lhsDest.encoding());
Additional Details:
- The change adds an additional parameter to the vhaddpd_rr call, suggesting the previous version might have been using the instruction incorrectly.
- This could potentially lead to incorrect calculations or behavior, but it's not clear if this constituted a security vulnerability.
- Without more context about the masm implementation, it's difficult to determine if this was actually exploitable.
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.