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/third_party/rust/libc/src/unix/linux_like/linux/mod.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/libc/src/unix/linux_like/linux/mod.rs@@ -2583,6 +2583,7 @@ // include/uapi/asm-generic/mman-common.h pub const MAP_FIXED_NOREPLACE: ::c_int = 0x100000;+pub const MLOCK_ONFAULT: ::c_uint = 0x01; // uapi/linux/vm_sockets.h pub const VMADDR_CID_ANY: ::c_uint = 0xFFFFFFFF;@@ -3533,6 +3534,7 @@ pub fn seekdir(dirp: *mut ::DIR, loc: ::c_long); pub fn telldir(dirp: *mut ::DIR) -> ::c_long;+ pub fn mlock2(addr: *const ::c_void, len: ::size_t, flags: ::c_uint) -> ::c_int; pub fn madvise(addr: *mut ::c_void, len: ::size_t, advice: ::c_int) -> ::c_int; pub fn msync(addr: *mut ::c_void, len: ::size_t, flags: ::c_int) -> ::c_int;
Here's the analysis of the provided code diff following the specified format: 1. Vulnerability Existed: not sure [Potential Memory Locking Enhancement] [third_party/rust/libc/src/unix/linux_like/linux/mod.rs] [Lines 2583-2584, 3533-3534] [Old Code] (No MLOCK_ONFAULT constant or mlock2 function) [Fixed Code] ```rust pub const MLOCK_ONFAULT: ::c_uint = 0x01; pub fn mlock2(addr: *const ::c_void, len: ::size_t, flags: ::c_uint) -> ::c_int; ``` Additional Details: The diff adds support for MLOCK_ONFAULT flag and mlock2 system call. This appears to be adding functionality rather than fixing a security vulnerability. The MLOCK_ONFAULT flag allows for more granular memory locking (only locking pages when they're faulted in), which could be considered a security enhancement by providing better control over memory locking behavior, but I cannot identify a specific vulnerability being fixed. The change seems to be adding support for newer kernel features rather than patching a security hole. No clear vulnerability is being fixed here - this appears to be adding support for new functionality (mlock2 system call with MLOCK_ONFAULT flag) that was introduced in Linux kernels. The mlock2 system call with MLOCK_ONFAULT provides more control over memory locking behavior, but this is an enhancement 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/third_party/rust/glean-core/src/ping/mod.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/glean-core/src/ping/mod.rs@@ -15,7 +15,7 @@ use crate::metrics::{CounterMetric, DatetimeMetric, Metric, MetricType, PingType, TimeUnit}; use crate::storage::StorageManager; use crate::upload::HeaderMap;-use crate::util::{get_iso_time_string, local_now_with_offset_and_record};+use crate::util::{get_iso_time_string, local_now_with_offset}; use crate::{ Glean, Result, DELETION_REQUEST_PINGS_DIRECTORY, INTERNAL_STORAGE, PENDING_PINGS_DIRECTORY, };@@ -112,7 +112,7 @@ let start_time_data = start_time .get_value(glean, INTERNAL_STORAGE) .unwrap_or_else(|| glean.start_time());- let end_time_data = local_now_with_offset_and_record(glean);+ let end_time_data = local_now_with_offset(); // Update the start time with the current time. start_time.set(glean, Some(end_time_data));
Let me analyze the diff for potential security vulnerabilities:
1. Vulnerability Existed: not sure
[Potential Time Zone Information Leak] [third_party/rust/glean-core/src/ping/mod.rs] [Lines 15, 112]
[Old Code]
use crate::util::{get_iso_time_string, local_now_with_offset_and_record};
...
let end_time_data = local_now_with_offset_and_record(glean);
[Fixed Code]
use crate::util::{get_iso_time_string, local_now_with_offset};
...
let end_time_data = local_now_with_offset();
Analysis: The change removes the `_and_record` suffix from the time function call, suggesting it no longer records timezone information. This could potentially address information leakage about the user's timezone, but without seeing the implementation details of both functions, I can't be certain. The removal of the `glean` parameter suggests less tracking is being done.
2. Vulnerability Existed: not sure
[Potential Information Exposure Through Timing] [third_party/rust/glean-core/src/ping/mod.rs] [Lines 112]
[Old Code]
let end_time_data = local_now_with_offset_and_record(glean);
[Fixed Code]
let end_time_data = local_now_with_offset();
Analysis: The removal of passing the `glean` object to the time function might reduce the amount of information being recorded or tracked, potentially addressing some information exposure concerns. However, without seeing what `local_now_with_offset_and_record` was doing with the glean object, this is uncertain.
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/python/taskcluster_taskgraph/taskgraph/parameters.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/python/taskcluster_taskgraph/taskgraph/parameters.py@@ -9,10 +9,10 @@ import time from datetime import datetime from pprint import pformat+from subprocess import CalledProcessError from urllib.parse import urlparse from urllib.request import urlopen-from taskgraph.util.memoize import memoize from taskgraph.util.readonlydict import ReadOnlyDict from taskgraph.util.schema import validate_schema from taskgraph.util.vcs import get_repository@@ -26,11 +26,6 @@ class ParameterMismatch(Exception): """Raised when a parameters.yml has extra or missing parameters."""---@memoize-def _repo():- return get_repository(os.getcwd()) # Please keep this list sorted and in sync with taskcluster/docs/parameters.rst@@ -64,25 +59,33 @@ )-def _get_defaults():+def _get_defaults(repo_root=None):+ repo = get_repository(repo_root or os.getcwd())+ try:+ repo_url = repo.get_url()+ project = repo_url.rsplit("/", 1)[1]+ except CalledProcessError:+ repo_url = ""+ project = ""+ return {- "base_repository": _repo().get_url(),+ "base_repository": repo_url, "build_date": int(time.time()), "do_not_optimize": [], "existing_tasks": {}, "filters": ["target_tasks_method"],- "head_ref": _repo().head_ref,- "head_repository": _repo().get_url(),- "head_rev": _repo().head_ref,+ "head_ref": repo.head_ref,+ "head_repository": repo_url,+ "head_rev": repo.head_ref, "head_tag": "", "level": "3", "moz_build_date": datetime.now().strftime("%Y%m%d%H%M%S"), "optimize_target_tasks": True, "owner": "[email protected]",- "project": _repo().get_url().rsplit("/", 1)[1],+ "project": project, "pushdate": int(time.time()), "pushlog_id": "0",- "repository_type": _repo().tool,+ "repository_type": repo.tool, "target_tasks_method": "default", "tasks_for": "", }@@ -115,14 +118,14 @@ class Parameters(ReadOnlyDict): """An immutable dictionary with nicer KeyError messages on failure"""- def __init__(self, strict=True, **kwargs):+ def __init__(self, strict=True, repo_root=None, **kwargs): self.strict = strict self.spec = kwargs.pop("spec", None) self._id = None if not self.strict: # apply defaults to missing parameters- kwargs = Parameters._fill_defaults(**kwargs)+ kwargs = Parameters._fill_defaults(repo_root=repo_root, **kwargs) ReadOnlyDict.__init__(self, **kwargs)@@ -159,10 +162,10 @@ return os.path.splitext(os.path.basename(spec))[0] @staticmethod- def _fill_defaults(**kwargs):+ def _fill_defaults(repo_root=None, **kwargs): defaults = {} for fn in defaults_functions:- defaults.update(fn())+ defaults.update(fn(repo_root)) for name, default in defaults.items(): if name not in kwargs:@@ -257,7 +260,9 @@ return pformat(dict(self), indent=2)-def load_parameters_file(spec, strict=True, overrides=None, trust_domain=None):+def load_parameters_file(+ spec, strict=True, overrides=None, trust_domain=None, repo_root=None+): """ Load parameters from a path, url, decision task-id or project.@@ -273,7 +278,7 @@ overrides["spec"] = spec if not spec:- return Parameters(strict=strict, **overrides)+ return Parameters(strict=strict, repo_root=repo_root, **overrides) try: # reading parameters from a local parameters.yml file@@ -307,15 +312,21 @@ raise TypeError(f"Parameters file `{spec}` is not JSON or YAML") kwargs.update(overrides)- return Parameters(strict=strict, **kwargs)+ return Parameters(strict=strict, repo_root=repo_root, **kwargs) def parameters_loader(spec, strict=True, overrides=None): def get_parameters(graph_config):+ try:+ repo_root = graph_config.vcs_root+ except Exception:+ repo_root = None+ parameters = load_parameters_file( spec, strict=strict, overrides=overrides,+ repo_root=repo_root, trust_domain=graph_config["trust-domain"], ) parameters.check()
Here's the analysis of the provided code diff for security fixes:
1. Vulnerability Existed: yes
Vulnerability Name: Insecure Default Parameter Initialization [File] [Lines]
File: third_party/python/taskcluster_taskgraph/taskgraph/parameters.py
Old Code:
```python
@memoize
def _repo():
return get_repository(os.getcwd())
def _get_defaults():
return {
"base_repository": _repo().get_url(),
...
}
```
Fixed Code:
```python
def _get_defaults(repo_root=None):
repo = get_repository(repo_root or os.getcwd())
try:
repo_url = repo.get_url()
project = repo_url.rsplit("/", 1)[1]
except CalledProcessError:
repo_url = ""
project = ""
return {
"base_repository": repo_url,
...
}
```
Additional Details: The fix removes the memoized repository function and adds proper error handling for repository operations, making the code more robust against potential repository access failures.
2. Vulnerability Existed: not sure
Vulnerability Name: Potential Information Leak Through Error Messages [File] [Lines]
File: third_party/python/taskcluster_taskgraph/taskgraph/parameters.py
Old Code: No explicit error handling for repository operations
Fixed Code:
```python
try:
repo_url = repo.get_url()
project = repo_url.rsplit("/", 1)[1]
except CalledProcessError:
repo_url = ""
project = ""
```
Additional Details: The added error handling prevents potential information leaks through error messages when repository operations fail, though it's not clear if this was previously exploitable.
3. Vulnerability Existed: yes
Vulnerability Name: Inconsistent Repository Root Handling [File] [Lines]
File: third_party/python/taskcluster_taskgraph/taskgraph/parameters.py
Old Code: Hardcoded use of os.getcwd() for repository operations
Fixed Code: Added repo_root parameter throughout the call chain
```python
def _get_defaults(repo_root=None):
repo = get_repository(repo_root or os.getcwd())
...
```
Additional Details: The fix allows for explicit control of the repository root directory, preventing potential issues with working directory assumptions.
The changes primarily focus on making the repository handling more robust and configurable, with better error handling and removal of potentially problematic caching (memoization) of repository information.
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/semantics/interactive-elements/the-dialog-element/modal-dialog-scroll-height.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/semantics/interactive-elements/the-dialog-element/modal-dialog-scroll-height.html@@ -27,6 +27,6 @@ <script> test(() => { document.querySelector('dialog').showModal();- assert_equals(document.scrollingElement.scrollHeight, 600);+ assert_equals(document.scrollingElement.scrollHeight, window.innerHeight); }, 'dialogs should be centered before computing overflow.'); </script>
Here's the analysis of the provided code diff: Vulnerability Existed: no [No specific vulnerability] [testing/web-platform/tests/html/semantics/interactive-elements/the-dialog-element/modal-dialog-scroll-height.html] [Lines 27-30] [Old Code] assert_equals(document.scrollingElement.scrollHeight, 600); [Fixed Code] assert_equals(document.scrollingElement.scrollHeight, window.innerHeight); Additional Details: This appears to be a test case modification rather than a security fix. The change updates the expected scroll height value from a hardcoded 600 to use window.innerHeight, which is more dynamic and accurate for testing purposes. There's no clear security vulnerability being addressed here - it's more likely a test improvement to make it more reliable across different viewport sizes.
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.clip.empty.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.clip.empty.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 = '#0f0'; ctx.fillRect(0, 0, 100, 50);@@ -22,7 +22,7 @@ ctx.clip(); ctx.fillStyle = '#f00'; 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 vulnerabilities being fixed. The changes appear to be purely variable renaming for better clarity/consistency. Here's my analysis:
1. Vulnerability Existed: no
Variable Renaming [testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.clip.empty.worker.js] [Lines 13-22]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
[...]
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
[...]
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes simply rename the variable from `offscreenCanvas` to `canvas` throughout the file. There are no security implications to this change - it's purely a code style/readability improvement. No security vulnerabilities were identified in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.arcTo.coincide.2.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.arcTo.coincide.2.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -28,7 +28,7 @@ ctx.moveTo(0, 25); ctx.arcTo(100, 25, 100, 25, 1); 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(); });
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely cosmetic/refactoring changes (variable renaming) rather than security-related fixes.
Here's the analysis following your requested format:
Vulnerability Existed: no
[No security vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.arcTo.coincide.2.html] [17-28]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes simply rename the variable `offscreenCanvas` to `canvas` and update all references to it. There are no security implications to this change.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/css-pseudo/active-selection-057.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-pseudo/active-selection-057.html@@ -8,7 +8,6 @@ <link rel="help" href="https://www.w3.org/TR/css-pseudo-4/#highlight-selectors"> <link rel="match" href="../reference/ref-nothing-below.xht">- <meta content="" name="flags"> <meta name="assert" content="The <div id="subtest1"> element and the <hr> element in this test are empty elements. Their background color can be painted but specifying their 'color' should generate no rendering effect of any kind. Since the 'background-color' has not been specified in the ::selection pseudo-element, then it defaults to 'transparent'. The <div id="subtest3"> element is also an empty element since the 2 &NewLine; character references are line break control characters. Their background color can not be painted. Therefore, in this test, nothing should be painted or viewable. The fact that lines break at preserved newline characters thanks to 'white-space: pre' does not change that."> <style>
Based on the provided diff, I'll analyze it for security fixes: Vulnerability Existed: no No security vulnerability found [File] testing/web-platform/tests/css/css-pseudo/active-selection-057.html [Lines 8] Old Code: <meta content="" name="flags"> Fixed Code: (removed line) Additional Details: 1. The change simply removes an empty meta tag with a "flags" attribute, which appears to be test-related metadata rather than security-related. 2. There's no indication of any security vulnerability being fixed here - this seems to be just a test file cleanup. 3. The "flags" meta tag doesn't appear to have any security implications in this context. 4. The rest of the changes are just test assertions and styling, unrelated to 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/taskcluster/gecko_taskgraph/test/test_optimize_strategies.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/taskcluster/gecko_taskgraph/test/test_optimize_strategies.py@@ -117,7 +117,10 @@ def idfn(param): if isinstance(param, tuple):- return param[0].__name__+ try:+ return param[0].__name__+ except AttributeError:+ return None return None
Let me analyze the code diff for potential security vulnerabilities.
Vulnerability Existed: not sure
[Potential AttributeError Handling] [taskcluster/gecko_taskgraph/test/test_optimize_strategies.py] [Lines 117-121]
[Old Code]
def idfn(param):
if isinstance(param, tuple):
return param[0].__name__
return None
[Fixed Code]
def idfn(param):
if isinstance(param, tuple):
try:
return param[0].__name__
except AttributeError:
return None
return None
Additional Details:
The change adds error handling for cases where param[0] might not have a __name__ attribute. While this improves code robustness, it's not clear if this was fixing an actual security vulnerability or just making the code more defensive. The original code could potentially raise an AttributeError, but this would typically be caught during testing rather than representing a security issue.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/security/nss/build.sh+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/security/nss/build.sh@@ -67,10 +67,6 @@ gyp_params=(--depth="$cwd" --generator-output=".") ninja_params=()--# Assume that the target architecture is the same as the host by default.-host_arch=$(python "$cwd/coreconf/detect_host_arch.py")-target_arch=$host_arch # Assume that MSVC is wanted if this is running on windows. platform=$(uname -s)@@ -132,11 +128,23 @@ --disable-keylog) sslkeylogfile=0 ;; --enable-legacy-db) gyp_params+=(-Ddisable_dbm=0) ;; --mozilla-central) gyp_params+=(-Dmozilla_central=1) ;;+ --python) python="$2"; shift ;;+ --python=*) python="${1#*=}" ;; -D*) gyp_params+=("$1") ;; *) show_help; exit 2 ;; esac shift done++if [ -n "$python" ]; then+ gyp_params+=(-Dpython="$python")+fi++if [ -z "$target_arch" ]; then+ # Assume that the target architecture is the same as the host by default.+ host_arch=$(${python:-python} "$cwd/coreconf/detect_host_arch.py")+ target_arch=$host_arch+fi # Set the target architecture and build type. gyp_params+=(-Dtarget_arch="$target_arch")
Analyzing the provided code diff, here are the security-related findings:
1. Vulnerability Existed: not sure
[Potential Command Injection] [File: security/nss/build.sh] [Lines: 132-142]
[Old Code]
--disable-keylog) sslkeylogfile=0 ;;
--enable-legacy-db) gyp_params+=(-Ddisable_dbm=0) ;;
--mozilla-central) gyp_params+=(-Dmozilla_central=1) ;;
[Fixed Code]
--disable-keylog) sslkeylogfile=0 ;;
--enable-legacy-db) gyp_params+=(-Ddisable_dbm=0) ;;
--mozilla-central) gyp_params+=(-Dmozilla_central=1) ;;
--python) python="$2"; shift ;;
--python=*) python="${1#*=}" ;;
Additional Details:
- The change adds Python interpreter path handling, which could potentially be vulnerable to command injection if the input isn't properly sanitized, though there's no direct evidence of vulnerability in this specific change.
2. Vulnerability Existed: not sure
[Potential Insecure Default Python Interpreter] [File: security/nss/build.sh] [Lines: 67-68, 128-142]
[Old Code]
host_arch=$(python "$cwd/coreconf/detect_host_arch.py")
target_arch=$host_arch
[Fixed Code]
if [ -z "$target_arch" ]; then
# Assume that the target architecture is the same as the host by default.
host_arch=$(${python:-python} "$cwd/coreconf/detect_host_arch.py")
target_arch=$host_arch
fi
Additional Details:
- The change makes the Python interpreter configurable rather than hardcoded, which could be a security improvement if the default system Python was considered potentially unsafe. However, this might also introduce new attack vectors if the Python path can be controlled by an attacker.
Note: While these changes appear to be security-related improvements, I cannot definitively state they are fixing specific known vulnerabilities without more context about the threat model and attack scenarios.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/naga/src/front/spv/mod.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/naga/src/front/spv/mod.rs@@ -499,6 +499,11 @@ parameter_sampling: &'function mut [image::SamplingFlags], }+enum SignAnchor {+ Result,+ Operand,+}+ pub struct Parser<I> { data: I, data_offset: usize,@@ -849,38 +854,35 @@ Ok(()) }- /// A more complicated version of the binary op,+ /// A more complicated version of the unary op, /// where we force the operand to have the same type as the result.- /// This is mostly needed for "i++" and "i--" coming from GLSL.- fn parse_expr_binary_op_sign_adjusted(+ fn parse_expr_unary_op_sign_adjusted( &mut self, ctx: &mut BlockContext, emitter: &mut super::Emitter, block: &mut crate::Block, block_id: spirv::Word, body_idx: usize,- op: crate::BinaryOperator,+ op: crate::UnaryOperator, ) -> Result<(), Error> { let start = self.data_offset; let result_type_id = self.next()?; let result_id = self.next()?; let p1_id = self.next()?;- let p2_id = self.next()?; let span = self.span_from_with_op(start); let p1_lexp = self.lookup_expression.lookup(p1_id)?; let left = self.get_expr_handle(p1_id, p1_lexp, ctx, emitter, block, body_idx);- let p2_lexp = self.lookup_expression.lookup(p2_id)?;- let right = self.get_expr_handle(p2_id, p2_lexp, ctx, emitter, block, body_idx);+ let result_lookup_ty = self.lookup_type.lookup(result_type_id)?; let kind = ctx.type_arena[result_lookup_ty.handle] .inner .scalar_kind() .unwrap();- let expr = crate::Expression::Binary {+ let expr = crate::Expression::Unary { op,- left: if p1_lexp.type_id == result_type_id {+ expr: if p1_lexp.type_id == result_type_id { left } else { ctx.expressions.append(@@ -892,7 +894,73 @@ span, ) },- right: if p2_lexp.type_id == result_type_id {+ };++ self.lookup_expression.insert(+ result_id,+ LookupExpression {+ handle: ctx.expressions.append(expr, span),+ type_id: result_type_id,+ block_id,+ },+ );+ Ok(())+ }++ /// A more complicated version of the binary op,+ /// where we force the operand to have the same type as the result.+ /// This is mostly needed for "i++" and "i--" coming from GLSL.+ #[allow(clippy::too_many_arguments)]+ fn parse_expr_binary_op_sign_adjusted(+ &mut self,+ ctx: &mut BlockContext,+ emitter: &mut super::Emitter,+ block: &mut crate::Block,+ block_id: spirv::Word,+ body_idx: usize,+ op: crate::BinaryOperator,+ // For arithmetic operations, we need the sign of operands to match the result.+ // For boolean operations, however, the operands need to match the signs, but+ // result is always different - a boolean.+ anchor: SignAnchor,+ ) -> Result<(), Error> {+ let start = self.data_offset;+ let result_type_id = self.next()?;+ let result_id = self.next()?;+ let p1_id = self.next()?;+ let p2_id = self.next()?;+ let span = self.span_from_with_op(start);++ let p1_lexp = self.lookup_expression.lookup(p1_id)?;+ let left = self.get_expr_handle(p1_id, p1_lexp, ctx, emitter, block, body_idx);+ let p2_lexp = self.lookup_expression.lookup(p2_id)?;+ let right = self.get_expr_handle(p2_id, p2_lexp, ctx, emitter, block, body_idx);++ let expected_type_id = match anchor {+ SignAnchor::Result => result_type_id,+ SignAnchor::Operand => p1_lexp.type_id,+ };+ let expected_lookup_ty = self.lookup_type.lookup(expected_type_id)?;+ let kind = ctx.type_arena[expected_lookup_ty.handle]+ .inner+ .scalar_kind()+ .unwrap();++ let expr = crate::Expression::Binary {+ op,+ left: if p1_lexp.type_id == expected_type_id {+ left+ } else {+ ctx.expressions.append(+ crate::Expression::As {+ expr: left,+ kind,+ convert: None,+ },+ span,+ )+ },+ right: if p2_lexp.type_id == expected_type_id { right } else { ctx.expressions.append(@@ -1076,6 +1144,7 @@ selections: &[spirv::Word], type_arena: &UniqueArena<crate::Type>, expressions: &mut Arena<crate::Expression>,+ constants: &Arena<crate::Constant>, span: crate::Span, ) -> Result<Handle<crate::Expression>, Error> { let selection = match selections.first() {@@ -1092,7 +1161,29 @@ .ok_or(Error::InvalidAccessType(root_type_id))?; (members.len(), child_member.type_id) }- // crate::TypeInner::Array //TODO?+ crate::TypeInner::Array { size, .. } => {+ let size = match size {+ crate::ArraySize::Constant(handle) => match constants[handle] {+ crate::Constant {+ specialization: Some(_),+ ..+ } => return Err(Error::UnsupportedType(root_lookup.handle)),+ ref unspecialized => unspecialized+ .to_array_length()+ .ok_or(Error::InvalidArraySize(handle))?,+ },+ // A runtime sized array is not a composite type+ crate::ArraySize::Dynamic => {+ return Err(Error::InvalidAccessType(root_type_id))+ }+ };++ let child_type_id = root_lookup+ .base_id+ .ok_or(Error::InvalidAccessType(root_type_id))?;++ (size as usize, child_type_id)+ } crate::TypeInner::Vector { size, .. } | crate::TypeInner::Matrix { columns: size, .. } => { let child_type_id = root_lookup@@ -1121,6 +1212,7 @@ &selections[1..], type_arena, expressions,+ constants, span, )?;@@ -1595,7 +1687,24 @@ let root_handle = get_expr_handle!(composite_id, root_lexp); let root_type_lookup = self.lookup_type.lookup(root_lexp.type_id)?; let index_lexp = self.lookup_expression.lookup(index_id)?;- let index_handle = get_expr_handle!(index_id, index_lexp);+ let mut index_handle = get_expr_handle!(index_id, index_lexp);+ let index_type = self.lookup_type.lookup(index_lexp.type_id)?.handle;++ // SPIR-V allows signed and unsigned indices but naga's is strict about+ // types and since the `index_constants` are all signed integers, we need+ // to cast the index to a signed integer if it's unsigned.+ if let Some(crate::ScalarKind::Uint) =+ ctx.type_arena[index_type].inner.scalar_kind()+ {+ index_handle = ctx.expressions.append(+ crate::Expression::As {+ expr: index_handle,+ kind: crate::ScalarKind::Sint,+ convert: None,+ },+ span,+ )+ } let num_components = match ctx.type_arena[root_type_lookup.handle].inner { crate::TypeInner::Vector { size, .. } => size as usize,@@ -1720,6 +1829,7 @@ &selections, ctx.type_arena, ctx.expressions,+ ctx.const_arena, span, )?;@@ -1832,9 +1942,24 @@ // Arithmetic Instructions +, -, *, /, % Op::SNegate | Op::FNegate => { inst.expect(4)?;- parse_expr_op!(crate::UnaryOperator::Negate, UNARY)?;- }- Op::IAdd | Op::ISub => {+ self.parse_expr_unary_op_sign_adjusted(+ ctx,+ &mut emitter,+ &mut block,+ block_id,+ body_idx,+ crate::UnaryOperator::Negate,+ )?;+ }+ Op::IAdd+ | Op::ISub+ | Op::IMul+ | Op::BitwiseOr+ | Op::BitwiseXor+ | Op::BitwiseAnd+ | Op::SDiv+ | Op::SMod+ | Op::SRem => { inst.expect(5)?; let operator = map_binary_operator(inst.op)?; self.parse_expr_binary_op_sign_adjusted(@@ -1844,6 +1969,20 @@ block_id, body_idx, operator,+ SignAnchor::Result,+ )?;+ }+ Op::IEqual | Op::INotEqual => {+ inst.expect(5)?;+ let operator = map_binary_operator(inst.op)?;+ self.parse_expr_binary_op_sign_adjusted(+ ctx,+ &mut emitter,+ &mut block,+ block_id,+ body_idx,+ operator,+ SignAnchor::Operand, )?; } Op::FAdd => {@@ -1854,15 +1993,15 @@ inst.expect(5)?; parse_expr_op!(crate::BinaryOperator::Subtract, BINARY)?; }- Op::IMul | Op::FMul => {+ Op::FMul => { inst.expect(5)?; parse_expr_op!(crate::BinaryOperator::Multiply, BINARY)?; }- Op::SDiv | Op::UDiv | Op::FDiv => {+ Op::UDiv | Op::FDiv => { inst.expect(5)?; parse_expr_op!(crate::BinaryOperator::Divide, BINARY)?; }- Op::SMod | Op::UMod | Op::FMod | Op::SRem | Op::FRem => {+ Op::UMod | Op::FMod | Op::FRem => { inst.expect(5)?; parse_expr_op!(crate::BinaryOperator::Modulo, BINARY)?; }@@ -2097,19 +2236,14 @@ // Bitwise instructions Op::Not => { inst.expect(4)?;- parse_expr_op!(crate::UnaryOperator::Not, UNARY)?;- }- Op::BitwiseOr => {- inst.expect(5)?;- parse_expr_op!(crate::BinaryOperator::InclusiveOr, BINARY)?;- }- Op::BitwiseXor => {- inst.expect(5)?;- parse_expr_op!(crate::BinaryOperator::ExclusiveOr, BINARY)?;- }- Op::BitwiseAnd => {- inst.expect(5)?;- parse_expr_op!(crate::BinaryOperator::And, BINARY)?;+ self.parse_expr_unary_op_sign_adjusted(+ ctx,+ &mut emitter,+ &mut block,+ block_id,+ body_idx,+ crate::UnaryOperator::Not,+ )?; } Op::ShiftRightLogical => { inst.expect(5)?;@@ -2400,7 +2534,9 @@ let expr = crate::Expression::As { expr: get_expr_handle!(value_id, value_lexp), kind,- convert: if inst.op == Op::Bitcast {+ convert: if kind == crate::ScalarKind::Bool {+ Some(crate::BOOL_WIDTH)+ } else if inst.op == Op::Bitcast { None } else { Some(width)@@ -2475,157 +2611,115 @@ let inst_id = self.next()?; let gl_op = Glo::from_u32(inst_id).ok_or(Error::UnsupportedExtInst(inst_id))?;- if gl_op == Glo::Radians || gl_op == Glo::Degrees {- inst.expect(base_wc + 1)?;- let arg = {- let arg_id = self.next()?;- let lexp = self.lookup_expression.lookup(arg_id)?;- get_expr_handle!(arg_id, lexp)- };-- let constant_handle = ctx.const_arena.fetch_or_append(- crate::Constant {- name: None,- specialization: None,- inner: crate::ConstantInner::Scalar {- width: 4,- value: crate::ScalarValue::Float(match gl_op {- Glo::Radians => std::f64::consts::PI / 180.0,- Glo::Degrees => 180.0 / std::f64::consts::PI,- _ => unreachable!(),- }),- },- },- Default::default(),- );-- let expr_handle = ctx.expressions.append(- crate::Expression::Constant(constant_handle),- Default::default(),- );-- self.lookup_expression.insert(- result_id,- LookupExpression {- handle: ctx.expressions.append(- crate::Expression::Binary {- op: crate::BinaryOperator::Multiply,- left: arg,- right: expr_handle,- },- span,- ),- type_id: result_type_id,- block_id,- },- );+ let fun = match gl_op {+ Glo::Round => Mf::Round,+ Glo::RoundEven => Mf::Round,+ Glo::Trunc => Mf::Trunc,+ Glo::FAbs | Glo::SAbs => Mf::Abs,+ Glo::FSign | Glo::SSign => Mf::Sign,+ Glo::Floor => Mf::Floor,+ Glo::Ceil => Mf::Ceil,+ Glo::Fract => Mf::Fract,+ Glo::Sin => Mf::Sin,+ Glo::Cos => Mf::Cos,+ Glo::Tan => Mf::Tan,+ Glo::Asin => Mf::Asin,+ Glo::Acos => Mf::Acos,+ Glo::Atan => Mf::Atan,+ Glo::Sinh => Mf::Sinh,+ Glo::Cosh => Mf::Cosh,+ Glo::Tanh => Mf::Tanh,+ Glo::Atan2 => Mf::Atan2,+ Glo::Asinh => Mf::Asinh,+ Glo::Acosh => Mf::Acosh,+ Glo::Atanh => Mf::Atanh,+ Glo::Radians => Mf::Radians,+ Glo::Degrees => Mf::Degrees,+ Glo::Pow => Mf::Pow,+ Glo::Exp => Mf::Exp,+ Glo::Log => Mf::Log,+ Glo::Exp2 => Mf::Exp2,+ Glo::Log2 => Mf::Log2,+ Glo::Sqrt => Mf::Sqrt,+ Glo::InverseSqrt => Mf::InverseSqrt,+ Glo::MatrixInverse => Mf::Inverse,+ Glo::Determinant => Mf::Determinant,+ Glo::Modf => Mf::Modf,+ Glo::FMin | Glo::UMin | Glo::SMin | Glo::NMin => Mf::Min,+ Glo::FMax | Glo::UMax | Glo::SMax | Glo::NMax => Mf::Max,+ Glo::FClamp | Glo::UClamp | Glo::SClamp | Glo::NClamp => Mf::Clamp,+ Glo::FMix => Mf::Mix,+ Glo::Step => Mf::Step,+ Glo::SmoothStep => Mf::SmoothStep,+ Glo::Fma => Mf::Fma,+ Glo::Frexp => Mf::Frexp, //TODO: FrexpStruct?+ Glo::Ldexp => Mf::Ldexp,+ Glo::Length => Mf::Length,+ Glo::Distance => Mf::Distance,+ Glo::Cross => Mf::Cross,+ Glo::Normalize => Mf::Normalize,+ Glo::FaceForward => Mf::FaceForward,+ Glo::Reflect => Mf::Reflect,+ Glo::Refract => Mf::Refract,+ Glo::PackUnorm4x8 => Mf::Pack4x8unorm,+ Glo::PackSnorm4x8 => Mf::Pack4x8snorm,+ Glo::PackHalf2x16 => Mf::Pack2x16float,+ Glo::PackUnorm2x16 => Mf::Pack2x16unorm,+ Glo::PackSnorm2x16 => Mf::Pack2x16snorm,+ Glo::UnpackUnorm4x8 => Mf::Unpack4x8unorm,+ Glo::UnpackSnorm4x8 => Mf::Unpack4x8snorm,+ Glo::UnpackHalf2x16 => Mf::Unpack2x16float,+ Glo::UnpackUnorm2x16 => Mf::Unpack2x16unorm,+ Glo::UnpackSnorm2x16 => Mf::Unpack2x16snorm,+ Glo::FindILsb => Mf::FindLsb,+ Glo::FindUMsb | Glo::FindSMsb => Mf::FindMsb,+ _ => return Err(Error::UnsupportedExtInst(inst_id)),+ };++ let arg_count = fun.argument_count();+ inst.expect(base_wc + arg_count as u16)?;+ let arg = {+ let arg_id = self.next()?;+ let lexp = self.lookup_expression.lookup(arg_id)?;+ get_expr_handle!(arg_id, lexp)+ };+ let arg1 = if arg_count > 1 {+ let arg_id = self.next()?;+ let lexp = self.lookup_expression.lookup(arg_id)?;+ Some(get_expr_handle!(arg_id, lexp)) } else {- let fun = match gl_op {- Glo::Round => Mf::Round,- Glo::RoundEven => Mf::Round,- Glo::Trunc => Mf::Trunc,- Glo::FAbs | Glo::SAbs => Mf::Abs,- Glo::FSign | Glo::SSign => Mf::Sign,- Glo::Floor => Mf::Floor,- Glo::Ceil => Mf::Ceil,- Glo::Fract => Mf::Fract,- Glo::Sin => Mf::Sin,- Glo::Cos => Mf::Cos,- Glo::Tan => Mf::Tan,- Glo::Asin => Mf::Asin,- Glo::Acos => Mf::Acos,- Glo::Atan => Mf::Atan,- Glo::Sinh => Mf::Sinh,- Glo::Cosh => Mf::Cosh,- Glo::Tanh => Mf::Tanh,- Glo::Atan2 => Mf::Atan2,- Glo::Asinh => Mf::Asinh,- Glo::Acosh => Mf::Acosh,- Glo::Atanh => Mf::Atanh,- Glo::Pow => Mf::Pow,- Glo::Exp => Mf::Exp,- Glo::Log => Mf::Log,- Glo::Exp2 => Mf::Exp2,- Glo::Log2 => Mf::Log2,- Glo::Sqrt => Mf::Sqrt,- Glo::InverseSqrt => Mf::InverseSqrt,- Glo::MatrixInverse => Mf::Inverse,- Glo::Determinant => Mf::Determinant,- Glo::Modf => Mf::Modf,- Glo::FMin | Glo::UMin | Glo::SMin | Glo::NMin => Mf::Min,- Glo::FMax | Glo::UMax | Glo::SMax | Glo::NMax => Mf::Max,- Glo::FClamp | Glo::UClamp | Glo::SClamp | Glo::NClamp => Mf::Clamp,- Glo::FMix => Mf::Mix,- Glo::Step => Mf::Step,- Glo::SmoothStep => Mf::SmoothStep,- Glo::Fma => Mf::Fma,- Glo::Frexp => Mf::Frexp, //TODO: FrexpStruct?- Glo::Ldexp => Mf::Ldexp,- Glo::Length => Mf::Length,- Glo::Distance => Mf::Distance,- Glo::Cross => Mf::Cross,- Glo::Normalize => Mf::Normalize,- Glo::FaceForward => Mf::FaceForward,- Glo::Reflect => Mf::Reflect,- Glo::Refract => Mf::Refract,- Glo::PackUnorm4x8 => Mf::Pack4x8unorm,- Glo::PackSnorm4x8 => Mf::Pack4x8snorm,- Glo::PackHalf2x16 => Mf::Pack2x16float,- Glo::PackUnorm2x16 => Mf::Pack2x16unorm,- Glo::PackSnorm2x16 => Mf::Pack2x16snorm,- Glo::UnpackUnorm4x8 => Mf::Unpack4x8unorm,- Glo::UnpackSnorm4x8 => Mf::Unpack4x8snorm,- Glo::UnpackHalf2x16 => Mf::Unpack2x16float,- Glo::UnpackUnorm2x16 => Mf::Unpack2x16unorm,- Glo::UnpackSnorm2x16 => Mf::Unpack2x16snorm,- _ => return Err(Error::UnsupportedExtInst(inst_id)),- };-- let arg_count = fun.argument_count();- inst.expect(base_wc + arg_count as u16)?;- let arg = {- let arg_id = self.next()?;- let lexp = self.lookup_expression.lookup(arg_id)?;- get_expr_handle!(arg_id, lexp)- };- let arg1 = if arg_count > 1 {- let arg_id = self.next()?;- let lexp = self.lookup_expression.lookup(arg_id)?;- Some(get_expr_handle!(arg_id, lexp))- } else {- None- };- let arg2 = if arg_count > 2 {- let arg_id = self.next()?;- let lexp = self.lookup_expression.lookup(arg_id)?;- Some(get_expr_handle!(arg_id, lexp))- } else {- None- };- let arg3 = if arg_count > 3 {- let arg_id = self.next()?;- let lexp = self.lookup_expression.lookup(arg_id)?;- Some(get_expr_handle!(arg_id, lexp))- } else {- None- };-- let expr = crate::Expression::Math {- fun,- arg,- arg1,- arg2,- arg3,- };- self.lookup_expression.insert(- result_id,- LookupExpression {- handle: ctx.expressions.append(expr, span),- type_id: result_type_id,- block_id,- },- );- }+ None+ };+ let arg2 = if arg_count > 2 {+ let arg_id = self.next()?;+ let lexp = self.lookup_expression.lookup(arg_id)?;+ Some(get_expr_handle!(arg_id, lexp))+ } else {+ None+ };+ let arg3 = if arg_count > 3 {+ let arg_id = self.next()?;+ let lexp = self.lookup_expression.lookup(arg_id)?;+ Some(get_expr_handle!(arg_id, lexp))+ } else {+ None+ };++ let expr = crate::Expression::Math {+ fun,+ arg,+ arg1,+ arg2,+ arg3,+ };+ self.lookup_expression.insert(+ result_id,+ LookupExpression {+ handle: ctx.expressions.append(expr, span),+ type_id: result_type_id,+ block_id,+ },+ ); } // Relational and Logical Instructions Op::LogicalNot => {@@ -2640,12 +2734,7 @@ inst.expect(5)?; parse_expr_op!(crate::BinaryOperator::LogicalAnd, BINARY)?; }- Op::IEqual- | Op::INotEqual- | Op::SGreaterThan- | Op::SGreaterThanEqual- | Op::SLessThan- | Op::SLessThanEqual => {+ Op::SGreaterThan | Op::SGreaterThanEqual | Op::SLessThan | Op::SLessThanEqual => { inst.expect(5)?; self.parse_expr_int_comparison( ctx,@@ -2769,8 +2858,15 @@ get_expr_handle!(condition_id, lexp) };+ block.extend(emitter.finish(ctx.expressions));+ ctx.blocks.insert(block_id, block);+ let body = &mut ctx.bodies[body_idx];+ body.data.push(BodyFragment::BlockId(block_id));+ let true_id = self.next()?; let false_id = self.next()?;++ let same_target = true_id == false_id; // Start a body block for the `accept` branch. let accept = ctx.bodies.len();@@ -2780,11 +2876,27 @@ // merge or continue block, then put a `Break` or `Continue` // statement in this new body block. if let Some(info) = ctx.mergers.get(&true_id) {- merger(&mut accept_block, info)+ merger(+ match same_target {+ true => &mut ctx.bodies[body_idx],+ false => &mut accept_block,+ },+ info,+ ) } else { // Note the body index for the block we're branching to.- let prev = ctx.body_for_label.insert(true_id, accept);+ let prev = ctx.body_for_label.insert(+ true_id,+ match same_target {+ true => body_idx,+ false => accept,+ },+ ); debug_assert!(prev.is_none());+ }++ if same_target {+ return Ok(()); } ctx.bodies.push(accept_block);@@ -2802,17 +2914,17 @@ ctx.bodies.push(reject_block);- block.extend(emitter.finish(ctx.expressions));- ctx.blocks.insert(block_id, block); let body = &mut ctx.bodies[body_idx];- // Make sure the vector has space for at least two more allocations- body.data.reserve(2);- body.data.push(BodyFragment::BlockId(block_id)); body.data.push(BodyFragment::If { condition, accept, reject, });++ // Consume branch weights+ for _ in 4..inst.wc {+ let _ = self.next()?;+ } return Ok(()); }@@ -3105,6 +3217,24 @@ } else { log::warn!("Unsupported barrier execution scope: {}", exec_scope); }+ }+ Op::CopyObject => {+ inst.expect(4)?;+ let result_type_id = self.next()?;+ let result_id = self.next()?;+ let operand_id = self.next()?;++ let lookup = self.lookup_expression.lookup(operand_id)?;+ let handle = get_expr_handle!(operand_id, lookup);++ self.lookup_expression.insert(+ result_id,+ LookupExpression {+ handle,+ type_id: result_type_id,+ block_id,+ },+ ); } _ => return Err(Error::UnsupportedInstruction(self.state, inst.op)), }
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: yes Type Casting Vulnerability [third_party/rust/naga/src/front/spv/mod.rs] [Lines 1595-1710] [Old Code] No explicit handling of unsigned integer indices when accessing arrays/vectors [Fixed Code] Added explicit casting of unsigned indices to signed integers when accessing arrays/vectors to prevent potential type mismatch issues 2. Vulnerability Existed: yes Array Access Validation Vulnerability [third_party/rust/naga/src/front/spv/mod.rs] [Lines 1076-1125] [Old Code] Incomplete handling of array access validation (commented "TODO" for array case) [Fixed Code] Added proper validation for array access, including handling of both constant-sized and dynamic arrays, with proper error returns for invalid cases 3. Vulnerability Existed: yes Sign Handling Vulnerability [third_party/rust/naga/src/front/spv/mod.rs] [Lines 849-954, 1832-1856] [Old Code] Basic binary operation handling without proper sign adjustment control [Fixed Code] Added SignAnchor enum and proper sign adjustment logic for binary operations, with separate handling for arithmetic vs boolean operations 4. Vulnerability Existed: yes GLSL Extension Function Vulnerability [third_party/rust/naga/src/front/spv/mod.rs] [Lines 2475-2611] [Old Code] Special-case handling for only Radians/Degrees functions [Fixed Code] Comprehensive handling of all GLSL extension functions with proper argument counting and validation 5. Vulnerability Existed: not sure Control Flow Vulnerability [third_party/rust/naga/src/front/spv/mod.rs] [Lines 2769-2858] [Old Code] Basic if-else handling without same-target optimization [Fixed Code] Added optimization for same-target branches and proper branch weight consumption The changes appear to focus on improving type safety, validation, and security in several areas: - Proper type casting for array/vector indices - Complete validation of array accesses - Better handling of signed/unsigned operations - More secure handling of GLSL extension functions - Improved control flow handling These changes help prevent potential security issues that could arise from type mismatches, invalid memory accesses, and improper function handling.
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/public/ScalarType.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/public/ScalarType.h@@ -53,6 +53,7 @@ /** * Types that don't have their own TypedArray equivalent, for now.+ * E.g. DataView */ MaxTypedArrayViewType,
Let me analyze the code diff according to the provided format. Vulnerability Existed: no [No specific vulnerability] [js/public/ScalarType.h] [Lines 53-56] [Old Code] /** * Types that don't have their own TypedArray equivalent, for now. */ [Fixed Code] /** * Types that don't have their own TypedArray equivalent, for now. * E.g. DataView */ Analysis: 1. This is a documentation-only change, adding an example (DataView) to clarify the comment. 2. There are no code changes that would affect security. 3. No actual vulnerability is being fixed here - just improved documentation. 4. The change doesn't modify any behavior or fix any security issues, it only adds explanatory text. The modification appears to be purely for code clarity/documentation purposes rather than addressing any 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/testing/web-platform/tests/html/canvas/offscreen/the-canvas-state/2d.state.saverestore.lineWidth.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/the-canvas-state/2d.state.saverestore.lineWidth.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'); // Test that restore() undoes any modifications var old = ctx.lineWidth;
Analysis of the provided code diff:
1. Vulnerability Existed: no
Variable Renaming [File] [Lines 17-18]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
Additional Details:
- This appears to be a simple variable renaming from 'offscreenCanvas' to 'canvas' for consistency or clarity.
- No security vulnerability is addressed in this change.
- The functionality remains exactly the same, only the variable name changes.
- This is likely part of code cleanup or standardization 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/third_party/rust/darling_core/src/from_field.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/darling_core/src/from_field.rs@@ -1,6 +1,6 @@-use syn::{self, Field};+use syn::Field;-use Result;+use crate::Result; /// Creates an instance by parsing an individual field and its attributes. pub trait FromField: Sized {
Analyzing the provided code diff:
1. Vulnerability Existed: no
No specific vulnerability [File] [Lines 1-4]
[Old Code]
use syn::{self, Field};
use Result;
[Fixed Code]
use syn::Field;
use crate::Result;
Additional Details:
- The changes are primarily import statement cleanups and modernization (using explicit crate:: prefix)
- No security vulnerabilities are being fixed here
- The changes appear to be Rust idiom improvements rather than security fixes
No security vulnerabilities were identified in this diff. The changes are related to code style 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/browser/base/content/nsContextMenu.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/base/content/nsContextMenu.js@@ -1157,23 +1157,20 @@ } initPasswordControlItems() {- let shouldShow = this.onPassword && SHOW_PASSWORD_ENABLED;+ let shouldShow = this.onPassword && REVEAL_PASSWORD_ENABLED; if (shouldShow) {- let checked = this.passwordRevealed;- let showPasswordMenuItem = document.getElementById(- "context-toggle-show-password"- );- if (checked) {- showPasswordMenuItem.setAttribute("checked", "true");+ let revealPassword = document.getElementById("context-reveal-password");+ if (this.passwordRevealed) {+ revealPassword.setAttribute("checked", "true"); } else {- showPasswordMenuItem.removeAttribute("checked");+ revealPassword.removeAttribute("checked"); } }- this.showItem("context-toggle-show-password", shouldShow);- }-- toggleShowPassword() {- this.actor.toggleShowPassword(this.targetIdentifier);+ this.showItem("context-reveal-password", shouldShow);+ }++ toggleRevealPassword() {+ this.actor.toggleRevealPassword(this.targetIdentifier); } openPasswordManager() {@@ -2266,7 +2263,7 @@ XPCOMUtils.defineLazyPreferenceGetter( this,- "SHOW_PASSWORD_ENABLED",- "layout.forms.input-type-show-password-button.enabled",+ "REVEAL_PASSWORD_ENABLED",+ "layout.forms.reveal-password-context-menu.enabled", false );
Here's the analysis of the provided code diff following the specified format:
1. Vulnerability Existed: not sure
[Potential Inconsistent Password Visibility Control] [browser/base/content/nsContextMenu.js] [Lines 1157-1170, 2266-2270]
[Old Code]
```javascript
let shouldShow = this.onPassword && SHOW_PASSWORD_ENABLED;
...
this.showItem("context-toggle-show-password", shouldShow);
...
XPCOMUtils.defineLazyPreferenceGetter(
this,
"SHOW_PASSWORD_ENABLED",
"layout.forms.input-type-show-password-button.enabled",
false
);
```
[Fixed Code]
```javascript
let shouldShow = this.onPassword && REVEAL_PASSWORD_ENABLED;
...
this.showItem("context-reveal-password", shouldShow);
...
XPCOMUtils.defineLazyPreferenceGetter(
this,
"REVEAL_PASSWORD_ENABLED",
"layout.forms.reveal-password-context-menu.enabled",
false
);
```
Note: The change appears to be a renaming/refactoring of password visibility control functionality, but it's unclear if this was fixing a security vulnerability or just improving consistency. The preference name and control ID were changed, which could potentially affect how password visibility is managed.
2. Vulnerability Existed: not sure
[Potential Method Exposure] [browser/base/content/nsContextMenu.js] [Lines 1172-1174]
[Old Code]
```javascript
toggleShowPassword() {
this.actor.toggleShowPassword(this.targetIdentifier);
}
```
[Fixed Code]
```javascript
toggleRevealPassword() {
this.actor.toggleRevealPassword(this.targetIdentifier);
}
```
Note: The method name was changed from `toggleShowPassword` to `toggleRevealPassword`, matching the other changes. While this could be part of a security-related refactoring, there's no clear evidence of a vulnerability being fixed. The change appears to be part of a larger naming consistency update.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.css-color-4-rgb-5.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.css-color-4-rgb-5.worker.js@@ -13,14 +13,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillStyle = 'rgb(0 255 0 / 0.2)'; ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,51, "50,25", "0,255,0,51");+_assertPixel(canvas, 50,25, 0,255,0,51, "50,25", "0,255,0,51"); t.done(); });
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely cosmetic/refactoring changes (variable renaming) rather than security fixes.
Here's the analysis following 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-rgb-5.worker.js] [Lines 13-21]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 50,25, 0,255,0,51, "50,25", "0,255,0,51");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 50,25, 0,255,0,51, "50,25", "0,255,0,51");
The changes simply rename the variable `offscreenCanvas` to `canvas` and update its references. There are no security implications to 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/path-objects/2d.path.roundrect.4.radii.3.dompoint.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.dompoint.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(); });
Based on the provided code diff, I don't see any security-related fixes. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and updating all references to this variable. Here's the analysis:
Vulnerability Existed: no
Variable Renaming Refactor [File] [Lines 13-14, 23-31]
[Old Code]
```javascript
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 79,48, 255,0,0,255, "79,48", "255,0,0,255");
```
[Fixed Code]
```javascript
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 79,48, 255,0,0,255, "79,48", "255,0,0,255");
```
This appears to be a simple code refactoring/cleanup with no security implications. The functionality remains exactly the same, only the variable name has changed for better 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/nsBrowserApp.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/app/nsBrowserApp.cpp@@ -219,7 +219,7 @@ #endif // Note: keep in sync with LauncherProcessWin.- const char* acceptableParams[] = {"url", nullptr};+ const char* acceptableParams[] = {"url", "private-window", nullptr}; EnsureCommandlineSafe(argc, argv, acceptableParams); return gBootstrap->XRE_main(argc, argv, config);
Here's the analysis of the provided code diff:
Vulnerability Existed: yes
Command Injection (Parameter Whitelisting) [File] browser/app/nsBrowserApp.cpp [Lines 219]
[Old Code]
const char* acceptableParams[] = {"url", nullptr};
[Fixed Code]
const char* acceptableParams[] = {"url", "private-window", nullptr};
Additional Details:
The fix adds "private-window" to the whitelist of acceptable command line parameters. The vulnerability here is that without proper parameter whitelisting, attackers could potentially inject malicious command line parameters that the application might process in an unsafe way. By expanding the whitelist to include legitimate parameters while still blocking others, this improves security by ensuring only approved parameters are processed.
The vulnerability type could be classified as a form of command injection or parameter injection, though it's more precisely a parameter whitelisting improvement to prevent potential abuse of command line 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/transformations/2d.transformation.scale.zero.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/transformations/2d.transformation.scale.zero.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 = '#0f0'; ctx.fillRect(0, 0, 100, 50);@@ -30,7 +30,7 @@ ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50); ctx.restore();-_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 changes (variable renaming) rather than security-related fixes. Here's the analysis:
Vulnerability Existed: no
No security vulnerability found [File] testing/web-platform/tests/html/canvas/offscreen/transformations/2d.transformation.scale.zero.worker.js
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes simply rename the variable `offscreenCanvas` to `canvas` throughout the file, which doesn't appear to address any security issues. The functionality remains the same.
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/components/downloads/content/downloads.css+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/components/downloads/content/downloads.css@@ -29,7 +29,7 @@ /*** Downloads View ***/-#downloadsRichListBox > richlistitem button {+#downloadsListBox.allDownloadsListBox > richlistitem button { /* These buttons should never get focus, as that would "disable" the downloads view controller (it's only used when the richlistbox is focused). */
Analysis: 1. Vulnerability Existed: not sure [Potential Clickjacking/UI Redress Attack] [browser/components/downloads/content/downloads.css] [Lines 29] [Old Code] `#downloadsRichListBox > richlistitem button` [Fixed Code] `#downloadsListBox.allDownloadsListBox > richlistitem button` Additional Details: The change appears to modify the CSS selector for download list buttons, making it more specific. While this doesn't directly indicate a security vulnerability, it could potentially relate to UI security by ensuring proper element targeting and preventing unintended button interactions. However, without more context about the application's behavior, we can't be certain if this was addressing a specific security issue. The change might be defensive programming rather than fixing an actual 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/devtools/client/shared/test/shared-head.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/shared/test/shared-head.js@@ -62,6 +62,12 @@ this, "ResponsiveUIManager", "devtools/client/responsive/manager"+);++loader.lazyRequireGetter(+ this,+ "FluentReact",+ "devtools/client/shared/vendor/fluent-react" ); const TEST_DIR = gTestPath.substr(0, gTestPath.lastIndexOf("/"));@@ -1899,3 +1905,69 @@ }, "Waiting for a valid presShell"); }); };++/**+ * In tests using Fluent localization, it is preferable to match DOM elements using+ * a message ID rather than the raw string as:+ *+ * 1. It allows testing infrastructure to be multilingual if needed.+ * 2. It isolates the tests from localization changes.+ *+ * @param {Array<string>} resourceIds A list of .ftl files to load.+ * @returns {(id: string, args?: Record<string, FluentVariable>) => string}+ */+async function getFluentStringHelper(resourceIds) {+ const locales = Services.locale.appLocalesAsBCP47;+ const generator = L10nRegistry.getInstance().generateBundles(+ locales,+ resourceIds+ );++ const bundles = [];+ for await (const bundle of generator) {+ bundles.push(bundle);+ }++ const reactLocalization = new FluentReact.ReactLocalization(bundles);++ /**+ * Get the string from a message id. It throws when the message is not found.+ *+ * @param {string} id+ * @param {string} attributeName: attribute name if you need to access a specific attribute+ * defined in the fluent string, e.g. setting "title" for this param+ * will retrieve the `title` string in+ * compatibility-issue-browsers-list =+ * .title = This is the title+ * @param {Record<string, FluentVariable>} [args] optional+ * @returns {string}+ */+ return (id, attributeName, args) => {+ let string;++ if (!attributeName) {+ string = reactLocalization.getString(id, args);+ } else {+ for (const bundle of reactLocalization.bundles) {+ const msg = bundle.getMessage(id);+ if (msg?.attributes[attributeName]) {+ string = bundle.formatPattern(+ msg.attributes[attributeName],+ args,+ []+ );+ break;+ }+ }+ }++ if (!string) {+ throw new Error(+ `Could not find a string for "${id}"${+ attributeName ? ` and attribute "${attributeName}")` : ""+ }. Was the correct resource bundle loaded?`+ );+ }+ return string;+ };+}
Based on the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be adding new functionality for Fluent localization support in tests rather than addressing security issues. Here's the analysis: Vulnerability Existed: no No security vulnerability found [File] devtools/client/shared/test/shared-head.js [Lines] 62-68, 1905-1973 [Old Code] (No previous Fluent-related code existed) [Fixed Code] (Added new Fluent localization helper functionality) The changes include: 1. Adding lazyRequireGetter for FluentReact 2. Adding a new getFluentStringHelper function for localization support in tests These changes are functional enhancements rather than security fixes. The new code appears to be properly handling localization strings and includes appropriate error checking when strings aren't found. No Common Vulnerabilities and Exposures (CVE) or other known vulnerability patterns are present 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.