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/css/css-conditional/at-supports-017.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-conditional/at-supports-017.html@@ -6,7 +6,6 @@ <link rel="author" href="http://opera.com" title="Opera Software ASA"> <link rel="help" href="http://www.w3.org/TR/css3-conditional/#at-supports"> <link rel="match" href="at-supports-001-ref.html">- <meta name="flags" content=""> <style> div { background:red;
Based on the provided code diff, here's the analysis: Vulnerability Existed: no No security vulnerability found [File] testing/web-platform/tests/css/css-conditional/at-supports-017.html [Lines] 6 [Old Code] `<meta name="flags" content="">` [Fixed Code] (Line removed) Additional Details: The change simply removes an empty meta tag that wasn't serving any purpose. This appears to be a code cleanup rather than a security fix. The "flags" meta tag was typically used for test configuration in web platform tests, and its removal doesn't indicate any security vulnerability being addressed.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/neqo-qpack/src/qpack_send_buf.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/neqo-qpack/src/qpack_send_buf.rs@@ -88,10 +88,10 @@ } pub fn read(&mut self, r: usize) {- if r > self.buf.len() {- panic!("want to set more byte read than remaing in the buffer.");- }-+ assert!(+ r <= self.buf.len(),+ "want to set more bytes read than remain in the buffer."+ ); self.buf = self.buf.split_off(r); } }
Here's the analysis of the provided code diff:
Vulnerability Existed: yes
Buffer Overflow Prevention [File] third_party/rust/neqo-qpack/src/qpack_send_buf.rs [Lines] 88-92
[Old Code]
```rust
if r > self.buf.len() {
panic!("want to set more byte read than remaing in the buffer.");
}
```
[Fixed Code]
```rust
assert!(
r <= self.buf.len(),
"want to set more bytes read than remain in the buffer."
);
```
Additional Details:
1. The change replaces a simple `if-panic` check with Rust's `assert!` macro, which is more idiomatic and provides better error messages.
2. While not a classic buffer overflow vulnerability (since it's caught and panics), the old code could potentially allow unsafe operations if the panic handler was modified or bypassed.
3. The fixed version is more robust as `assert!` is designed specifically for these kinds of bounds checking scenarios.
4. The error message was also improved ("remaing" -> "remain", "byte" -> "bytes").
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/tools/lint/perfdocs/utils.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/tools/lint/perfdocs/utils.py@@ -81,17 +81,33 @@ if mismatch or errors: logger.log(f"Found mismatches: {mismatch}")- for entry in mismatch:- logger.log(f"Mismatch found on {entry}")- with open(os.path.join(dir_1, entry)) as f:- newlines = f.readlines()- with open(os.path.join(dir_2, entry)) as f:- baselines = f.readlines()- for line in difflib.unified_diff(- baselines, newlines, fromfile="base", tofile="new"- ):- logger.log(line)- logger.log(f"Completed diff on {entry}")+ with open("/builds/worker/diff.txt", "w") as difffile:+ for entry in mismatch:+ logger.log(f"Mismatch found on {entry}")+ with open(os.path.join(dir_1, entry)) as f:+ newlines = f.readlines()+ with open(os.path.join(dir_2, entry)) as f:+ baselines = f.readlines()+ for line in difflib.unified_diff(+ baselines, newlines, fromfile="base", tofile="new"+ ):+ logger.log(line)++ # here we want to add to diff.txt in a patch format+ basedir = "/builds/worker/checkouts/gecko/"+ relative_path = os.path.join(dir_2, entry).split(basedir)[-1]+ patch = difflib.unified_diff(+ baselines, newlines, fromfile=relative_path, tofile=relative_path+ )+ write_header = True+ for line in patch:+ if write_header:+ difffile.write(+ f"diff --git a/{relative_path} b/{relative_path}\n"+ )+ write_header = False+ difffile.write(line)+ logger.log(f"Completed diff on {entry}") return False for common_dir in dirs_cmp.common_dirs:
Let me analyze the code diff for potential security vulnerabilities:
1. Vulnerability Existed: yes
Path Traversal Vulnerability [tools/lint/perfdocs/utils.py] [Lines 81-98]
[Old Code]
for entry in mismatch:
logger.log(f"Mismatch found on {entry}")
with open(os.path.join(dir_1, entry)) as f:
newlines = f.readlines()
with open(os.path.join(dir_2, entry)) as f:
baselines = f.readlines()
[Fixed Code]
with open("/builds/worker/diff.txt", "w") as difffile:
for entry in mismatch:
logger.log(f"Mismatch found on {entry}")
with open(os.path.join(dir_1, entry)) as f:
newlines = f.readlines()
with open(os.path.join(dir_2, entry)) as f:
baselines = f.readlines()
Additional Details:
The old code was vulnerable to path traversal attacks as it directly used user-controlled 'entry' values in os.path.join() without any validation. An attacker could potentially access files outside the intended directories. The new code adds additional path handling by using a base directory and extracting relative paths, though it could still benefit from explicit path validation/sanitization.
2. Vulnerability Existed: not sure
Potential Information Disclosure [tools/lint/perfdocs/utils.py] [Lines 81-98]
[Old Code]
(No file output, only logging)
[Fixed Code]
with open("/builds/worker/diff.txt", "w") as difffile:
... (writes diff information to file)
Additional Details:
The new version writes diff information to a file in a worker directory. While this might not be a direct vulnerability, it could potentially expose sensitive information if the file permissions are not properly set or if the file location is accessible to unauthorized users. The security impact would depend on the server configuration.
3. Vulnerability Existed: not sure
Potential Race Condition [tools/lint/perfdocs/utils.py] [Lines 81-98]
[Old Code]
(No file creation)
[Fixed Code]
with open("/builds/worker/diff.txt", "w") as difffile:
... (writes to file)
Additional Details:
The new code creates and writes to a file in a potentially shared location (/builds/worker/). There could be race condition concerns if multiple instances of this script run simultaneously, though the impact would depend on the specific use case and environment.
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/manager/ssl/nsClientAuthRemember.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/security/manager/ssl/nsClientAuthRemember.cpp@@ -237,15 +237,9 @@ return NS_ERROR_UNEXPECTED; }- nsCOMPtr<nsIX509Cert> cert(nsNSSCertificate::ConstructFromDER(- // ConstructFromDER is not const-correct so we have to cast away the- // const.- const_cast<char*>(- reinterpret_cast<const char*>(::CFDataGetBytePtr(der.get()))),- ::CFDataGetLength(der.get())));- if (!cert) {- return NS_ERROR_FAILURE;- }+ nsTArray<uint8_t> derArray(::CFDataGetBytePtr(der.get()),+ ::CFDataGetLength(der.get()));+ nsCOMPtr<nsIX509Cert> cert(new nsNSSCertificate(std::move(derArray))); return cert->GetDbKey(aCertDBKey); } #endif
Here's the analysis of the provided code diff:
Vulnerability Existed: yes
Memory Safety Issue (Potential Buffer Handling Vulnerability) [security/manager/ssl/nsClientAuthRemember.cpp] [Lines 237-246]
[Old Code]
nsCOMPtr<nsIX509Cert> cert(nsNSSCertificate::ConstructFromDER(
// ConstructFromDER is not const-correct so we have to cast away the
// const.
const_cast<char*>(
reinterpret_cast<const char*>(::CFDataGetBytePtr(der.get()))),
::CFDataGetLength(der.get())));
if (!cert) {
return NS_ERROR_FAILURE;
}
[Fixed Code]
nsTArray<uint8_t> derArray(::CFDataGetBytePtr(der.get()),
::CFDataGetLength(der.get()));
nsCOMPtr<nsIX509Cert> cert(new nsNSSCertificate(std::move(derArray)));
The vulnerability appears to be related to memory safety and proper handling of certificate data. The old code:
1. Used const_cast to remove constness (which is generally unsafe)
2. Directly passed raw pointers to ConstructFromDER
3. Had potential lifetime management issues with the DER data
The new code:
1. Creates a proper nsTArray copy of the data first
2. Uses move semantics for safer transfer
3. Eliminates the need for const_cast
4. Uses a more modern and safer construction pattern
This appears to be fixing a potential memory safety issue that could lead to use-after-free or other memory corruption vulnerabilities.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/build/build_virtualenv_packages.txt+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/build/build_virtualenv_packages.txt@@ -1,2 +1 @@-packages.txt:build/common_virtualenv_packages.txt vendored:third_party/python/glean_parser
Analyzing the provided code diff for security fixes:
1. Vulnerability Existed: not sure
[No specific vulnerability name] [build/build_virtualenv_packages.txt] [Lines 1-2]
[Old Code]
packages.txt:build/common_virtualenv_packages.txt
vendored:third_party/python/glean_parser
[Fixed Code]
vendored:third_party/python/glean_parser
Additional Details:
- The diff shows a removal of a reference to 'build/common_virtualenv_packages.txt' while keeping the vendored Python package reference
- Without more context about the contents of the removed file or the reason for its removal, it's difficult to determine if this was a security fix
- The change could be related to dependency management or build system simplification rather than a security fix
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/css-conditional/at-supports-015.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-conditional/at-supports-015.html@@ -6,7 +6,6 @@ <link rel="author" href="http://opera.com" title="Opera Software ASA"> <link rel="help" href="http://www.w3.org/TR/css3-conditional/#at-supports"> <link rel="match" href="at-supports-001-ref.html">- <meta name="flags" content=""> <style> div { background-color:red;
Based on the provided code diff, here's the analysis: Vulnerability Existed: no [No specific vulnerability found] [testing/web-platform/tests/css/css-conditional/at-supports-015.html] [Lines 6] [Old Code: <meta name="flags" content="">] [Fixed Code: [line removed]] Additional Details: - The change simply removes an empty meta tag with a "flags" attribute - This appears to be a cleanup change rather than a security fix - No known vulnerabilities are associated with empty meta tags or flags attributes - The modification is likely related to test configuration rather than security No other vulnerabilities were identified in this small diff. The change seems to be a minor cleanup or test configuration adjustment rather than a security-related fix.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.pattern.image.undefined.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.pattern.image.undefined.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'); assert_throws_js(TypeError, function() { ctx.createPattern(undefined, 'repeat'); }); t.done();
Analyzing the provided code diff, here's the security assessment:
Vulnerability Existed: no
[No specific vulnerability] [testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.pattern.image.undefined.html] [Lines 17-18]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
Additional Details:
- The change appears to be purely a variable name change from `offscreenCanvas` to `canvas`
- No security-related changes were made in this diff
- The functionality remains exactly the same, only the variable naming was improved
- The test still checks for the same TypeError when calling createPattern with undefined
This appears to be a code style/readability improvement rather than a security fix.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/selectors/old-tests/css3-modsel-166a.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-166a.xml@@ -8,7 +8,6 @@ ]]></style> <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> <p>The first letter of this paragraph should have a green background.</p>
Based on the provided diff, here's the analysis: 1. Vulnerability Existed: no No specific vulnerability [File] testing/web-platform/tests/css/selectors/old-tests/css3-modsel-166a.xml [Lines] 8 [Old Code] `<meta name="flags" content="" />` [Fixed Code] (removed line) Additional Details: - The change simply removes an empty meta tag with a "flags" attribute, which doesn't appear to be security-related - This appears to be a test file cleanup rather than a security fix - No known vulnerability patterns or security issues are addressed by this change - The modification is likely related to test configuration rather than security hardening No security vulnerabilities were found in this diff. The change appears to be a minor cleanup of test metadata.
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/config.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/taskcluster/gecko_taskgraph/config.py@@ -5,14 +5,11 @@ import os import logging-import sys-import attr-from mozpack import path+from taskgraph.config import GraphConfig from taskgraph.util.yaml import load_yaml from voluptuous import Required, Optional, Any-from .util.python_path import find_object from .util.schema import validate_schema, Schema, optionally_keyed_by logger = logging.getLogger(__name__)@@ -125,6 +122,7 @@ Required("mac-entitlements"): optionally_keyed_by( "platform", "release-level", str ),+ Required("mac-requirements"): optionally_keyed_by("platform", str), }, Required("taskgraph"): { Optional(@@ -135,48 +133,6 @@ }, } )--[email protected](frozen=True, cmp=False)-class GraphConfig:- _config = attr.ib()- root_dir = attr.ib()-- _PATH_MODIFIED = False-- def __getitem__(self, name):- return self._config[name]-- def register(self):- """- Add the project's taskgraph directory to the python path, and register- any extensions present.- """- modify_path = os.path.dirname(self.root_dir)- if GraphConfig._PATH_MODIFIED:- if GraphConfig._PATH_MODIFIED == modify_path:- # Already modified path with the same root_dir.- # We currently need to do this to enable actions to call- # taskgraph_decision, e.g. relpro.- return- raise Exception("Can't register multiple directories on python path.")- GraphConfig._PATH_MODIFIED = modify_path- sys.path.insert(0, modify_path)- register_path = self["taskgraph"].get("register")- if register_path:- find_object(register_path)(self)-- @property- def taskcluster_yml(self):- if path.split(self.root_dir)[-2:] != ["taskcluster", "ci"]:- raise Exception(- "Not guessing path to `.taskcluster.yml`. "- "Graph config in non-standard location."- )- return os.path.join(- os.path.dirname(os.path.dirname(self.root_dir)),- ".taskcluster.yml",- ) def validate_graph_config(config):
Based on the provided diff, I'll analyze it for security vulnerabilities:
1. Vulnerability Existed: not sure
Python Path Manipulation [taskcluster/gecko_taskgraph/config.py] [Lines 135-48 in old code]
[Old Code]
```python
def register(self):
"""
Add the project's taskgraph directory to the python path, and register
any extensions present.
"""
modify_path = os.path.dirname(self.root_dir)
if GraphConfig._PATH_MODIFIED:
if GraphConfig._PATH_MODIFIED == modify_path:
# Already modified path with the same root_dir.
# We currently need to do this to enable actions to call
# taskgraph_decision, e.g. relpro.
return
raise Exception("Can't register multiple directories on python path.")
GraphConfig._PATH_MODIFIED = modify_path
sys.path.insert(0, modify_path)
register_path = self["taskgraph"].get("register")
if register_path:
find_object(register_path)(self)
```
[Fixed Code]
```python
# Entire GraphConfig class and register method removed
```
Additional Details:
- The main change is the removal of the `GraphConfig` class and its `register` method which manipulated Python's `sys.path`. While not definitively a vulnerability, modifying Python's import path can be risky if not properly controlled, as it could potentially allow importing malicious modules if an attacker can control the path being added.
- The removal of this functionality might indicate it was deemed unsafe or unnecessary.
- No specific vulnerability name applies here, but the pattern is similar to potential Python path manipulation issues.
- The rest of the changes appear to be code cleanup (removing unused imports) and adding a new configuration option ("mac-requirements") which doesn't show security implications.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/js/src/jit/MacroAssembler.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/jit/MacroAssembler.h@@ -2259,7 +2259,7 @@ inline void shuffleInt8x16(const uint8_t lanes[16], FloatRegister lhs, FloatRegister rhs, FloatRegister dest)- DEFINED_ON(arm64);+ DEFINED_ON(x86_shared, arm64); // Lane values must be 0 (select from lhs) or FF (select from rhs). // The behavior is undefined for lane values that are neither 0 nor FF.@@ -2291,53 +2291,37 @@ FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void interleaveHighInt8x16(FloatRegister rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);- inline void interleaveHighInt8x16(FloatRegister lhs, FloatRegister rhs,- FloatRegister dest) DEFINED_ON(arm64);-- inline void interleaveHighInt16x8(FloatRegister rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ FloatRegister dest)+ DEFINED_ON(x86_shared, arm64); inline void interleaveHighInt16x8(FloatRegister lhs, FloatRegister rhs,- FloatRegister dest) DEFINED_ON(arm64);-- inline void interleaveHighInt32x4(FloatRegister rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ FloatRegister dest)+ DEFINED_ON(x86_shared, arm64); inline void interleaveHighInt32x4(FloatRegister lhs, FloatRegister rhs,- FloatRegister dest) DEFINED_ON(arm64);-- inline void interleaveHighInt64x2(FloatRegister rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ FloatRegister dest)+ DEFINED_ON(x86_shared, arm64); inline void interleaveHighInt64x2(FloatRegister lhs, FloatRegister rhs,- FloatRegister dest) DEFINED_ON(arm64);-- inline void interleaveLowInt8x16(FloatRegister rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ FloatRegister dest)+ DEFINED_ON(x86_shared, arm64); inline void interleaveLowInt8x16(FloatRegister lhs, FloatRegister rhs,- FloatRegister dest) DEFINED_ON(arm64);-- inline void interleaveLowInt16x8(FloatRegister rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ FloatRegister dest)+ DEFINED_ON(x86_shared, arm64); inline void interleaveLowInt16x8(FloatRegister lhs, FloatRegister rhs,- FloatRegister dest) DEFINED_ON(arm64);-- inline void interleaveLowInt32x4(FloatRegister rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ FloatRegister dest)+ DEFINED_ON(x86_shared, arm64); inline void interleaveLowInt32x4(FloatRegister lhs, FloatRegister rhs,- FloatRegister dest) DEFINED_ON(arm64);-- inline void interleaveLowInt64x2(FloatRegister rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ FloatRegister dest)+ DEFINED_ON(x86_shared, arm64); inline void interleaveLowInt64x2(FloatRegister lhs, FloatRegister rhs,- FloatRegister dest) DEFINED_ON(arm64);+ FloatRegister dest)+ DEFINED_ON(x86_shared, arm64); // Permute - permute with immediate indices.@@ -2360,18 +2344,12 @@ // lane values 0..3 inline void permuteInt32x4(const uint32_t lanes[4], FloatRegister src, FloatRegister dest) DEFINED_ON(x86_shared, arm64);-- // Funnel shift by immediate count:- // low_16_bytes_of((lhsDest ++ rhs) >> shift*8), shift must be < 32.- inline void concatAndRightShiftSimd128(FloatRegister rhs,- FloatRegister lhsDest, uint32_t shift)- DEFINED_ON(x86_shared); // Funnel shift by immediate count: // low_16_bytes_of((lhs ++ rhs) >> shift*8), shift must be < 16 inline void concatAndRightShiftSimd128(FloatRegister lhs, FloatRegister rhs, FloatRegister dest, uint32_t shift)- DEFINED_ON(arm64);+ DEFINED_ON(x86_shared, arm64); // Rotate right by immediate count: // low_16_bytes_of((src ++ src) >> shift*8), shift must be < 16@@ -2421,8 +2399,8 @@ inline void addInt8x16(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void addInt8x16(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void addInt8x16(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void addInt16x8(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2430,8 +2408,8 @@ inline void addInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void addInt16x8(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void addInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void addInt32x4(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2439,8 +2417,8 @@ inline void addInt32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(x86_shared, arm64);- inline void addInt32x4(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void addInt32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void addInt64x2(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2448,8 +2426,8 @@ inline void addInt64x2(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void addInt64x2(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void addInt64x2(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); // Integer Subtract@@ -2459,8 +2437,8 @@ inline void subInt8x16(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void subInt8x16(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void subInt8x16(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void subInt16x8(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2468,14 +2446,14 @@ inline void subInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void subInt16x8(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void subInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void subInt32x4(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);- inline void subInt32x4(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void subInt32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void subInt32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(x86_shared, arm64);@@ -2483,8 +2461,8 @@ inline void subInt64x2(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);- inline void subInt64x2(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void subInt64x2(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void subInt64x2(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);@@ -2497,8 +2475,8 @@ inline void mulInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void mulInt16x8(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void mulInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void mulInt32x4(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2506,8 +2484,8 @@ inline void mulInt32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(x86_shared, arm64);- inline void mulInt32x4(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void mulInt32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); // On x86_shared, it is required lhs == dest inline void mulInt64x2(FloatRegister lhs, FloatRegister rhs,@@ -2623,8 +2601,8 @@ inline void addSatInt8x16(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void addSatInt8x16(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void addSatInt8x16(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void unsignedAddSatInt8x16(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2632,9 +2610,8 @@ inline void unsignedAddSatInt8x16(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void unsignedAddSatInt8x16(const SimdConstant& rhs,- FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void unsignedAddSatInt8x16(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void addSatInt16x8(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2642,8 +2619,8 @@ inline void addSatInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void addSatInt16x8(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void addSatInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void unsignedAddSatInt16x8(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2651,9 +2628,8 @@ inline void unsignedAddSatInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void unsignedAddSatInt16x8(const SimdConstant& rhs,- FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void unsignedAddSatInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); // Saturating integer subtract@@ -2663,8 +2639,8 @@ inline void subSatInt8x16(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void subSatInt8x16(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void subSatInt8x16(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void unsignedSubSatInt8x16(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2672,9 +2648,8 @@ inline void unsignedSubSatInt8x16(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void unsignedSubSatInt8x16(const SimdConstant& rhs,- FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void unsignedSubSatInt8x16(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void subSatInt16x8(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2682,8 +2657,8 @@ inline void subSatInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void subSatInt16x8(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void subSatInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void unsignedSubSatInt16x8(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2691,9 +2666,8 @@ inline void unsignedSubSatInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void unsignedSubSatInt16x8(const SimdConstant& rhs,- FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void unsignedSubSatInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); // Lane-wise integer minimum@@ -2703,8 +2677,8 @@ inline void minInt8x16(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void minInt8x16(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void minInt8x16(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void unsignedMinInt8x16(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2712,8 +2686,8 @@ inline void unsignedMinInt8x16(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void unsignedMinInt8x16(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void unsignedMinInt8x16(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void minInt16x8(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2721,8 +2695,8 @@ inline void minInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void minInt16x8(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void minInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void unsignedMinInt16x8(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2730,8 +2704,8 @@ inline void unsignedMinInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void unsignedMinInt16x8(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void unsignedMinInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void minInt32x4(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2739,8 +2713,8 @@ inline void minInt32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void minInt32x4(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void minInt32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void unsignedMinInt32x4(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2748,8 +2722,8 @@ inline void unsignedMinInt32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void unsignedMinInt32x4(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void unsignedMinInt32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); // Lane-wise integer maximum@@ -2759,8 +2733,8 @@ inline void maxInt8x16(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void maxInt8x16(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void maxInt8x16(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void unsignedMaxInt8x16(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2768,8 +2742,8 @@ inline void unsignedMaxInt8x16(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void unsignedMaxInt8x16(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void unsignedMaxInt8x16(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void maxInt16x8(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2777,8 +2751,8 @@ inline void maxInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void maxInt16x8(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void maxInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void unsignedMaxInt16x8(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2786,8 +2760,8 @@ inline void unsignedMaxInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void unsignedMaxInt16x8(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void unsignedMaxInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void maxInt32x4(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2795,8 +2769,8 @@ inline void maxInt32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void maxInt32x4(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void maxInt32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void unsignedMaxInt32x4(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2804,8 +2778,8 @@ inline void unsignedMaxInt32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void unsignedMaxInt32x4(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void unsignedMaxInt32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); // Lane-wise integer rounding average@@ -2985,8 +2959,8 @@ FloatRegister dest) DEFINED_ON(x86_shared, arm64);- inline void bitwiseAndSimd128(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void bitwiseAndSimd128(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void bitwiseOrSimd128(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -2995,8 +2969,8 @@ FloatRegister dest) DEFINED_ON(x86_shared, arm64);- inline void bitwiseOrSimd128(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void bitwiseOrSimd128(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void bitwiseXorSimd128(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -3005,8 +2979,8 @@ FloatRegister dest) DEFINED_ON(x86_shared, arm64);- inline void bitwiseXorSimd128(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void bitwiseXorSimd128(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void bitwiseNotSimd128(FloatRegister src, FloatRegister dest) DEFINED_ON(x86_shared, arm64);@@ -3094,8 +3068,9 @@ DEFINED_ON(x86_shared, arm64); // On x86_shared, limited to !=, ==, <=, >- inline void compareInt8x16(Assembler::Condition cond, const SimdConstant& rhs,- FloatRegister lhsDest) DEFINED_ON(x86_shared);+ inline void compareInt8x16(Assembler::Condition cond, FloatRegister lhs,+ const SimdConstant& rhs, FloatRegister dest)+ DEFINED_ON(x86_shared); // On arm64, use any integer comparison condition. inline void compareInt8x16(Assembler::Condition cond, FloatRegister lhs,@@ -3111,18 +3086,20 @@ DEFINED_ON(arm64); // On x86_shared, limited to !=, ==, <=, >- inline void compareInt16x8(Assembler::Condition cond, const SimdConstant& rhs,- FloatRegister lhsDest) DEFINED_ON(x86_shared);+ inline void compareInt16x8(Assembler::Condition cond, FloatRegister lhs,+ const SimdConstant& rhs, FloatRegister dest)+ DEFINED_ON(x86_shared); // On x86_shared, limited to !=, ==, <=, > inline void compareInt32x4(Assembler::Condition cond, FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);+ inline void compareInt32x4(Assembler::Condition cond, FloatRegister lhs,+ const SimdConstant& rhs, FloatRegister dest)+ DEFINED_ON(x86_shared);+ // On arm64, use any integer comparison condition.- inline void compareInt32x4(Assembler::Condition cond, const SimdConstant& rhs,- FloatRegister lhsDest) DEFINED_ON(x86_shared);- inline void compareInt32x4(Assembler::Condition cond, FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(x86_shared, arm64);@@ -3148,8 +3125,8 @@ DEFINED_ON(x86_shared, arm64); // On x86_shared, limited to ==, !=, <, <=- inline void compareFloat32x4(Assembler::Condition cond,- const SimdConstant& rhs, FloatRegister lhsDest)+ inline void compareFloat32x4(Assembler::Condition cond, FloatRegister lhs,+ const SimdConstant& rhs, FloatRegister dest) DEFINED_ON(x86_shared); // On x86_shared, limited to ==, !=, <, <=@@ -3163,8 +3140,8 @@ DEFINED_ON(x86_shared, arm64); // On x86_shared, limited to ==, !=, <, <=- inline void compareFloat64x2(Assembler::Condition cond,- const SimdConstant& rhs, FloatRegister lhsDest)+ inline void compareFloat64x2(Assembler::Condition cond, FloatRegister lhs,+ const SimdConstant& rhs, FloatRegister dest) DEFINED_ON(x86_shared); // On arm64, use any float-point comparison condition.@@ -3259,8 +3236,8 @@ inline void addFloat32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(x86_shared, arm64);- inline void addFloat32x4(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void addFloat32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void addFloat64x2(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -3268,8 +3245,8 @@ inline void addFloat64x2(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void addFloat64x2(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void addFloat64x2(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); // Floating subtract@@ -3279,8 +3256,8 @@ inline void subFloat32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(x86_shared, arm64);- inline void subFloat32x4(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void subFloat32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void subFloat64x2(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -3288,8 +3265,8 @@ inline void subFloat64x2(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void subFloat64x2(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void subFloat64x2(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); // Floating division@@ -3299,8 +3276,8 @@ inline void divFloat32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(x86_shared, arm64);- inline void divFloat32x4(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void divFloat32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void divFloat64x2(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -3308,8 +3285,8 @@ inline void divFloat64x2(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void divFloat64x2(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void divFloat64x2(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); // Floating Multiply@@ -3319,8 +3296,8 @@ inline void mulFloat32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(x86_shared, arm64);- inline void mulFloat32x4(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void mulFloat32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void mulFloat64x2(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);@@ -3328,8 +3305,8 @@ inline void mulFloat64x2(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void mulFloat64x2(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void mulFloat64x2(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); // Pairwise add@@ -3425,8 +3402,8 @@ inline void narrowInt16x8(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);- inline void narrowInt16x8(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void narrowInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void narrowInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);@@ -3434,9 +3411,8 @@ inline void unsignedNarrowInt16x8(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);- inline void unsignedNarrowInt16x8(const SimdConstant& rhs,- FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void unsignedNarrowInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void unsignedNarrowInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);@@ -3444,8 +3420,8 @@ inline void narrowInt32x4(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);- inline void narrowInt32x4(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void narrowInt32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void narrowInt32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);@@ -3453,9 +3429,8 @@ inline void unsignedNarrowInt32x4(FloatRegister rhs, FloatRegister lhsDest) DEFINED_ON(x86_shared, arm64);- inline void unsignedNarrowInt32x4(const SimdConstant& rhs,- FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void unsignedNarrowInt32x4(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); inline void unsignedNarrowInt32x4(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);@@ -3542,8 +3517,8 @@ inline void widenDotInt16x8(FloatRegister lhs, FloatRegister rhs, FloatRegister dest) DEFINED_ON(arm64);- inline void widenDotInt16x8(const SimdConstant& rhs, FloatRegister lhsDest)- DEFINED_ON(x86_shared);+ inline void widenDotInt16x8(FloatRegister lhs, const SimdConstant& rhs,+ FloatRegister dest) DEFINED_ON(x86_shared); // Floating point rounding@@ -3656,7 +3631,7 @@ void wasmTrap(wasm::Trap trap, wasm::BytecodeOffset bytecodeOffset); void wasmInterruptCheck(Register tls, wasm::BytecodeOffset bytecodeOffset); #ifdef ENABLE_WASM_EXCEPTIONS- size_t wasmStartTry();+ [[nodiscard]] bool wasmStartTry(size_t* tryNoteIndex); #endif // Returns a pair: the offset of the undefined (trapping) instruction, and
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: yes Buffer Overflow/Incorrect SIMD Operation Handling [js/src/jit/MacroAssembler.h] [Multiple locations] Old Code: Various SIMD operations with `const SimdConstant& rhs, FloatRegister lhsDest` pattern Fixed Code: Changed to `FloatRegister lhs, const SimdConstant& rhs, FloatRegister dest` pattern This change appears to fix potential buffer overflow or incorrect SIMD operation handling by properly separating source and destination registers instead of using the same register for both input and output in many SIMD operations. 2. Vulnerability Existed: yes SIMD Instruction Consistency Issue [js/src/jit/MacroAssembler.h] [Multiple locations] Old Code: Different function signatures for x86_shared and arm64 architectures Fixed Code: Unified function signatures across architectures The changes standardize the function signatures across different architectures (x86_shared and arm64), which could prevent architecture-specific vulnerabilities or inconsistencies in SIMD operations. 3. Vulnerability Existed: not sure Potential WASM Exception Handling Improvement [js/src/jit/MacroAssembler.h] [~3656] Old Code: `size_t wasmStartTry();` Fixed Code: `[[nodiscard]] bool wasmStartTry(size_t* tryNoteIndex);` This change might improve WASM exception handling safety by making the function's return value checking mandatory (via [[nodiscard]]) and changing the return type to bool, but it's unclear if this was fixing a specific security vulnerability. The most significant security-related changes appear to be in the SIMD operation handling, where the modifications: 1. Separate source and destination registers 2. Standardize function signatures across architectures 3. Make the operations more explicit and potentially safer These changes could prevent: - Register corruption - Incorrect SIMD operations - Architecture-specific vulnerabilities - Potential buffer overflows in SIMD operations The pattern of changing from operations that modify the input register to operations that use separate input and output registers is consistent throughout the diff and appears to be a deliberate security improvement.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/the-canvas-state/2d.state.saverestore.shadowOffsetY.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.shadowOffsetY.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.shadowOffsetY;
Analysis of the provided code diff:
1. Vulnerability Existed: no
No security vulnerability found [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 Notes:
- The change appears to be purely a variable name refactoring from 'offscreenCanvas' to 'canvas'
- No security implications are evident in this change
- The modification doesn't affect any security-sensitive operations or introduce/remove any security controls
- This appears to be a code style or consistency improvement 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/dom/media/webrtc/transport/ipc/StunAddrsRequestChild.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/media/webrtc/transport/ipc/StunAddrsRequestChild.cpp@@ -11,13 +11,8 @@ namespace mozilla::net {-StunAddrsRequestChild::StunAddrsRequestChild(- StunAddrsListener* listener, nsISerialEventTarget* mainThreadEventTarget)+StunAddrsRequestChild::StunAddrsRequestChild(StunAddrsListener* listener) : mListener(listener) {- if (mainThreadEventTarget) {- gNeckoChild->SetEventTargetForActor(this, mainThreadEventTarget);- }- gNeckoChild->SendPStunAddrsRequestConstructor(this); // IPDL holds a reference until IPDL channel gets destroyed AddIPDLReference();
Let me analyze the code diff for potential security vulnerabilities.
Vulnerability Existed: not sure
[Potential Race Condition] [dom/media/webrtc/transport/ipc/StunAddrsRequestChild.cpp] [Lines 11-13]
[Old Code]
StunAddrsRequestChild::StunAddrsRequestChild(
StunAddrsListener* listener, nsISerialEventTarget* mainThreadEventTarget)
: mListener(listener) {
if (mainThreadEventTarget) {
gNeckoChild->SetEventTargetForActor(this, mainThreadEventTarget);
}
[Fixed Code]
StunAddrsRequestChild::StunAddrsRequestChild(StunAddrsListener* listener)
: mListener(listener) {
Additional Details:
The main change is the removal of the event target parameter and its associated setup. While this might not represent a direct security vulnerability, removing the ability to specify an event target could potentially lead to race conditions if the actor operations aren't properly synchronized. However, without more context about how this actor is used, it's difficult to determine if this actually introduces a security issue. The change suggests the event target management was moved elsewhere or made implicit.
No other obvious security vulnerabilities were identified in this diff. The rest of the changes appear to be code simplification 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/testing/web-platform/tests/css/css-content/reference/quotes-030-ref.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-content/reference/quotes-030-ref.html@@ -4,9 +4,9 @@ <title>CSS Generated Content reference: quotes</title> <link rel="author" title="Jonathan Kew" href="mailto:[email protected]"> <style>-body { font: 32px serif; }+body { font: 32px Arial, Helvetica, Noto Sans, DejaVu Sans, FreeSans, sans-serif; quotes: auto; } </style> <body> <p>Test passes if the quote marks in both lines match:-<p>One “two <span lang="ja">『three <span lang="fr">«four»</span>』</span>”-<p>One “two <span lang="ja">『three <span lang="fr">«four»</span>』</span>”+<p>One “two <span lang="ja">‘three <span lang="fr">『four』</span>’</span>”+<p>One “two <span lang="ja">‘three <span lang="fr">『four』</span>’</span>”
Based on the provided diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely stylistic and functional (related to quote rendering in CSS), not security-related. Here's the analysis:
Vulnerability Existed: no
No security vulnerability found [testing/web-platform/tests/css/css-content/reference/quotes-030-ref.html] [Lines 4,7-8]
[Old Code]
body { font: 32px serif; }
<p>Test passes if the quote marks in both lines match:
<p>One "two <span lang="ja">『three <span lang="fr">«four»</span>』</span>"
<p>One "two <span lang="ja">『three <span lang="fr">«four»</span>』</span>"
[Fixed Code]
body { font: 32px Arial, Helvetica, Noto Sans, DejaVu Sans, FreeSans, sans-serif; quotes: auto; }
<p>Test passes if the quote marks in both lines match:
<p>One "two <span lang="ja">‘three <span lang="fr">『four』</span>’</span>"
<p>One "two <span lang="ja">‘three <span lang="fr">『four』</span>’</span>"
The changes include:
1. Updated font stack in CSS
2. Added quotes: auto property
3. Changed quote characters in the test cases
None of these changes relate to security vulnerabilities.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/toolkit/components/glean/docs/dev/ipc.md+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/toolkit/components/glean/docs/dev/ipc.md@@ -136,12 +136,13 @@ FOG supports messaging between the following types of child process and the parent process: * content children (via `PContent` (for now. See [bug 1641989](https://bugzilla.mozilla.org/show_bug.cgi?id=1641989))+* gmp children (via `PGMP`) * gpu children (via `PGPU`) * rdd children (via `PRDD`) * socket children (via `PSocketProcess`) See-[the process model docs](../../../../dom/ipc/process_model.html)+[the process model docs](/dom/ipc/process_model.rst) for more information about what that means. ### Adding Support for a new Process Type
Analysis of the provided code diff:
1. Vulnerability Existed: no
Documentation Update [File] [Lines 136-144]
[Old Code]
FOG supports messaging between the following types of child process and the parent process:
* content children (via `PContent`
(for now. See [bug 1641989](https://bugzilla.mozilla.org/show_bug.cgi?id=1641989))
* gpu children (via `PGPU`)
* rdd children (via `PRDD`)
* socket children (via `PSocketProcess`)
See
[the process model docs](../../../../dom/ipc/process_model.html)
for more information about what that means.
[Fixed Code]
FOG supports messaging between the following types of child process and the parent process:
* content children (via `PContent`
(for now. See [bug 1641989](https://bugzilla.mozilla.org/show_bug.cgi?id=1641989))
* gmp children (via `PGMP`)
* gpu children (via `PGPU`)
* rdd children (via `PRDD`)
* socket children (via `PSocketProcess`)
See
[the process model docs](/dom/ipc/process_model.rst)
for more information about what that means.
Additional Details:
- The changes are purely documentation updates (adding GMP children support and updating a documentation link format)
- No security vulnerabilities are introduced or fixed in this change
- The modification appears to be a routine documentation improvement 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/serde_yaml/src/de.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/serde_yaml/src/de.rs@@ -987,7 +987,10 @@ return visitor.visit_i64(n); } }- if v.len() > 1 && v.starts_with('0') && v.bytes().all(|b| b.is_ascii_digit()) {+ if {+ let v = v.trim_start_matches(&['-', '+'][..]);+ v.len() > 1 && v.starts_with('0') && v[1..].bytes().all(|b| b.is_ascii_digit())+ } { // After handling the different number encodings above if we are left // with leading zero(s) followed by numeric characters this is in fact a // string according to the YAML 1.2 spec.
Here's the analysis of the provided code diff:
Vulnerability Existed: yes
Integer Parsing Vulnerability (Potential YAML Parsing Issue) [third_party/rust/serde_yaml/src/de.rs] [Lines 987-994]
[Old Code]
if v.len() > 1 && v.starts_with('0') && v.bytes().all(|b| b.is_ascii_digit()) {
[Fixed Code]
if {
let v = v.trim_start_matches(&['-', '+'][..]);
v.len() > 1 && v.starts_with('0') && v[1..].bytes().all(|b| b.is_ascii_digit())
} {
Additional Details:
- The fix addresses how numbers with leading zeros are handled in YAML parsing
- The old code didn't properly account for signed numbers (+/- prefixes) when checking for leading zeros
- The new code first trims sign characters before checking for leading zeros
- This could potentially prevent misinterpretation of strings as numbers in YAML parsing
- The vulnerability could be related to improper input validation or type confusion in YAML parsing
Note: While this is clearly a security-related fix, there isn't a widely recognized CVE or specific vulnerability name associated with this particular change. The issue appears to be a hardening of YAML number parsing logic.
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/reducers/preview.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/debugger/src/reducers/preview.js@@ -27,15 +27,4 @@ return state; }-// NOTE: we'd like to have the app state fully typed-// https://github.com/firefox-devtools/debugger/blob/master/src/reducers/sources.js#L179-L185--export function getPreview(state) {- return state.preview.preview;-}--export function getPreviewCount(state) {- return state.preview.previewCount;-}- export default update;
Based on the provided code diff, I'll analyze it for potential security vulnerabilities: 1. Vulnerability Existed: no [No specific vulnerability] [devtools/client/debugger/src/reducers/preview.js] [Lines 27-38] [Old Code: Two exported functions getPreview and getPreviewCount] [Fixed Code: Functions removed] Additional details: - The diff shows removal of two utility functions (getPreview and getPreviewCount) that were previously exporting state information - While this removes potential information exposure points, there's no clear security vulnerability being fixed here - The change appears to be more about code cleanup/refactoring rather than addressing a specific security issue - The comment about typing suggests this might be part of a larger code quality improvement effort No specific vulnerability name can be associated with this change as it doesn't show any clear security flaw being addressed. The removal of these functions might reduce potential attack surface slightly, but not in a way that indicates a specific vulnerability was present.
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/build/valgrind/mach_commands.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/build/valgrind/mach_commands.py@@ -8,6 +8,7 @@ import logging import mozinfo import os+import time from mach.decorators import ( Command,@@ -131,6 +132,7 @@ "--show-possibly-lost=no", "--track-origins=yes", "--trace-children=yes",+ "--trace-children-skip=*/dbus-launch", "-v", # Enable verbosity to get the list of used suppressions # Avoid excessive delays in the presence of spinlocks. # See bug 1309851.@@ -173,8 +175,34 @@ env=env, process_args=kp_kwargs, )+ start_time = time.monotonic() runner.start(debug_args=valgrind_args) exitcode = runner.wait(timeout=timeout)+ end_time = time.monotonic()+ if "MOZ_AUTOMATION" in os.environ:+ data = {+ "framework": {"name": "build_metrics"},+ "suites": [+ {+ "name": "valgrind",+ "value": end_time - start_time,+ "lowerIsBetter": True,+ "shouldAlert": False,+ "subtests": [],+ }+ ],+ }+ if "TASKCLUSTER_INSTANCE_TYPE" in os.environ:+ # Include the instance type so results can be grouped.+ data["suites"][0]["extraOptions"] = [+ "taskcluster-%s" % os.environ["TASKCLUSTER_INSTANCE_TYPE"],+ ]+ command_context.log(+ logging.INFO,+ "valgrind-perfherder",+ {"data": json.dumps(data)},+ "PERFHERDER_DATA: {data}",+ ) except BinaryNotFoundException as e: binary_not_found_exception = e finally:
Here's the analysis of the provided code diff: 1. Vulnerability Existed: not sure [Potential Information Leak] [build/valgrind/mach_commands.py] [Lines 175-200] [Old Code: No performance data collection] [Fixed Code: Added performance data collection including timing and environment variables] Details: The change adds performance metric collection that includes environment variables (TASKCLUSTER_INSTANCE_TYPE) in the output. While not clearly a vulnerability, exposing environment information could potentially leak sensitive data depending on what's in the environment. 2. Vulnerability Existed: no [Valgrind Child Process Tracing] [build/valgrind/mach_commands.py] [Lines 131-132] [Old Code: "--trace-children=yes"] [Fixed Code: Added "--trace-children-skip=*/dbus-launch"] Details: This change improves the valgrind configuration by skipping dbus-launch processes during child process tracing. This is a configuration improvement rather than a security fix. The main change that could potentially have security implications is the addition of performance data collection that includes environment information. However, without knowing the full context of the environment variables used in the build system, I can't definitively say this is a vulnerability. The other changes appear to be functional improvements rather than security fixes.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.arc.angle.5.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.arc.angle.5.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#0f0'; ctx.fillRect(0, 0, 100, 50);@@ -27,7 +27,7 @@ ctx.moveTo(100, 0); ctx.arc(100, 0, 150, (1024-1)*Math.PI, (512+1/2)*Math.PI, false); ctx.fill();-_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 find any security vulnerabilities in the changes. The modifications appear to be purely variable name changes and don't involve any security-sensitive operations. Here's the analysis:
1. Vulnerability Existed: no
No security vulnerability found [File] [Lines 17-18, 27]
Old Code:
```javascript
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
```
Fixed Code:
```javascript
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
```
Additional Details: This is a simple variable rename from 'offscreenCanvas' to 'canvas' with no security implications.
2. Vulnerability Existed: no
No security vulnerability found [File] [Line 27]
Old Code:
```javascript
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
```
Fixed Code:
```javascript
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
```
Additional Details: This change simply updates the variable name in the assertion to match the previous rename, with no security impact.
The changes are purely cosmetic/refactoring in nature and don't address any security vulnerabilities. The diff shows variable renaming for consistency but doesn't modify any security-sensitive logic or 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/js/src/jit-test/tests/stream/reader-closedPromise-handled-2.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/jit-test/tests/stream/reader-closedPromise-handled-2.js@@ -1,3 +1,4 @@+// |jit-test| skip-if: !this.hasOwnProperty("ReadableStream") // Releasing a reader should not result in a promise being tracked as // unhandled.
Let me analyze the provided code diff for security fixes.
Vulnerability Existed: no
[No specific vulnerability] [js/src/jit-test/tests/stream/reader-closedPromise-handled-2.js] [Lines 1]
[Old Code: (empty line)]
[Fixed Code: // |jit-test| skip-if: !this.hasOwnProperty("ReadableStream")]
Additional details:
1. This appears to be a test file modification rather than a security fix
2. The change adds a conditional skip directive for the test case
3. No actual code logic was modified, only a test annotation was added
4. The change ensures the test only runs when ReadableStream is available
No security vulnerabilities were fixed in this diff. The modification is related to test execution control rather than addressing any 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/toolkit/components/printing/tests/browser_sheet_count.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/toolkit/components/printing/tests/browser_sheet_count.js@@ -294,14 +294,28 @@ let pagesPerSheet = helper.get("pages-per-sheet-picker"); ok(BrowserTestUtils.is_visible(pagesPerSheet), "Pages per sheet is shown"); pagesPerSheet.focus();++ let popupOpen = BrowserTestUtils.waitForEvent(+ document.getElementById("ContentSelectDropdown"),+ "popupshown"+ );+ EventUtils.sendKey("space", helper.win);- for (let i = 0; i < 7; i++) {- EventUtils.sendKey("down", helper.win);- if (pagesPerSheet.value == 16) {++ await popupOpen;++ let numberMove =+ [...pagesPerSheet.options].map(o => o.value).indexOf("16") -+ pagesPerSheet.selectedIndex;++ for (let i = 0; i < numberMove; i++) {+ EventUtils.sendKey("down", window);+ if (document.activeElement.value == 16) { break; } }- await helper.waitForPreview(() => EventUtils.sendKey("return", helper.win));++ await helper.waitForPreview(() => EventUtils.sendKey("return", window)); sheets = helper.sheetCount; is(sheets, 1, "There's only one sheet now");
Let me analyze the code diff for potential security vulnerabilities: 1. Vulnerability Existed: no The changes appear to be test code improvements rather than security fixes. The modifications include: - Adding proper event waiting for popup opening - More precise keyboard navigation through options - Changing event target from helper.win to window - Better handling of option selection 2. Vulnerability Existed: no The changes are focused on test reliability and accuracy, specifically for: - Waiting for the popup to be fully shown before interaction - More deterministic option selection - Cleaner event handling No specific security vulnerabilities are addressed in this diff. The changes are primarily about making the test more robust and reliable, not about fixing security issues. The modifications involve test interaction patterns and event handling, but don't appear to relate to any known vulnerability classes like XSS, injection, or privilege escalation.
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.