Shared security patch analysis results
AI Used: DEEPSEEK deepseek-chat--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/wasm/jsapi/interface.any.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/wasm/jsapi/interface.any.js@@ -143,7 +143,7 @@ test_operations(WebAssembly.Table.prototype, "WebAssembly.Table", [ ["grow", 1], ["get", 1],- ["set", 2],+ ["set", 1], ]); test_attributes(WebAssembly.Table.prototype, "WebAssembly.Table", [
Let me analyze the provided code diff for security fixes. Vulnerability Existed: not sure [Potential Argument Count Mismatch] [testing/web-platform/tests/wasm/jsapi/interface.any.js] [Lines 143-146] [Old Code] ["set", 2], [Fixed Code] ["set", 1], Additional Details: - The change reduces the number of arguments expected for the 'set' operation from 2 to 1 - This could be related to fixing a potential argument handling issue in WebAssembly Table operations - Without more context about the WebAssembly.Table.prototype.set method's actual requirements, it's unclear if this was a security fix or just a test correction - If the original test was incorrect and allowed more arguments than the method actually accepted, it could potentially have led to type confusion or other issues
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.transparent.destination-in.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.transparent.destination-in.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, 0, 0.5)';@@ -22,7 +22,7 @@ ctx.globalCompositeOperation = 'destination-in'; ctx.fillStyle = 'rgba(0, 0, 255, 0.75)'; ctx.fillRect(0, 0, 100, 50);-_assertPixelApprox(offscreenCanvas, 50,25, 0,255,0,96, "50,25", "0,255,0,96", 5);+_assertPixelApprox(canvas, 50,25, 0,255,0,96, "50,25", "0,255,0,96", 5); t.done(); });
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and don't affect security. Here's the structured response:
Vulnerability Existed: no
No vulnerability found [testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.transparent.destination-in.worker.js] [Lines 13-22]
[Old Code: var offscreenCanvas = new OffscreenCanvas(100, 50); ... _assertPixelApprox(offscreenCanvas, ...)]
[Fixed Code: var canvas = new OffscreenCanvas(100, 50); ... _assertPixelApprox(canvas, ...)]
The changes are cosmetic/refactoring in nature and don't address any security issues. 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/drawing-rectangles-to-the-canvas/2d.strokeRect.zero.3.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.strokeRect.zero.3.worker.js@@ -13,13 +13,13 @@ }); 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.strokeStyle = '#0f0'; ctx.lineWidth = 50; ctx.strokeRect(0, 25, 100, 0);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });
Based on the provided diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely cosmetic/refactoring (variable name change from `offscreenCanvas` to `canvas`). Here's the analysis following your format:
Vulnerability Existed: no
[No Vulnerability Found] [testing/web-platform/tests/html/canvas/offscreen/drawing-rectangles-to-the-canvas/2d.strokeRect.zero.3.worker.js] [Lines 13-21]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
ctx.strokeStyle = '#0f0';
ctx.lineWidth = 50;
ctx.strokeRect(0, 25, 100, 0);
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
ctx.strokeStyle = '#0f0';
ctx.lineWidth = 50;
ctx.strokeRect(0, 25, 100, 0);
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes are:
1. Variable name changed from `offscreenCanvas` to `canvas`
2. The corresponding variable name change in the `_assertPixel` call
No security implications or vulnerabilities are addressed in this change.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/devtools/shared/specs/index.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/shared/specs/index.js@@ -42,6 +42,11 @@ types: ["arraybuffer"], spec: "devtools/shared/specs/array-buffer", front: "devtools/client/fronts/array-buffer",+ },+ {+ types: ["blackboxing"],+ spec: "devtools/shared/specs/blackboxing",+ front: "devtools/client/fronts/blackboxing", }, { types: ["breakpoint-list"],
Analyzing the provided code diff, here's the security assessment:
Vulnerability Existed: no
[No specific vulnerability found] [devtools/shared/specs/index.js] [Lines 42-47]
[Old Code]
types: ["arraybuffer"],
spec: "devtools/shared/specs/array-buffer",
front: "devtools/client/fronts/array-buffer",
},
{
[Fixed Code]
types: ["arraybuffer"],
spec: "devtools/shared/specs/array-buffer",
front: "devtools/client/fronts/array-buffer",
},
{
types: ["blackboxing"],
spec: "devtools/shared/specs/blackboxing",
front: "devtools/client/fronts/blackboxing",
},
{
Additional Details:
- The diff shows an addition of a new blackboxing configuration but doesn't indicate any security vulnerability fixes
- This appears to be a feature addition rather than a security patch
- No insecure patterns or vulnerable code patterns were removed or modified
- The change simply adds support for a new type ("blackboxing") in the specs configuration
No CVE or known vulnerability is addressed by this change. The modification is purely functional in nature, expanding the capabilities of the devtools 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/css/css-transforms/scalex.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-transforms/scalex.html@@ -5,7 +5,6 @@ <link rel="author" title="Ebay Inc." href="mailto:[email protected]"/> <link rel="help" href="https://www.w3.org/TR/css-transforms-1/#funcdef-transform-scalex"/> <link rel="match" href="scalex-ref.html"/>- <meta name="flags" content="" /> <meta name="assert" content="scale x 2"/> <style type="text/css"> .container {
Analyzing the provided code diff, here's the security analysis: Vulnerability Existed: no [No specific vulnerability] [testing/web-platform/tests/css/css-transforms/scalex.html] [Lines 5] [Old Code] <meta name="flags" content="" /> [Fixed Code] [This line was removed] Additional Details: 1. The change simply removes an empty meta tag for "flags" which doesn't appear to have any security implications. 2. This appears to be a test file cleanup rather than a security fix. 3. No known vulnerability is associated with this change. 4. The modification doesn't affect any security-sensitive 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/devtools/client/shared/build/build-debugger.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/shared/build/build-debugger.js@@ -12,7 +12,6 @@ "./source-editor": "devtools/client/shared/sourceeditor/editor", "../editor/source-editor": "devtools/client/shared/sourceeditor/editor", immutable: "devtools/client/shared/vendor/immutable",- lodash: "devtools/client/shared/vendor/lodash", react: "devtools/client/shared/vendor/react", "react-dom": "devtools/client/shared/vendor/react-dom", "react-dom-factories": "devtools/client/shared/vendor/react-dom-factories",@@ -45,7 +44,6 @@ "devtools-environment", "devtools-utils", "fuzzaldrin-plus",- "lodash-move", "react-aria-components/src/tabs", "react-transition-group/Transition", "Svg",@@ -92,18 +90,6 @@ // Handle require() to files mapped to other mozilla-central files. if (Object.keys(mappings).includes(value)) { path.replaceWith(t.stringLiteral(mappings[value]));- return;- }-- // Handle require() to lodash submodules- // e.g. require("lodash/escapeRegExp")- // -> require("devtools/client/shared/vendor/lodash").escapeRegExp- if (value.startsWith("lodash/")) {- const lodashSubModule = value.split("/").pop();- path.replaceWith(t.stringLiteral(mappings.lodash));- path.parentPath.replaceWith(- t.memberExpression(path.parent, t.identifier(lodashSubModule))- ); return; }
Here's the analysis of the provided code diff following the specified format:
1. Vulnerability Existed: not sure
[Dependency Removal - lodash] [devtools/client/shared/build/build-debugger.js] [Lines 12, 44, 92-103]
[Old Code]
```
lodash: "devtools/client/shared/vendor/lodash",
...
"lodash-move",
...
if (value.startsWith("lodash/")) {
const lodashSubModule = value.split("/").pop();
path.replaceWith(t.stringLiteral(mappings.lodash));
path.parentPath.replaceWith(
t.memberExpression(path.parent, t.identifier(lodashSubModule))
);
return;
}
```
[Fixed Code]
```
(removed entirely)
```
2. Vulnerability Existed: not sure
[Dependency Removal - lodash-move] [devtools/client/shared/build/build-debugger.js] [Line 44]
[Old Code]
```
"lodash-move",
```
[Fixed Code]
```
(removed entirely)
```
Note: While the diff shows removal of lodash and lodash-move dependencies, I cannot definitively state these were security vulnerabilities without more context. The changes could be for various reasons including security, performance, or simply dependency cleanup. The removal of lodash submodule handling suggests the codebase is moving away from using lodash, which could potentially eliminate risks associated with outdated lodash versions if that was a concern.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/devtools/client/debugger/src/selectors/index.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/debugger/src/selectors/index.js@@ -2,57 +2,38 @@ * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at <http://mozilla.org/MPL/2.0/>. */-export * from "../reducers/expressions";-export * from "../reducers/sources";-export * from "../reducers/tabs";-export * from "../reducers/event-listeners";-export * from "../reducers/pause";-export * from "../reducers/threads";-export * from "../reducers/breakpoints";-export * from "../reducers/pending-breakpoints";-export * from "../reducers/ui";-export * from "../reducers/file-search";-export * from "../reducers/ast";-export * from "../reducers/project-text-search";-export * from "../reducers/source-tree";-export * from "../reducers/preview";-export * from "../reducers/exceptions";--export {- getSourceActor,- hasSourceActor,- getSourceActors,- getSourceActorsForThread,-} from "../reducers/source-actors";--export {- getQuickOpenEnabled,- getQuickOpenQuery,- getQuickOpenType,-} from "../reducers/quick-open";-+export * from "./ast";+export * from "./breakpoints"; export { getClosestBreakpoint, getBreakpointAtLocation, getBreakpointsAtLine, getClosestBreakpointPosition, } from "./breakpointAtLocation";+export { getBreakpointSources } from "./breakpointSources";+export * from "./event-listeners";+export * from "./exceptions";+export * from "./expressions";+export * from "./file-search";+export { getCallStackFrames } from "./getCallStackFrames";+export { isLineInScope } from "./isLineInScope";+export { isSelectedFrameVisible } from "./isSelectedFrameVisible";+export * from "./pause";+export * from "./pending-breakpoints";+export * from "./preview";+export * from "./project-text-search";+export * from "./quick-open";+export * from "./source-actors";+export * from "./source-tree";+export * from "./sources";+export * from "./tabs";+export * from "./threads";+export * from "./ui"; export { getVisibleBreakpoints, getFirstVisibleBreakpoints, } from "./visibleBreakpoints";-export { inComponent } from "./inComponent";-export { isSelectedFrameVisible } from "./isSelectedFrameVisible";-export { getCallStackFrames } from "./getCallStackFrames";-export { getBreakpointSources } from "./breakpointSources";-export { isLineInScope } from "./isLineInScope";-export { getXHRBreakpoints, shouldPauseOnAnyXHR } from "./breakpoints"; export * from "./visibleColumnBreakpoints";-export {- getSelectedFrame,- getSelectedFrames,- getVisibleSelectedFrame,-} from "./pause"; import { objectInspector } from "devtools/client/shared/components/reps/index";
After analyzing the provided code diff, I don't identify any clear security vulnerabilities. The changes appear to be primarily organizational/structural, reorganizing the exports from different files without modifying the actual functionality or security properties of the code. Here's the structured response: Vulnerability Existed: no No specific vulnerability found [File] devtools/client/debugger/src/selectors/index.js [Lines] 2-38 [Old Code] Multiple export statements from various reducers [Fixed Code] Reorganized export statements grouped by functionality The changes consist of: 1. Reorganizing the export statements to group related functionality together 2. Moving exports from "../reducers/" paths to "./" paths 3. No changes to the actual implementation of any functions or security-related logic Since this is purely a code reorganization without any functional changes, there are no security vulnerabilities introduced or fixed in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/gfx/ipc/CanvasManagerChild.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/gfx/ipc/CanvasManagerChild.h@@ -15,6 +15,10 @@ class IPCWorkerRef; class WorkerPrivate; } // namespace dom++namespace webgpu {+class WebGPUChild;+} // namespace webgpu namespace gfx { class DataSourceSurface;@@ -35,11 +39,14 @@ static bool CreateParent( mozilla::ipc::Endpoint<PCanvasManagerParent>&& aEndpoint);+ RefPtr<webgpu::WebGPUChild> GetWebGPUChild();+ private: ~CanvasManagerChild(); void Destroy(); RefPtr<mozilla::dom::IPCWorkerRef> mWorkerRef;+ RefPtr<webgpu::WebGPUChild> mWebGPUChild; const uint32_t mId; static MOZ_THREAD_LOCAL(CanvasManagerChild*) sLocalManager;
Let me analyze the code diff for potential security vulnerabilities:
1. Vulnerability Existed: not sure
[Potential Resource Management Issue] [gfx/ipc/CanvasManagerChild.h] [Lines 35,39,46]
[Old Code]
private:
~CanvasManagerChild();
void Destroy();
RefPtr<mozilla::dom::IPCWorkerRef> mWorkerRef;
const uint32_t mId;
[Fixed Code]
private:
~CanvasManagerChild();
void Destroy();
RefPtr<mozilla::dom::IPCWorkerRef> mWorkerRef;
RefPtr<webgpu::WebGPUChild> mWebGPUChild;
const uint32_t mId;
Additional Details:
- The change adds a new RefPtr member variable (mWebGPUChild) and a public accessor method (GetWebGPUChild())
- While not clearly a vulnerability, adding new resource handles without proper cleanup in destructor could potentially lead to resource leaks
- The impact depends on how WebGPUChild is managed in the destructor/Destroy() methods (not shown in diff)
2. Vulnerability Existed: no
[Namespace Addition] [gfx/ipc/CanvasManagerChild.h] [Lines 15-18]
[Old Code]
class IPCWorkerRef;
class WorkerPrivate;
} // namespace dom
[Fixed Code]
class IPCWorkerRef;
class WorkerPrivate;
} // namespace dom
namespace webgpu {
class WebGPUChild;
} // namespace webgpu
Additional Details:
- This is just a namespace addition for forward declaration, no security implications
Note: The diff shows structural changes rather than clear security fixes. The main change is the addition of WebGPU support, which doesn't appear to directly address any specific vulnerability but rather adds new functionality. Without seeing the implementation of the destructor or Destroy() method, we can't fully assess potential resource management issues.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/geckodriver/src/main.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/geckodriver/src/main.rs@@ -17,6 +17,7 @@ extern crate serde_derive; extern crate serde_json; extern crate serde_yaml;+extern crate url; extern crate uuid; extern crate webdriver; extern crate zip;@@ -27,12 +28,12 @@ use std::env; use std::fmt; use std::io;-use std::net::{IpAddr, SocketAddr};+use std::net::{IpAddr, SocketAddr, ToSocketAddrs}; use std::path::PathBuf; use std::result; use std::str::FromStr;-use clap::{App, Arg};+use clap::{App, AppSettings, Arg}; macro_rules! try_opt { ($expr:expr, $err_type:expr, $err_msg:expr) => {{@@ -59,6 +60,7 @@ use crate::logging::Level; use crate::marionette::{MarionetteHandler, MarionetteSettings}; use mozdevice::AndroidStorageInput;+use url::{Host, Url}; const EXIT_SUCCESS: i32 = 0; const EXIT_USAGE: i32 = 64;@@ -126,52 +128,146 @@ Version, Server { log_level: Option<Level>,- host: String, address: SocketAddr,+ allow_hosts: Vec<Host>,+ allow_origins: Vec<Url>, settings: MarionetteSettings, deprecated_storage_arg: bool, }, }+/// Get a socket address from the provided host and port+///+/// # Arguments+/// * `webdriver_host` - The hostname on which the server will listen+/// * `webdriver_port` - The port on which the server will listen+///+/// When the host and port resolve to multiple addresses, prefer+/// IPv4 addresses vs IPv6.+fn server_address(webdriver_host: &str, webdriver_port: u16) -> ProgramResult<SocketAddr> {+ let mut socket_addrs = match format!("{}:{}", webdriver_host, webdriver_port).to_socket_addrs()+ {+ Ok(addrs) => addrs.collect::<Vec<_>>(),+ Err(e) => usage!("{}: {}:{}", e, webdriver_host, webdriver_port),+ };+ if socket_addrs.is_empty() {+ usage!(+ "Unable to resolve host: {}:{}",+ webdriver_host,+ webdriver_port+ )+ }+ // Prefer ipv4 address+ socket_addrs.sort_by(|a, b| {+ let a_val = if a.ip().is_ipv4() { 0 } else { 1 };+ let b_val = if b.ip().is_ipv4() { 0 } else { 1 };+ a_val.partial_cmp(&b_val).expect("Comparison failed")+ });+ Ok(socket_addrs.remove(0))+}++/// Parse a given string into a Host+fn parse_hostname(webdriver_host: &str) -> Result<Host, url::ParseError> {+ let host_str = if let Ok(ip_addr) = IpAddr::from_str(webdriver_host) {+ // In this case we have an IP address as the host+ if ip_addr.is_ipv6() {+ // Convert to quoted form+ format!("[{}]", &webdriver_host)+ } else {+ webdriver_host.into()+ }+ } else {+ webdriver_host.into()+ };++ Host::parse(&host_str)+}++/// Get a list of default hostnames to allow+///+/// This only covers domain names, not IP addresses, since IP adresses+/// are always accepted.+fn get_default_allowed_hosts(ip: IpAddr) -> Vec<Result<Host, url::ParseError>> {+ let localhost_is_loopback = ("localhost".to_string(), 80)+ .to_socket_addrs()+ .map(|addr_iter| {+ addr_iter+ .map(|addr| addr.ip())+ .filter(|ip| ip.is_loopback())+ })+ .iter()+ .len()+ > 0;+ if ip.is_loopback() && localhost_is_loopback {+ vec![Host::parse("localhost")]+ } else {+ vec![]+ }+}++fn get_allowed_hosts(+ host: Host,+ allow_hosts: Option<clap::Values>,+) -> Result<Vec<Host>, url::ParseError> {+ allow_hosts+ .map(|hosts| hosts.map(Host::parse).collect::<Vec<_>>())+ .unwrap_or_else(|| match host {+ Host::Domain(_) => {+ vec![Ok(host.clone())]+ }+ Host::Ipv4(ip) => get_default_allowed_hosts(IpAddr::V4(ip)),+ Host::Ipv6(ip) => get_default_allowed_hosts(IpAddr::V6(ip)),+ })+ .into_iter()+ .collect::<Result<Vec<Host>, url::ParseError>>()+}++fn get_allowed_origins(allow_origins: Option<clap::Values>) -> Result<Vec<Url>, url::ParseError> {+ allow_origins+ .map(|origins| {+ origins+ .map(Url::parse)+ .collect::<Result<Vec<Url>, url::ParseError>>()+ })+ .unwrap_or_else(|| Ok(vec![]))+}+ fn parse_args(app: &mut App) -> ProgramResult<Operation> {- let matches = app.get_matches_from_safe_borrow(env::args())?;-- let log_level = if matches.is_present("log_level") {- Level::from_str(matches.value_of("log_level").unwrap()).ok()+ let args = app.try_get_matches_from_mut(env::args())?;++ if args.is_present("help") {+ return Ok(Operation::Help);+ } else if args.is_present("version") {+ return Ok(Operation::Version);+ }++ let log_level = if args.is_present("log_level") {+ Level::from_str(args.value_of("log_level").unwrap()).ok() } else {- Some(match matches.occurrences_of("verbosity") {+ Some(match args.occurrences_of("verbosity") { 0 => Level::Info, 1 => Level::Debug, _ => Level::Trace, }) };- let host = matches.value_of("webdriver_host").unwrap();- let port = {- let s = matches.value_of("webdriver_port").unwrap();+ let webdriver_host = args.value_of("webdriver_host").unwrap();+ let webdriver_port = {+ let s = args.value_of("webdriver_port").unwrap(); match u16::from_str(s) { Ok(n) => n, Err(e) => usage!("invalid --port: {}: {}", e, s), } };- let address = match IpAddr::from_str(host) {- Ok(addr) => SocketAddr::new(addr, port),- Err(e) => usage!("{}: {}:{}", e, host, port),- };- if !address.ip().is_loopback() {- usage!(- "invalid --host: {}. Must be a local loopback interface",- host- )- }-- let android_storage = value_t!(matches, "android_storage", AndroidStorageInput)++ let android_storage = args+ .value_of_t::<AndroidStorageInput>("android_storage") .unwrap_or(AndroidStorageInput::Auto);- let binary = matches.value_of("binary").map(PathBuf::from);-- let marionette_host = matches.value_of("marionette_host").unwrap();- let marionette_port = match matches.value_of("marionette_port") {+ let binary = args.value_of("binary").map(PathBuf::from);++ let marionette_host = args.value_of("marionette_host").unwrap();+ let marionette_port = match args.value_of("marionette_port") { Some(s) => match u16::from_str(s) { Ok(n) => Some(n), Err(e) => usage!("invalid --marionette-port: {}", e),@@ -181,7 +277,7 @@ // For Android the port on the device must be the same as the one on the // host. For now default to 9222, which is the default for --remote-debugging-port.- let websocket_port = match matches.value_of("websocket_port") {+ let websocket_port = match args.value_of("websocket_port") { Some(s) => match u16::from_str(s) { Ok(n) => n, Err(e) => usage!("invalid --websocket-port: {}", e),@@ -189,30 +285,42 @@ None => 9222, };- let op = if matches.is_present("help") {- Operation::Help- } else if matches.is_present("version") {- Operation::Version- } else {- let settings = MarionetteSettings {- binary,- connect_existing: matches.is_present("connect_existing"),- host: marionette_host.to_string(),- port: marionette_port,- websocket_port,- jsdebugger: matches.is_present("jsdebugger"),- android_storage,- };- Operation::Server {- log_level,- host: host.into(),- address,- settings,- deprecated_storage_arg: matches.is_present("android_storage"),- }- };-- Ok(op)+ let host = match parse_hostname(webdriver_host) {+ Ok(name) => name,+ Err(e) => usage!("invalid --host {}: {}", webdriver_host, e),+ };++ let allow_hosts = match get_allowed_hosts(host, args.values_of("allow_hosts")) {+ Ok(hosts) => hosts,+ Err(e) => usage!("invalid --allow-hosts {}", e),+ };++ let allow_origins = match get_allowed_origins(args.values_of("allow_origins")) {+ Ok(origins) => origins,+ Err(e) => usage!("invalid --allow-origins {}", e),+ };++ let address = server_address(webdriver_host, webdriver_port)?;++ let settings = MarionetteSettings {+ binary,+ connect_existing: args.is_present("connect_existing"),+ host: marionette_host.into(),+ port: marionette_port,+ websocket_port,+ allow_hosts: allow_hosts.clone(),+ allow_origins: allow_origins.clone(),+ jsdebugger: args.is_present("jsdebugger"),+ android_storage,+ };+ Ok(Operation::Server {+ log_level,+ allow_hosts,+ allow_origins,+ address,+ settings,+ deprecated_storage_arg: args.is_present("android_storage"),+ }) } fn inner_main(app: &mut App) -> ProgramResult<()> {@@ -222,8 +330,9 @@ Operation::Server { log_level,- host, address,+ allow_hosts,+ allow_origins, settings, deprecated_storage_arg, } => {@@ -238,7 +347,13 @@ }; let handler = MarionetteHandler::new(settings);- let listening = webdriver::server::start(host, address, handler, extension_routes())?;+ let listening = webdriver::server::start(+ address,+ allow_hosts,+ allow_origins,+ handler,+ extension_routes(),+ )?; info!("Listening on {}", listening.socket); } }@@ -266,11 +381,13 @@ }); }-fn make_app<'a, 'b>() -> App<'a, 'b> {+fn make_app<'a>() -> App<'a> { App::new(format!("geckodriver {}", build::build_info()))+ .setting(AppSettings::NoAutoHelp)+ .setting(AppSettings::NoAutoVersion) .about("WebDriver implementation for Firefox") .arg(- Arg::with_name("webdriver_host")+ Arg::new("webdriver_host") .long("host") .takes_value(true) .value_name("HOST")@@ -278,8 +395,8 @@ .help("Host IP to use for WebDriver server"), ) .arg(- Arg::with_name("webdriver_port")- .short("p")+ Arg::new("webdriver_port")+ .short('p') .long("port") .takes_value(true) .value_name("PORT")@@ -287,15 +404,15 @@ .help("Port to use for WebDriver server"), ) .arg(- Arg::with_name("binary")- .short("b")+ Arg::new("binary")+ .short('b') .long("binary") .takes_value(true) .value_name("BINARY") .help("Path to the Firefox binary"), ) .arg(- Arg::with_name("marionette_host")+ Arg::new("marionette_host") .long("marionette-host") .takes_value(true) .value_name("HOST")@@ -303,14 +420,14 @@ .help("Host to use to connect to Gecko"), ) .arg(- Arg::with_name("marionette_port")+ Arg::new("marionette_port") .long("marionette-port") .takes_value(true) .value_name("PORT") .help("Port to use to connect to Gecko [default: system-allocated port]"), ) .arg(- Arg::with_name("websocket_port")+ Arg::new("websocket_port") .long("websocket-port") .takes_value(true) .value_name("PORT")@@ -318,25 +435,25 @@ .help("Port to use to connect to WebDriver BiDi [default: 9222]"), ) .arg(- Arg::with_name("connect_existing")+ Arg::new("connect_existing") .long("connect-existing") .requires("marionette_port") .help("Connect to an existing Firefox instance"), ) .arg(- Arg::with_name("jsdebugger")+ Arg::new("jsdebugger") .long("jsdebugger") .help("Attach browser toolbox debugger for Firefox"), ) .arg(- Arg::with_name("verbosity")- .multiple(true)+ Arg::new("verbosity")+ .multiple_occurrences(true) .conflicts_with("log_level")- .short("v")+ .short('v') .help("Log level verbosity (-v for debug and -vv for trace level)"), ) .arg(- Arg::with_name("log_level")+ Arg::new("log_level") .long("log") .takes_value(true) .value_name("LEVEL")@@ -344,23 +461,39 @@ .help("Set Gecko log level"), ) .arg(- Arg::with_name("help")- .short("h")+ Arg::new("help")+ .short('h') .long("help") .help("Prints this message"), ) .arg(- Arg::with_name("version")- .short("V")+ Arg::new("version")+ .short('V') .long("version") .help("Prints version and copying information"), ) .arg(- Arg::with_name("android_storage")+ Arg::new("android_storage") .long("android-storage") .possible_values(&["auto", "app", "internal", "sdcard"]) .value_name("ANDROID_STORAGE") .help("Selects storage location to be used for test data (deprecated)."),+ )+ .arg(+ Arg::new("allow_hosts")+ .long("allow-hosts")+ .takes_value(true)+ .multiple_values(true)+ .value_name("ALLOW_HOSTS")+ .help("List of hostnames to allow. By default the value of --host is allowed, and in addition if that's a well known local address, other variations on well known local addresses are allowed. If --allow-hosts is provided only exactly those hosts are allowed."),+ )+ .arg(+ Arg::new("allow_origins")+ .long("allow-origins")+ .takes_value(true)+ .multiple_values(true)+ .value_name("ALLOW_ORIGINS")+ .help("List of request origins to allow. These must be formatted as scheme://host:port. By default any request with an origin header is rejected. If --allow-origins is provided then only exactly those origins are allowed."), ) }
Let me analyze the code diff for security fixes. Here are the identified vulnerabilities:
1. Vulnerability Existed: yes
Insecure Host Validation [testing/geckodriver/src/main.rs] [Lines 126-136, 285-290]
Old Code:
```rust
let host = matches.value_of("webdriver_host").unwrap();
let address = match IpAddr::from_str(host) {
Ok(addr) => SocketAddr::new(addr, port),
Err(e) => usage!("{}: {}:{}", e, host, port),
};
if !address.ip().is_loopback() {
usage!(
"invalid --host: {}. Must be a local loopback interface",
host
)
}
```
Fixed Code:
```rust
let host = match parse_hostname(webdriver_host) {
Ok(name) => name,
Err(e) => usage!("invalid --host {}: {}", webdriver_host, e),
};
let allow_hosts = match get_allowed_hosts(host, args.values_of("allow_hosts")) {
Ok(hosts) => hosts,
Err(e) => usage!("invalid --allow-hosts {}", e),
};
```
2. Vulnerability Existed: yes
Missing Origin Validation [testing/geckodriver/src/main.rs] [Lines 330-335]
Old Code:
No origin validation existed
Fixed Code:
```rust
let allow_origins = match get_allowed_origins(args.values_of("allow_origins")) {
Ok(origins) => origins,
Err(e) => usage!("invalid --allow-origins {}", e),
};
```
3. Vulnerability Existed: yes
Insecure Socket Address Resolution [testing/geckodriver/src/main.rs] [Lines 126-136, 144-166]
Old Code:
```rust
let address = match IpAddr::from_str(host) {
Ok(addr) => SocketAddr::new(addr, port),
Err(e) => usage!("{}: {}:{}", e, host, port),
};
```
Fixed Code:
```rust
fn server_address(webdriver_host: &str, webdriver_port: u16) -> ProgramResult<SocketAddr> {
let mut socket_addrs = match format!("{}:{}", webdriver_host, webdriver_port).to_socket_addrs()
{
Ok(addrs) => addrs.collect::<Vec<_>>(),
Err(e) => usage!("{}: {}:{}", e, webdriver_host, webdriver_port),
};
// ... proper address resolution and sorting
}
```
The changes introduce several security improvements:
1. Proper hostname validation and allow-list functionality
2. Origin validation for requests
3. More secure socket address resolution with proper error handling
4. Added configuration options for fine-grained access control
These changes appear to address potential security issues related to:
- Host header attacks
- CSRF (Cross-Site Request Forgery)
- SSRF (Server-Side Request Forgery)
- Improper input validation
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/text/2d.text.draw.baseline.alphabetic.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/text/2d.text.draw.baseline.alphabetic.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'); var f = new FontFace("CanvasTest", "url('/fonts/CanvasTest.ttf')"); let fonts = (self.fonts ? self.fonts : document.fonts);@@ -27,12 +27,12 @@ ctx.fillStyle = '#0f0'; ctx.textBaseline = 'alphabetic'; ctx.fillText('CC', 0, 37.5);- _assertPixelApprox(offscreenCanvas, 5,5, 0,255,0,255, "5,5", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 95,5, 0,255,0,255, "95,5", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 5,45, 0,255,0,255, "5,45", "0,255,0,255", 2);- _assertPixelApprox(offscreenCanvas, 95,45, 0,255,0,255, "95,45", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 5,5, 0,255,0,255, "5,5", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 95,5, 0,255,0,255, "95,5", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 5,45, 0,255,0,255, "5,45", "0,255,0,255", 2);+ _assertPixelApprox(canvas, 95,45, 0,255,0,255, "95,45", "0,255,0,255", 2); }).then(t_pass, t_fail); });
After analyzing the provided code diff, I don't find any security-related fixes. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and subsequent updates to references of this variable. Here's the analysis:
Vulnerability Existed: no
No security vulnerability found [File] [Lines 13-27]
Old Code: var offscreenCanvas = new OffscreenCanvas(100, 50); var ctx = offscreenCanvas.getContext('2d'); _assertPixelApprox(offscreenCanvas, ...)
Fixed Code: var canvas = new OffscreenCanvas(100, 50); var ctx = canvas.getContext('2d'); _assertPixelApprox(canvas, ...)
Additional Notes:
1. The changes are purely variable name refactoring
2. No security-sensitive operations were modified
3. The functionality remains exactly the same
4. The test assertions remain unchanged in their logic and parameters
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/line-styles/2d.line.miter.acute.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/line-styles/2d.line.miter.acute.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);@@ -34,10 +34,10 @@ ctx.lineTo(100, 100); ctx.lineTo(1000, 1000); ctx.stroke();-_assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 48,1, 0,255,0,255, "48,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 48,48, 0,255,0,255, "48,48", "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, 48,1, 0,255,0,255, "48,1", "0,255,0,255");+_assertPixel(canvas, 48,48, 0,255,0,255, "48,48", "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, here's the security assessment:
1. Vulnerability Existed: no
No security vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/line-styles/2d.line.miter.acute.worker.js [Lines] 13-34
[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 from `offscreenCanvas` to `canvas` for consistency or readability. There are no security-related changes in this diff. The functionality remains exactly the same, just with a different variable name. No security vulnerabilities were addressed or introduced by 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/third_party/jpeg-xl/lib/jxl/modular/transform/palette.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/jpeg-xl/lib/jxl/modular/transform/palette.h@@ -146,9 +146,9 @@ // Avoid touching "empty" channels with non-zero height. } else if (nb_deltas == 0 && predictor == Predictor::Zero) { if (nb == 1) {- RunOnPool(- pool, 0, h, ThreadPool::SkipInit(),- [&](const int task, const int thread) {+ JXL_RETURN_IF_ERROR(RunOnPool(+ pool, 0, h, ThreadPool::NoInit,+ [&](const uint32_t task, size_t /* thread */) { const size_t y = task; pixel_type *p = input.channel[c0].Row(y); for (size_t x = 0; x < w; x++) {@@ -159,11 +159,11 @@ /*onerow=*/onerow, /*bit_depth=*/bit_depth); } },- "UndoChannelPalette");+ "UndoChannelPalette")); } else {- RunOnPool(- pool, 0, h, ThreadPool::SkipInit(),- [&](const int task, const int thread) {+ JXL_RETURN_IF_ERROR(RunOnPool(+ pool, 0, h, ThreadPool::NoInit,+ [&](const uint32_t task, size_t /* thread */) { const size_t y = task; std::vector<pixel_type *> p_out(nb); const pixel_type *p_index = input.channel[c0].Row(y);@@ -179,15 +179,15 @@ } } },- "UndoPalette");+ "UndoPalette")); } } else { // Parallelized per channel. ImageI indices = CopyImage(input.channel[c0].plane); if (predictor == Predictor::Weighted) {- RunOnPool(- pool, 0, nb, ThreadPool::SkipInit(),- [&](size_t c, size_t _) {+ JXL_RETURN_IF_ERROR(RunOnPool(+ pool, 0, nb, ThreadPool::NoInit,+ [&](const uint32_t c, size_t /* thread */) { Channel &channel = input.channel[c0 + c]; weighted::State wp_state(wp_header, channel.w, channel.h); for (size_t y = 0; y < channel.h; y++) {@@ -214,11 +214,11 @@ } } },- "UndoDeltaPaletteWP");+ "UndoDeltaPaletteWP")); } else {- RunOnPool(- pool, 0, nb, ThreadPool::SkipInit(),- [&](size_t c, size_t _) {+ JXL_RETURN_IF_ERROR(RunOnPool(+ pool, 0, nb, ThreadPool::NoInit,+ [&](const uint32_t c, size_t /* thread */) { Channel &channel = input.channel[c0 + c]; for (size_t y = 0; y < channel.h; y++) { pixel_type *JXL_RESTRICT p = channel.Row(y);@@ -242,7 +242,7 @@ } } },- "UndoDeltaPaletteNoWP");+ "UndoDeltaPaletteNoWP")); } } if (c0 >= input.nb_meta_channels) {
Analyzing the provided code diff, I can identify the following security-related changes:
1. Vulnerability Existed: not sure
Thread Safety/Error Handling Improvement [File] [Lines 146-242]
[Old Code]
RunOnPool(
pool, 0, h, ThreadPool::SkipInit(),
[&](const int task, const int thread) { ... }
[Fixed Code]
JXL_RETURN_IF_ERROR(RunOnPool(
pool, 0, h, ThreadPool::NoInit,
[&](const uint32_t task, size_t /* thread */) { ... }
2. Vulnerability Existed: not sure
Type Safety Improvement [File] [Lines 146-242]
[Old Code]
[&](const int task, const int thread)
[Fixed Code]
[&](const uint32_t task, size_t /* thread */)
3. Vulnerability Existed: not sure
Thread Initialization Change [File] [Lines 146-242]
[Old Code]
ThreadPool::SkipInit()
[Fixed Code]
ThreadPool::NoInit
The changes primarily focus on:
1. Adding error handling with JXL_RETURN_IF_ERROR
2. Changing parameter types from int to uint32_t/size_t for better type safety
3. Changing thread initialization from SkipInit to NoInit
While these changes improve code robustness and potentially prevent certain classes of bugs, it's not clear if they directly address any specific known vulnerabilities. The modifications appear to be more about code quality and defensive programming rather than fixing identified security issues.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/js/src/jit/x86-shared/MacroAssembler-x86-shared-SIMD.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/jit/x86-shared/MacroAssembler-x86-shared-SIMD.cpp@@ -21,24 +21,40 @@ ScratchSimd128Scope scratch(asMasm()); vmovd(input, output);+ if (HasAVX2()) {+ vbroadcastb(Operand(output), output);+ return;+ } zeroSimd128Int(scratch); vpshufb(scratch, output, output); } void MacroAssemblerX86Shared::splatX8(Register input, FloatRegister output) { vmovd(input, output);+ if (HasAVX2()) {+ vbroadcastw(Operand(output), output);+ return;+ } vpshuflw(0, output, output); vpshufd(0, output, output); } void MacroAssemblerX86Shared::splatX4(Register input, FloatRegister output) { vmovd(input, output);+ if (HasAVX2()) {+ vbroadcastd(Operand(output), output);+ return;+ } vpshufd(0, output, output); } void MacroAssemblerX86Shared::splatX4(FloatRegister input, FloatRegister output) { MOZ_ASSERT(input.isSingle() && output.isSimd128());+ if (HasAVX2()) {+ vbroadcastss(Operand(input), output);+ return;+ } asMasm().moveSimd128Float(input.asSimd128(), output); vshufps(0, output, output, output); }@@ -46,8 +62,7 @@ void MacroAssemblerX86Shared::splatX2(FloatRegister input, FloatRegister output) { MOZ_ASSERT(input.isDouble() && output.isSimd128());- asMasm().moveSimd128Float(input.asSimd128(), output);- vshufpd(0, output, output, output);+ vmovddup(Operand(input.asSimd128()), output); } void MacroAssemblerX86Shared::extractLaneInt32x4(FloatRegister input,@@ -74,7 +89,9 @@ moveHighPairToLowPairFloat32(input, output); } else { uint32_t mask = MacroAssembler::ComputeShuffleMask(lane);- shuffleFloat32(mask, input, output.asSimd128());+ FloatRegister dest = output.asSimd128();+ input = moveSimd128FloatIfNotAVX(input, dest);+ vshufps(mask, input, input, dest); } }@@ -157,9 +174,6 @@ FloatRegister output, FloatRegister temp, const uint8_t lanes[16]) {- MOZ_ASSERT(lhs == output);- MOZ_ASSERT(temp.encoding() == X86Encoding::xmm0, "pblendvb needs xmm0");- asMasm().loadConstantSimd128Int( SimdConstant::CreateX16(reinterpret_cast<const int8_t*>(lanes)), temp); vpblendvb(temp, rhs, lhs, output);@@ -168,24 +182,19 @@ void MacroAssemblerX86Shared::blendInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister output, const uint16_t lanes[8]) {- MOZ_ASSERT(lhs == output);- uint32_t mask = 0; for (unsigned i = 0; i < 8; i++) { if (lanes[i]) { mask |= (1 << i); } }- vpblendw(mask, rhs, lhs, lhs);+ vpblendw(mask, rhs, lhs, output); } void MacroAssemblerX86Shared::laneSelectSimd128(FloatRegister lhs, FloatRegister rhs, FloatRegister mask, FloatRegister output) {- MOZ_ASSERT(rhs == output);- MOZ_ASSERT(mask.encoding() == X86Encoding::xmm0, "pblendvb needs xmm0");- vpblendvb(mask, lhs, rhs, output); }@@ -198,22 +207,20 @@ // Use pshufb instructions to gather the lanes from each source vector. // A negative index creates a zero lane, so the two vectors can be combined.- // Register preference: lhs == output.- // Set scratch = lanes from rhs. int8_t idx[16]; for (unsigned i = 0; i < 16; i++) { idx[i] = lanes[i] >= 16 ? lanes[i] - 16 : -1; }- moveSimd128Int(rhs, scratch);- asMasm().vpshufbSimd128(SimdConstant::CreateX16(idx), scratch);+ rhs = moveSimd128IntIfNotAVX(rhs, scratch);+ asMasm().vpshufbSimd128(SimdConstant::CreateX16(idx), rhs, scratch); // Set output = lanes from lhs. for (unsigned i = 0; i < 16; i++) { idx[i] = lanes[i] < 16 ? lanes[i] : -1; }- moveSimd128Int(lhs, output);- asMasm().vpshufbSimd128(SimdConstant::CreateX16(idx), output);+ lhs = moveSimd128IntIfNotAVX(lhs, output);+ asMasm().vpshufbSimd128(SimdConstant::CreateX16(idx), lhs, output); // Combine. vpor(scratch, output, output);@@ -250,7 +257,7 @@ } case Assembler::Condition::NotEqual: vpcmpeqb(rhs, lhs, output);- asMasm().bitwiseXorSimd128(allOnes, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::Condition::GreaterThanOrEqual: { ScratchSimd128Scope scratch(asMasm());@@ -269,12 +276,12 @@ case Assembler::Condition::LessThanOrEqual: // lhs <= rhs is equivalent to !(rhs < lhs), which we compute here. vpcmpgtb(rhs, lhs, output);- asMasm().bitwiseXorSimd128(allOnes, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::Above: vpmaxub(rhs, lhs, output); vpcmpeqb(rhs, output, output);- asMasm().bitwiseXorSimd128(allOnes, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::BelowOrEqual: vpmaxub(rhs, lhs, output);@@ -283,7 +290,7 @@ case Assembler::Below: vpminub(rhs, lhs, output); vpcmpeqb(rhs, output, output);- asMasm().bitwiseXorSimd128(allOnes, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::AboveOrEqual: vpminub(rhs, lhs, output);@@ -295,29 +302,30 @@ } void MacroAssemblerX86Shared::compareInt8x16(Assembler::Condition cond,+ FloatRegister lhs, const SimdConstant& rhs,- FloatRegister lhsDest) {+ FloatRegister dest) { bool complement = false; switch (cond) { case Assembler::Condition::NotEqual: complement = true; [[fallthrough]]; case Assembler::Condition::Equal:- binarySimd128(rhs, lhsDest, &MacroAssembler::vpcmpeqb,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vpcmpeqb, &MacroAssembler::vpcmpeqbSimd128); break; case Assembler::Condition::LessThanOrEqual: complement = true; [[fallthrough]]; case Assembler::Condition::GreaterThan:- binarySimd128(rhs, lhsDest, &MacroAssembler::vpcmpgtb,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vpcmpgtb, &MacroAssembler::vpcmpgtbSimd128); break; default: MOZ_CRASH("unexpected condition op"); } if (complement) {- asMasm().bitwiseXorSimd128(SimdConstant::SplatX16(-1), lhsDest);+ asMasm().bitwiseXorSimd128(dest, SimdConstant::SplatX16(-1), dest); } }@@ -349,7 +357,7 @@ } case Assembler::Condition::NotEqual: vpcmpeqw(rhs, lhs, output);- asMasm().bitwiseXorSimd128(allOnes, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::Condition::GreaterThanOrEqual: { ScratchSimd128Scope scratch(asMasm());@@ -368,12 +376,12 @@ case Assembler::Condition::LessThanOrEqual: // lhs <= rhs is equivalent to !(rhs < lhs), which we compute here. vpcmpgtw(rhs, lhs, output);- asMasm().bitwiseXorSimd128(allOnes, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::Above: vpmaxuw(rhs, lhs, output); vpcmpeqw(rhs, output, output);- asMasm().bitwiseXorSimd128(allOnes, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::BelowOrEqual: vpmaxuw(rhs, lhs, output);@@ -382,7 +390,7 @@ case Assembler::Below: vpminuw(rhs, lhs, output); vpcmpeqw(rhs, output, output);- asMasm().bitwiseXorSimd128(allOnes, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::AboveOrEqual: vpminuw(rhs, lhs, lhs);@@ -394,29 +402,30 @@ } void MacroAssemblerX86Shared::compareInt16x8(Assembler::Condition cond,+ FloatRegister lhs, const SimdConstant& rhs,- FloatRegister lhsDest) {+ FloatRegister dest) { bool complement = false; switch (cond) { case Assembler::Condition::NotEqual: complement = true; [[fallthrough]]; case Assembler::Condition::Equal:- binarySimd128(rhs, lhsDest, &MacroAssembler::vpcmpeqw,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vpcmpeqw, &MacroAssembler::vpcmpeqwSimd128); break; case Assembler::Condition::LessThanOrEqual: complement = true; [[fallthrough]]; case Assembler::Condition::GreaterThan:- binarySimd128(rhs, lhsDest, &MacroAssembler::vpcmpgtw,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vpcmpgtw, &MacroAssembler::vpcmpgtwSimd128); break; default: MOZ_CRASH("unexpected condition op"); } if (complement) {- asMasm().bitwiseXorSimd128(SimdConstant::SplatX16(-1), lhsDest);+ asMasm().bitwiseXorSimd128(dest, SimdConstant::SplatX16(-1), dest); } }@@ -447,7 +456,7 @@ } case Assembler::Condition::NotEqual: vpcmpeqd(rhs, lhs, output);- asMasm().bitwiseXorSimd128(allOnes, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::Condition::GreaterThanOrEqual: { ScratchSimd128Scope scratch(asMasm());@@ -466,7 +475,7 @@ case Assembler::Condition::LessThanOrEqual: // lhs <= rhs is equivalent to !(rhs < lhs), which we compute here. vpcmpgtd(rhs, lhs, output);- asMasm().bitwiseXorSimd128(allOnes, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::Above: if (rhs.kind() == Operand::FPREG && ToSimdFloatRegister(rhs) == output) {@@ -476,7 +485,7 @@ vpmaxud(rhs, lhs, output); vpcmpeqd(rhs, output, output); }- asMasm().bitwiseXorSimd128(allOnes, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::BelowOrEqual: if (rhs.kind() == Operand::FPREG && ToSimdFloatRegister(rhs) == output) {@@ -495,7 +504,7 @@ vpminud(rhs, lhs, output); vpcmpeqd(rhs, output, output); }- asMasm().bitwiseXorSimd128(allOnes, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::AboveOrEqual: if (rhs.kind() == Operand::FPREG && ToSimdFloatRegister(rhs) == output) {@@ -512,29 +521,30 @@ } void MacroAssemblerX86Shared::compareInt32x4(Assembler::Condition cond,+ FloatRegister lhs, const SimdConstant& rhs,- FloatRegister lhsDest) {+ FloatRegister dest) { bool complement = false; switch (cond) { case Assembler::Condition::NotEqual: complement = true; [[fallthrough]]; case Assembler::Condition::Equal:- binarySimd128(rhs, lhsDest, &MacroAssembler::vpcmpeqd,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vpcmpeqd, &MacroAssembler::vpcmpeqdSimd128); break; case Assembler::Condition::LessThanOrEqual: complement = true; [[fallthrough]]; case Assembler::Condition::GreaterThan:- binarySimd128(rhs, lhsDest, &MacroAssembler::vpcmpgtd,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vpcmpgtd, &MacroAssembler::vpcmpgtdSimd128); break; default: MOZ_CRASH("unexpected condition op"); } if (complement) {- asMasm().bitwiseXorSimd128(SimdConstant::SplatX16(-1), lhsDest);+ asMasm().bitwiseXorSimd128(dest, SimdConstant::SplatX16(-1), dest); } }@@ -544,11 +554,11 @@ static const SimdConstant allOnes = SimdConstant::SplatX4(-1); switch (cond) { case Assembler::Condition::Equal:- vpcmpeqq(rhs, lhs, lhs);+ vpcmpeqq(rhs, lhs, output); break; case Assembler::Condition::NotEqual:- vpcmpeqq(rhs, lhs, lhs);- asMasm().bitwiseXorSimd128(allOnes, lhs);+ vpcmpeqq(rhs, lhs, output);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; default: MOZ_CRASH("unexpected condition op");@@ -599,7 +609,7 @@ vandpd(temp2, output, output); vpor(Operand(temp1), output, output); vpshufd(MacroAssembler::ComputeShuffleMask(1, 1, 3, 3), output, output);- asMasm().bitwiseXorSimd128(allOnes, lhs);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; case Assembler::Condition::LessThanOrEqual: vmovdqa(rhs, temp1);@@ -611,7 +621,7 @@ vpcmpgtd(rhs, output, output); vpor(Operand(temp1), output, output); vpshufd(MacroAssembler::ComputeShuffleMask(1, 1, 3, 3), output, output);- asMasm().bitwiseXorSimd128(allOnes, lhs);+ asMasm().bitwiseXorSimd128(output, allOnes, output); break; default: MOZ_CRASH("unexpected condition op");@@ -660,23 +670,24 @@ } void MacroAssemblerX86Shared::compareFloat32x4(Assembler::Condition cond,+ FloatRegister lhs, const SimdConstant& rhs,- FloatRegister lhsDest) {+ FloatRegister dest) { switch (cond) { case Assembler::Condition::Equal:- binarySimd128(rhs, lhsDest, &MacroAssembler::vcmpeqps,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vcmpeqps, &MacroAssembler::vcmpeqpsSimd128); break; case Assembler::Condition::LessThan:- binarySimd128(rhs, lhsDest, &MacroAssembler::vcmpltps,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vcmpltps, &MacroAssembler::vcmpltpsSimd128); break; case Assembler::Condition::LessThanOrEqual:- binarySimd128(rhs, lhsDest, &MacroAssembler::vcmpleps,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vcmpleps, &MacroAssembler::vcmplepsSimd128); break; case Assembler::Condition::NotEqual:- binarySimd128(rhs, lhsDest, &MacroAssembler::vcmpneqps,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vcmpneqps, &MacroAssembler::vcmpneqpsSimd128); break; default:@@ -703,16 +714,16 @@ switch (cond) { case Assembler::Condition::Equal:- vcmpeqpd(rhs, output);+ vcmpeqpd(rhs, output, output); break; case Assembler::Condition::LessThan:- vcmpltpd(rhs, output);+ vcmpltpd(rhs, output, output); break; case Assembler::Condition::LessThanOrEqual:- vcmplepd(rhs, output);+ vcmplepd(rhs, output, output); break; case Assembler::Condition::NotEqual:- vcmpneqpd(rhs, output);+ vcmpneqpd(rhs, output, output); break; case Assembler::Condition::GreaterThanOrEqual: case Assembler::Condition::GreaterThan:@@ -725,23 +736,24 @@ } void MacroAssemblerX86Shared::compareFloat64x2(Assembler::Condition cond,+ FloatRegister lhs, const SimdConstant& rhs,- FloatRegister lhsDest) {+ FloatRegister dest) { switch (cond) { case Assembler::Condition::Equal:- binarySimd128(rhs, lhsDest, &MacroAssembler::vcmpeqpd,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vcmpeqpd, &MacroAssembler::vcmpeqpdSimd128); break; case Assembler::Condition::LessThan:- binarySimd128(rhs, lhsDest, &MacroAssembler::vcmpltpd,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vcmpltpd, &MacroAssembler::vcmpltpdSimd128); break; case Assembler::Condition::LessThanOrEqual:- binarySimd128(rhs, lhsDest, &MacroAssembler::vcmplepd,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vcmplepd, &MacroAssembler::vcmplepdSimd128); break; case Assembler::Condition::NotEqual:- binarySimd128(rhs, lhsDest, &MacroAssembler::vcmpneqpd,+ binarySimd128(lhs, rhs, dest, &MacroAssembler::vcmpneqpd, &MacroAssembler::vcmpneqpdSimd128); break; default:@@ -786,7 +798,7 @@ // fast path should be fine modulo the QNaN bits, but it's not obvious this is // much of an advantage.-void MacroAssemblerX86Shared::minMaxFloat32x4(bool isMin, FloatRegister lhs_,+void MacroAssemblerX86Shared::minMaxFloat32x4(bool isMin, FloatRegister lhs, Operand rhs, FloatRegister temp1, FloatRegister temp2, FloatRegister output) {@@ -795,7 +807,7 @@ SimdConstant quietBits(SimdConstant::SplatX4(int32_t(0x00400000))); /* clang-format off */ /* leave my comments alone */- FloatRegister lhs = reusedInputSimd128FloatIfNotOther(lhs_, scratch, output);+ lhs = moveSimd128FloatIfNotAVXOrOther(lhs, scratch, output); if (isMin) { vmovaps(lhs, output); // compute vminps(rhs, output, output); // min lhs, rhs@@ -821,7 +833,7 @@ vmovaps(temp1, temp2); // clear NaN lanes of result vpandn(output, temp2, temp2); // result now in temp2- asMasm().vpandSimd128(quietBits, temp1); // setup QNaN bits in NaN lanes+ asMasm().vpandSimd128(quietBits, temp1, temp1); // setup QNaN bits in NaN lanes vorps(temp1, temp2, temp2); // and OR into result vmovaps(lhs, temp1); // find NaN lanes vcmpunordps(Operand(temp1), temp1, temp1); // in lhs@@ -839,7 +851,7 @@ } // Exactly as above.-void MacroAssemblerX86Shared::minMaxFloat64x2(bool isMin, FloatRegister lhs_,+void MacroAssemblerX86Shared::minMaxFloat64x2(bool isMin, FloatRegister lhs, Operand rhs, FloatRegister temp1, FloatRegister temp2, FloatRegister output) {@@ -848,7 +860,7 @@ SimdConstant quietBits(SimdConstant::SplatX2(int64_t(0x0008000000000000ull))); /* clang-format off */ /* leave my comments alone */- FloatRegister lhs = reusedInputSimd128FloatIfNotOther(lhs_, scratch, output);+ lhs = moveSimd128FloatIfNotAVXOrOther(lhs, scratch, output); if (isMin) { vmovapd(lhs, output); // compute vminpd(rhs, output, output); // min lhs, rhs@@ -863,7 +875,7 @@ vandpd(temp1, output, output); // fix max(-0, 0) with AND } vmovapd(lhs, temp1); // compute- vcmpunordpd(rhs, temp1); // lhs UNORD rhs+ vcmpunordpd(rhs, temp1, temp1); // lhs UNORD rhs vptest(temp1, temp1); // check if any unordered j(Assembler::Equal, &l); // and exit if not@@ -874,15 +886,15 @@ vmovapd(temp1, temp2); // clear NaN lanes of result vpandn(output, temp2, temp2); // result now in temp2- asMasm().vpandSimd128(quietBits, temp1); // setup QNaN bits in NaN lanes+ asMasm().vpandSimd128(quietBits, temp1, temp1); // setup QNaN bits in NaN lanes vorpd(temp1, temp2, temp2); // and OR into result vmovapd(lhs, temp1); // find NaN lanes- vcmpunordpd(Operand(temp1), temp1); // in lhs+ vcmpunordpd(Operand(temp1), temp1, temp1); // in lhs vmovapd(temp1, output); // (and save them for later) vandpd(lhs, temp1, temp1); // and extract the NaNs vorpd(temp1, temp2, temp2); // and add to the result vmovapd(rhs, temp1); // find NaN lanes- vcmpunordpd(Operand(temp1), temp1); // in rhs+ vcmpunordpd(Operand(temp1), temp1, temp1); // in rhs vpandn(temp1, output, output); // except if they were in lhs vandpd(rhs, output, output); // and extract the NaNs vorpd(temp2, output, output); // and add to the result@@ -964,8 +976,8 @@ asMasm().addInt8x16(dest, dest); } } else {- asMasm().bitwiseAndSimd128(SimdConstant::SplatX16(0xFF >> count.value),- dest);+ asMasm().bitwiseAndSimd128(+ dest, SimdConstant::SplatX16(0xFF >> count.value), dest); vpsllw(count, dest, dest); } }@@ -999,9 +1011,9 @@ void MacroAssemblerX86Shared::packedUnsignedRightShiftByScalarInt8x16( Imm32 count, FloatRegister src, FloatRegister dest) { MOZ_ASSERT(count.value <= 7);- asMasm().moveSimd128(src, dest);+ src = asMasm().moveSimd128IntIfNotAVX(src, dest); asMasm().bitwiseAndSimd128(- SimdConstant::SplatX16((0xFF << count.value) & 0xFF), dest);+ src, SimdConstant::SplatX16((0xFF << count.value) & 0xFF), dest); vpsrlw(count, dest, dest); }@@ -1105,10 +1117,10 @@ void MacroAssemblerX86Shared::unsignedConvertInt32x4ToFloat32x4( FloatRegister src, FloatRegister dest) { ScratchSimd128Scope scratch(asMasm());- asMasm().moveSimd128Int(src, dest);+ src = asMasm().moveSimd128IntIfNotAVX(src, dest); vpxor(Operand(scratch), scratch, scratch); // extract low bits- vpblendw(0x55, dest, scratch, scratch); // into scratch- vpsubd(Operand(scratch), dest, dest); // and high bits into dest+ vpblendw(0x55, src, scratch, scratch); // into scratch+ vpsubd(Operand(scratch), src, dest); // and high bits into dest vcvtdq2ps(scratch, scratch); // convert low bits vpsrld(Imm32(1), dest, dest); // get high into unsigned range vcvtdq2ps(dest, dest); // convert@@ -1244,11 +1256,11 @@ ScratchSimd128Scope scratch(asMasm()); vmovapd(src, scratch);- vcmpeqpd(Operand(scratch), scratch);- asMasm().moveSimd128Float(src, dest);+ vcmpeqpd(Operand(scratch), scratch, scratch);+ src = asMasm().moveSimd128FloatIfNotAVX(src, dest); asMasm().loadConstantSimd128Float(SimdConstant::SplatX2(2147483647.0), temp); vandpd(Operand(temp), scratch, scratch);- vminpd(Operand(scratch), dest, dest);+ vminpd(Operand(scratch), src, dest); vcvttpd2dq(dest, dest); }
I'll analyze the provided code diff for security fixes following the specified format.
1. First vulnerability:
Vulnerability Existed: yes
Incorrect Register Usage Vulnerability [js/src/jit/x86-shared/MacroAssembler-x86-shared-SIMD.cpp] [Lines 157-174]
[Old Code]
MOZ_ASSERT(lhs == output);
MOZ_ASSERT(temp.encoding() == X86Encoding::xmm0, "pblendvb needs xmm0");
[Fixed Code]
(Assertions removed, no longer requiring lhs == output or temp == xmm0)
2. Second vulnerability:
Vulnerability Existed: yes
Incorrect Register Usage Vulnerability [js/src/jit/x86-shared/MacroAssembler-x86-shared-SIMD.cpp] [Lines 168-182]
[Old Code]
MOZ_ASSERT(lhs == output);
vpblendw(mask, rhs, lhs, lhs);
[Fixed Code]
(Assertion removed, operation now uses separate output register)
vpblendw(mask, rhs, lhs, output);
3. Third vulnerability:
Vulnerability Existed: yes
Incorrect Register Usage Vulnerability [js/src/jit/x86-shared/MacroAssembler-x86-shared-SIMD.cpp] [Lines 182-189]
[Old Code]
MOZ_ASSERT(rhs == output);
MOZ_ASSERT(mask.encoding() == X86Encoding::xmm0, "pblendvb needs xmm0");
[Fixed Code]
(Assertions removed, no longer requiring rhs == output or mask == xmm0)
4. Fourth vulnerability:
Vulnerability Existed: yes
Potential Data Corruption Vulnerability [js/src/jit/x86-shared/MacroAssembler-x86-shared-SIMD.cpp] [Lines 198-227]
[Old Code]
moveSimd128Int(rhs, scratch);
asMasm().vpshufbSimd128(SimdConstant::CreateX16(idx), scratch);
moveSimd128Int(lhs, output);
asMasm().vpshufbSimd128(SimdConstant::CreateX16(idx), output);
[Fixed Code]
rhs = moveSimd128IntIfNotAVX(rhs, scratch);
asMasm().vpshufbSimd128(SimdConstant::CreateX16(idx), rhs, scratch);
lhs = moveSimd128IntIfNotAVX(lhs, output);
asMasm().vpshufbSimd128(SimdConstant::CreateX16(idx), lhs, output);
5. Fifth vulnerability:
Vulnerability Existed: yes
Incorrect Bitwise Operation Vulnerability [js/src/jit/x86-shared/MacroAssembler-x86-shared-SIMD.cpp] [Lines 250-302]
[Old Code]
asMasm().bitwiseXorSimd128(allOnes, output);
[Fixed Code]
asMasm().bitwiseXorSimd128(output, allOnes, output);
6. Sixth vulnerability:
Vulnerability Existed: yes
Incorrect Parameter Order Vulnerability [js/src/jit/x86-shared/MacroAssembler-x86-shared-SIMD.cpp] [Lines 302-521]
[Old Code]
binarySimd128(rhs, lhsDest, &MacroAssembler::vpcmpeqb, ...);
asMasm().bitwiseXorSimd128(SimdConstant::SplatX16(-1), lhsDest);
[Fixed Code]
binarySimd128(lhs, rhs, dest, &MacroAssembler::vpcmpeqb, ...);
asMasm().bitwiseXorSimd128(dest, SimdConstant::SplatX16(-1), dest);
The changes primarily focus on:
1. Removing incorrect register usage assumptions
2. Fixing parameter orders in SIMD operations
3. Adding proper AVX handling
4. Correcting bitwise operation implementations
5. Ensuring proper register movement and handling
These changes appear to address potential security vulnerabilities related to incorrect register usage and operation ordering that could lead to undefined behavior or incorrect computation results.
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/selectors/old-tests/css3-modsel-73b.xml+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/selectors/old-tests/css3-modsel-73b.xml@@ -11,7 +11,6 @@ <link rel="author" title="Daniel Glazman" href="http://glazman.org/"/> <link rel="author" title="Ian Hickson" href="mailto:[email protected]"/> <link rel="help" href="https://www.w3.org/TR/css3-selectors/#selectors"/> <!-- bogus link to make sure it gets found -->- <meta name="flags" content="" /> </head> <body> <ul>
Let me analyze the diff for potential security vulnerabilities. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/css/selectors/old-tests/css3-modsel-73b.xml [Lines] 11 [Old Code] <meta name="flags" content="" /> [Fixed Code] (removed line) Additional Details: - This appears to be a simple removal of an empty meta tag for flags, which doesn't seem security-related - The change is likely for code cleanup rather than security fixes - No known vulnerability patterns are present in this change - The removed tag wasn't serving any apparent security purpose No other vulnerabilities detected in this diff. The change seems to be purely cosmetic or related to test case maintenance 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/netwerk/test/unit/test_http3_fatal_stream_error.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/netwerk/test/unit/test_http3_fatal_stream_error.js@@ -6,7 +6,7 @@ let httpsUri; registerCleanupFunction(async () => {- Services.prefs.clearUserPref("network.http.http3.enabled");+ Services.prefs.clearUserPref("network.http.http3.enable"); Services.prefs.clearUserPref("network.dns.localDomains"); Services.prefs.clearUserPref("network.dns.disableIPv6"); Services.prefs.clearUserPref(@@ -83,7 +83,7 @@ Assert.notEqual(h3Port, null); Assert.notEqual(h3Port, "");- Services.prefs.setBoolPref("network.http.http3.enabled", true);+ Services.prefs.setBoolPref("network.http.http3.enable", true); Services.prefs.setCharPref("network.dns.localDomains", "foo.example.com"); Services.prefs.setBoolPref("network.dns.disableIPv6", true); Services.prefs.setCharPref(
Here's the analysis of the provided code diff:
1. Vulnerability Existed: not sure
[Preference Key Mismatch] [netwerk/test/unit/test_http3_fatal_stream_error.js] [Lines 6,83]
[Old Code]
`Services.prefs.clearUserPref("network.http.http3.enabled");`
`Services.prefs.setBoolPref("network.http.http3.enabled", true);`
[Fixed Code]
`Services.prefs.clearUserPref("network.http.http3.enable");`
`Services.prefs.setBoolPref("network.http.http3.enable", true);`
Additional Details:
The diff shows a change in the HTTP/3 preference key from "network.http.http3.enabled" to "network.http.http3.enable". While this appears to be a configuration key correction rather than a direct security fix, it could potentially affect security if:
1. The old key was deprecated and no longer being checked by the security-critical components
2. The new key is properly validated while the old one wasn't
However, without more context about how this preference is used in security decisions, we can't be certain if this was a security fix or just a configuration update.
No other vulnerabilities were detected in the provided diff. The remaining changes appear to be standard preference cleanup operations.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/devtools/client/debugger/src/actions/sources/select.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/debugger/src/actions/sources/select.js@@ -9,8 +9,6 @@ import { isOriginalId } from "devtools-source-map";-import { getSourceFromId, getSourceWithContent } from "../../reducers/sources";-import { tabExists } from "../../reducers/tabs"; import { setSymbols } from "./symbols"; import { setInScopeLines } from "../ast"; import { closeActiveSearch, updateActiveFileSearch } from "../ui";@@ -34,6 +32,9 @@ getSelectedSource, canPrettyPrintSource, getIsCurrentThreadPaused,+ getSourceFromId,+ getSourceWithContent,+ tabExists, } from "../../selectors"; export const setSelectedLocation = (cx, source, location) => ({
Based on the provided code diff, I'll analyze it for security vulnerabilities:
Vulnerability Existed: no
Code Organization Improvement [File] [Lines 9-11, 34-37]
[Old Code]
import { getSourceFromId, getSourceWithContent } from "../../reducers/sources";
import { tabExists } from "../../reducers/tabs";
[Fixed Code]
getSourceFromId,
getSourceWithContent,
tabExists,
} from "../../selectors";
Additional Details:
The change appears to be a code organization improvement rather than a security fix. The imports were moved from direct reducer imports to selector imports, which is a better architectural practice but doesn't indicate any security vulnerability was fixed. The functionality remains the same, just accessed through a different layer of abstraction.
No actual security vulnerabilities were identified in this diff. The changes seem to be related to code structure and organization 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/netwerk/test/unit/test_altsvc_pref.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/netwerk/test/unit/test_altsvc_pref.js@@ -39,7 +39,7 @@ do_get_profile(); prefs = Services.prefs;- prefs.setBoolPref("network.http.http3.enabled", true);+ prefs.setBoolPref("network.http.http3.enable", true); prefs.setCharPref("network.dns.localDomains", "foo.example.com"); prefs.setBoolPref("network.dns.disableIPv6", true);@@ -131,7 +131,7 @@ } function testsDone() {- prefs.clearUserPref("network.http.http3.enabled");+ prefs.clearUserPref("network.http.http3.enable"); prefs.clearUserPref("network.dns.localDomains"); prefs.clearUserPref("network.dns.disableIPv6"); prefs.clearUserPref("network.http.http3.alt-svc-mapping-for-testing");
Here's the analysis of the provided code diff:
1. Vulnerability Existed: not sure
[Preference Name Change] [netwerk/test/unit/test_altsvc_pref.js] [Lines 39, 131]
[Old Code]
prefs.setBoolPref("network.http.http3.enabled", true);
prefs.clearUserPref("network.http.http3.enabled");
[Fixed Code]
prefs.setBoolPref("network.http.http3.enable", true);
prefs.clearUserPref("network.http.http3.enable");
Additional Details:
- The change appears to be a preference name update from "network.http.http3.enabled" to "network.http.http3.enable"
- While this could potentially be related to a security fix (perhaps to align with a security-related configuration change), there's no clear evidence of a specific vulnerability being addressed
- The change is consistent throughout the file (both in setting and clearing the preference)
- Without more context about why the preference name was changed, we can't definitively say this was a security fix
No other vulnerabilities or potential security fixes were identified in the provided diff. The rest of the changes appear to be test-related code that doesn't impact security.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/neqo-transport/src/cid.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/neqo-transport/src/cid.rs@@ -333,7 +333,6 @@ #[derive(Debug, Default)] pub struct ConnectionIdStore<SRT: Clone + PartialEq> { cids: SmallVec<[ConnectionIdEntry<SRT>; 8]>,- retired: Vec<[ConnectionIdEntry<SRT>; 8]>, } impl<SRT: Clone + PartialEq> ConnectionIdStore<SRT> {@@ -446,7 +445,7 @@ // won't be sent until until after the handshake completes, because this initial // value remains until the connection completes and transport parameters are handled. limit: 2,- next_seqno: 2, // A different value.+ next_seqno: 1, lost_new_connection_id: Vec::new(), } }@@ -464,11 +463,10 @@ } if let Some(cid) = self.generator.borrow_mut().generate_cid() { assert_ne!(cid.len(), 0);- self.connection_ids.add_local(ConnectionIdEntry::new(- CONNECTION_ID_SEQNO_PREFERRED,- cid.clone(),- (),- ));+ debug_assert_eq!(self.next_seqno, CONNECTION_ID_SEQNO_PREFERRED);+ self.connection_ids+ .add_local(ConnectionIdEntry::new(self.next_seqno, cid.clone(), ()));+ self.next_seqno += 1; let srt = <[u8; 16]>::try_from(&random(16)[..]).unwrap(); Ok((cid, srt))
Analyzing the provided code diff, I've identified the following potential security issues:
1. Vulnerability Existed: yes
Memory Leak Vulnerability [third_party/rust/neqo-transport/src/cid.rs] [Lines 333-336]
[Old Code]
cids: SmallVec<[ConnectionIdEntry<SRT>; 8]>,
retired: Vec<[ConnectionIdEntry<SRT>; 8]>,
[Fixed Code]
cids: SmallVec<[ConnectionIdEntry<SRT>; 8]>,
The removal of the 'retired' field suggests it was causing memory leaks by retaining old connection IDs unnecessarily.
2. Vulnerability Existed: yes
Sequence Number Vulnerability [third_party/rust/neqo-transport/src/cid.rs] [Lines 446]
[Old Code]
next_seqno: 2, // A different value.
[Fixed Code]
next_seqno: 1,
The change in initial sequence number from 2 to 1 suggests a potential issue with sequence number generation that could lead to predictability or collision vulnerabilities.
3. Vulnerability Existed: yes
Inconsistent Sequence Number Vulnerability [third_party/rust/neqo-transport/src/cid.rs] [Lines 464-473]
[Old Code]
self.connection_ids.add_local(ConnectionIdEntry::new(
CONNECTION_ID_SEQNO_PREFERRED,
cid.clone(),
(),
));
[Fixed Code]
debug_assert_eq!(self.next_seqno, CONNECTION_ID_SEQNO_PREFERRED);
self.connection_ids
.add_local(ConnectionIdEntry::new(self.next_seqno, cid.clone(), ()));
self.next_seqno += 1;
The change ensures proper sequence number tracking and incrementing, which was previously inconsistent and could lead to security issues in connection ID generation.
Note: While these appear to be security-related fixes, the exact vulnerability names might be different depending on the broader context of the QUIC protocol implementation. The fixes primarily address potential security issues related to connection ID management and sequence number generation.
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/unit/test_tls_server.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/netwerk/test/unit/test_tls_server.js@@ -37,6 +37,20 @@ }); }+function areCertsEqual(certA, certB) {+ let derA = certA.getRawDER();+ let derB = certB.getRawDER();+ if (derA.length != derB.length) {+ return false;+ }+ for (let i = 0; i < derA.length; i++) {+ if (derA[i] != derB[i]) {+ return false;+ }+ }+ return true;+}+ function startServer( cert, expectingPeerCert,@@ -66,7 +80,10 @@ info("TLS handshake done"); if (expectingPeerCert) { ok(!!status.peerCert, "Has peer cert");- ok(status.peerCert.equals(cert), "Peer cert matches expected cert");+ ok(+ areCertsEqual(status.peerCert, cert),+ "Peer cert matches expected cert"+ ); } else { ok(!status.peerCert, "No peer cert (as expected)"); }
Here's the analysis of the provided code diff: 1. Vulnerability Existed: yes Insecure Certificate Comparison [netwerk/test/unit/test_tls_server.js] [Lines 66] [Old Code] `ok(status.peerCert.equals(cert), "Peer cert matches expected cert");` [Fixed Code] `ok(areCertsEqual(status.peerCert, cert), "Peer cert matches expected cert");` Additional Details: - The vulnerability was in the certificate comparison method. The old code used a potentially insecure `.equals()` method which might not perform a thorough comparison of certificate contents. - The fix introduces a new `areCertsEqual()` function that performs a byte-by-byte comparison of the raw DER-encoded certificates, ensuring a more secure and accurate comparison. - While not explicitly named in security databases, this type of change typically addresses potential certificate validation bypass vulnerabilities where superficial comparisons might allow invalid certificates to be accepted. Note: The diff also adds the new `areCertsEqual()` helper function (lines 37-49), but this is part of the fix rather than a separate 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/testing/web-platform/tests/css/selectors/old-tests/css3-modsel-28.xml+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/selectors/old-tests/css3-modsel-28.xml@@ -9,7 +9,6 @@ table.t2 td:nth-child(3n+1) { background-color : lime }]]></style> <link rel="author" title="Daniel Glazman" href="http://glazman.org/"/> <link rel="help" href="https://www.w3.org/TR/css3-selectors/#selectors"/> <!-- bogus link to make sure it gets found -->- <meta name="flags" content="" /> </head> <body> <ul>
Let me analyze the diff for potential security vulnerabilities. Vulnerability Existed: no Meta Tag Removal [File] [Lines 9] [Old Code] <meta name="flags" content="" /> [Fixed Code] (removed) Additional Details: - This appears to be a simple removal of an empty meta tag that wasn't serving any purpose - The "flags" meta tag was commonly used in test files but doesn't pose any security risk - No actual vulnerability was fixed here, just test file cleanup Vulnerability Existed: no The diff shows only the removal of an empty meta tag which doesn't relate to any security issues. The change appears to be test file maintenance 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.