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/dom/tests/mochitest/general/test_clipboard_disallowed.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/tests/mochitest/general/test_clipboard_disallowed.html@@ -22,44 +22,45 @@ { let clipboardData = event.clipboardData;- let exception;- try {- clipboardData.setData("application/x-moz-file", "Test");- } catch(ex) {- exception = ex;+ let disallowedTypes = [+ "application/x-moz-file",+ "application/x-moz-file-promise",+ "application/x-moz-file-promise-url",+ "application/x-moz-file-promise-dest-filename",+ "application/x-moz-file-promise-dir",+ "application/x-moz-nativeimage",+ "text/x-moz-requestmime",+ "text/x-moz-place",+ "text/x-moz-place-container",+ "text/x-moz-some-made-up-type",+ ];++ for (let type of disallowedTypes) {+ let exception;+ try {+ clipboardData.setData(type, "Test");+ } catch(ex) {+ exception = ex;+ }+ is(String(exception).indexOf("SecurityError"), 0, "Cannot set " + type); }- is(String(exception).indexOf("SecurityError"), 0, "Cannot set file");- exception = null;- try {- clipboardData.setData("application/x-moz-file-promise", "Test");- } catch(ex) {- exception = ex;+ let allowedTypes = [+ "application/something",+ "x-moz-/something",+ "something/ax-moz-",+ ];++ for (let type of allowedTypes) {+ let exception = null;+ try {+ clipboardData.setData(type, "This is data");+ } catch(ex) {+ exception = ex;+ }+ is(exception, null, "Can set " + type); }- is(String(exception).indexOf("SecurityError"), 0, "Cannot set file promise");- exception = null;- try {- clipboardData.setData("text/x-moz-place", "Test");- } catch(ex) {- exception = ex;- }- is(String(exception).indexOf("SecurityError"), 0, "Cannot set place");- exception = null;- try {- clipboardData.setData("text/x-moz-place-container", "Test");- } catch(ex) {- exception = ex;- }- is(String(exception).indexOf("SecurityError"), 0, "Cannot set place container");-- exception = null;- try {- clipboardData.setData("application/something", "This is data");- } catch(ex) {- exception = ex;- }- is(exception, null, "Can set custom data to a string"); SimpleTest.finish(); }
Here's the analysis of the provided code diff following the specified format: 1. Vulnerability Existed: yes Insecure Clipboard Data Handling [dom/tests/mochitest/general/test_clipboard_disallowed.html] [Lines 22-45] Old Code: ```javascript let exception; try { clipboardData.setData("application/x-moz-file", "Test"); } catch(ex) { exception = ex; } is(String(exception).indexOf("SecurityError"), 0, "Cannot set file"); ``` Fixed Code: ```javascript let disallowedTypes = [ "application/x-moz-file", "application/x-moz-file-promise", "application/x-moz-file-promise-url", "application/x-moz-file-promise-dest-filename", "application/x-moz-file-promise-dir", "application/x-moz-nativeimage", "text/x-moz-requestmime", "text/x-moz-place", "text/x-moz-place-container", "text/x-moz-some-made-up-type", ]; for (let type of disallowedTypes) { let exception; try { clipboardData.setData(type, "Test"); } catch(ex) { exception = ex; } is(String(exception).indexOf("SecurityError"), 0, "Cannot set " + type); } ``` 2. Vulnerability Existed: yes Incomplete Clipboard Security Checks [dom/tests/mochitest/general/test_clipboard_disallowed.html] [Lines 22-45] Old Code: ```javascript // Only tested a few specific types individually ``` Fixed Code: ```javascript // Added comprehensive list of disallowed types and testing loop ``` 3. Vulnerability Existed: not sure Potential Missing Clipboard Type Validation [dom/tests/mochitest/general/test_clipboard_disallowed.html] [Lines 22-45] Old Code: ```javascript // Only tested disallowed types ``` Fixed Code: ```javascript // Added explicit testing of allowed types let allowedTypes = [ "application/something", "x-moz-/something", "something/ax-moz-", ]; ``` Note: The changes appear to be security-related improvements to clipboard handling, particularly around preventing certain MIME types from being set via clipboard operations. The test was expanded to cover more cases systematically rather than just a few specific types. While this is a test file, the changes likely reflect actual security fixes in the browser's clipboard handling implementation.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/css-shapes/shape-outside/shape-box/shape-outside-padding-box-002.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-shapes/shape-outside/shape-box/shape-outside-padding-box-002.html@@ -8,7 +8,6 @@ <link rel="author" title="Mozilla" href="http://www.mozilla.org/"> <link rel="help" href="https://drafts.csswg.org/css-shapes-1/#shapes-from-box-values"> <link rel="match" href="reference/shape-outside-padding-box-002-ref.html">- <meta name="flags" content=""> <meta name="assert" content="Test the boxes are wrapping around the right float shape defined by the padding-box value."> <style> .container {
Based on the provided code diff, I don't see any security-related fixes. The change appears to be a simple removal of an empty meta tag for flags, which doesn't relate to security vulnerabilities. Vulnerability Existed: no No security vulnerability found [testing/web-platform/tests/css/css-shapes/shape-outside/shape-box/shape-outside-padding-box-002.html] [Lines 8] [Old Code] <meta name="flags" content=""> [Fixed Code] (removed line) This change appears to be a minor cleanup rather than a security fix. The removed meta tag was empty and not serving any apparent purpose in the test file.
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/actions/scriptworker_canary.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/taskcluster/gecko_taskgraph/actions/scriptworker_canary.py@@ -2,11 +2,10 @@ # License, v. 2.0. If a copy of the MPL was not distributed with this # file, You can obtain one at http://mozilla.org/MPL/2.0/.+from taskgraph.parameters import Parameters+from gecko_taskgraph.actions.registry import register_callback_action from gecko_taskgraph.decision import taskgraph_decision-from gecko_taskgraph.parameters import Parameters--from .registry import register_callback_action @register_callback_action(
Based on the provided code diff, I'll analyze it for potential security vulnerabilities: 1. Vulnerability Existed: not sure [Potential Import Reorganization] [taskcluster/gecko_taskgraph/actions/scriptworker_canary.py] [Lines 2-11] [Old Code] from gecko_taskgraph.decision import taskgraph_decision from gecko_taskgraph.parameters import Parameters from .registry import register_callback_action [Fixed Code] from taskgraph.parameters import Parameters from gecko_taskgraph.actions.registry import register_callback_action from gecko_taskgraph.decision import taskgraph_decision Notes: - The changes appear to be primarily import reorganization rather than security fixes - The main change is switching from `gecko_taskgraph.parameters` to `taskgraph.parameters` - There's no obvious security vulnerability being fixed here, but import reorganizations can sometimes address potential import-related security issues (like relative vs absolute imports) - Without more context about the parameter implementations, I can't be certain if this was security-related
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/devtools/server/actors/resources/parent-process-document-event.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/server/actors/resources/parent-process-document-event.js@@ -15,8 +15,8 @@ false ); const {- getAllRemoteBrowsingContexts,-} = require("devtools/server/actors/watcher/target-helpers/utils.js");+ getAllBrowsingContextsForContext,+} = require("devtools/server/actors/watcher/browsing-context-helpers.jsm"); const { WILL_NAVIGATE_TIME_SHIFT, } = require("devtools/server/actors/webconsole/listeners/document-events");@@ -54,9 +54,9 @@ this._onceWillNavigate = new Map(); // Filter browsing contexts to only have the top BrowsingContext of each tree of BrowsingContexts…- const topLevelBrowsingContexts = this.getAllBrowsingContexts().filter(- browsingContext => browsingContext.top == browsingContext- );+ const topLevelBrowsingContexts = getAllBrowsingContextsForContext(+ this.watcherActor.sessionContext+ ).filter(browsingContext => browsingContext.top == browsingContext); // Only register one WebProgressListener per BrowsingContext tree. // We will be notified about children BrowsingContext navigations/state changes via the top level BrowsingContextWebProgressListener,@@ -77,29 +77,6 @@ Ci.nsIWebProgress.NOTIFY_STATE_DOCUMENT ); });- }-- getAllBrowsingContexts() {- if (this.watcherActor.sessionContext.type == "browser-element") {- const browsingContext = this.watcherActor.browserElement.browsingContext;- return browsingContext.getAllBrowsingContextsInSubtree();- }-- if (this.watcherActor.sessionContext.type == "all") {- return getAllRemoteBrowsingContexts();- }-- if (this.watcherActor.sessionContext.type == "webextension") {- return getAllRemoteBrowsingContexts().filter(- bc =>- bc.currentWindowGlobal.documentPrincipal.addonId ==- this.watcherActor.sessionContext.addonId- );- }- throw new Error(- "Unsupported session context type=" +- this.watcherActor.sessionContext.type- ); } /**
Based on the provided code diff, here's the analysis following the required format: Vulnerability Existed: not sure [Potential Information Leak or Improper Context Handling] [devtools/server/actors/resources/parent-process-document-event.js] [Lines 15-17, 54-56] [Old Code] const { getAllRemoteBrowsingContexts, } = require("devtools/server/actors/watcher/target-helpers/utils.js"); ... const topLevelBrowsingContexts = this.getAllBrowsingContexts().filter( browsingContext => browsingContext.top == browsingContext ); [Fixed Code] const { getAllBrowsingContextsForContext, } = require("devtools/server/actors/watcher/browsing-context-helpers.jsm"); ... const topLevelBrowsingContexts = getAllBrowsingContextsForContext( this.watcherActor.sessionContext ).filter(browsingContext => browsingContext.top == browsingContext); Additional Details: 1. The change involves replacing a custom context gathering method (`getAllBrowsingContexts`) with a more standardized helper function (`getAllBrowsingContextsForContext`) 2. The removed method had different behavior based on session context types (browser-element, all, webextension) which could potentially lead to inconsistent context handling 3. The new implementation appears to delegate context gathering to a more centralized and likely better-tested helper function 4. While not clearly a security vulnerability, the change improves consistency in how browsing contexts are gathered, which could prevent potential security issues related to improper context isolation Vulnerability Existed: not sure [Removed Custom Context Handling] [devtools/server/actors/resources/parent-process-document-event.js] [Lines 77-96] [Old Code] Removed getAllBrowsingContexts() method with custom logic for different session types [Fixed Code] Method completely removed and replaced with standardized helper Additional Details: 1. The removal of custom context handling code reduces the attack surface 2. The custom implementation had potential for edge cases in how different session types were handled 3. The standardized helper function likely has better security auditing and testing 4. While not a confirmed vulnerability, removing custom security-sensitive code is generally a positive change Note: Without more context about the specific security implications of browsing context handling in Firefox, it's difficult to confirm if these were actual vulnerabilities. However, the changes appear to be security improvements by using more standardized and likely better-reviewed code paths.
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/streams/readable-streams/templated.any.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/streams/readable-streams/templated.any.js@@ -1,4 +1,4 @@-// META: global=window,worker,jsshell+// META: global=window,worker // META: script=../resources/test-utils.js // META: script=../resources/rs-test-templates.js 'use strict';
Let me analyze the code diff for potential security fixes. Vulnerability Existed: not sure [Removed jsshell global scope] [testing/web-platform/tests/streams/readable-streams/templated.any.js] [Lines 1] [Old Code] // META: global=window,worker,jsshell [Fixed Code] // META: global=window,worker Additional Details: The change removes 'jsshell' from the list of global scopes where this test should run. This could be a security-related change if: 1. The jsshell environment had some security vulnerabilities that these tests could expose 2. The tests weren't properly secured for jsshell environment 3. The jsshell environment was deprecated for security reasons However, without more context about why this change was made, I can't be certain if this was specifically for security reasons or just a test scope adjustment. The change does reduce the attack surface by limiting where the tests run, which could be considered a security improvement. No other vulnerabilities are apparent in this small 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/line-styles/2d.line.join.valid.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/line-styles/2d.line.join.valid.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.lineJoin = 'bevel' _assertSame(ctx.lineJoin, 'bevel', "ctx.lineJoin", "'bevel'");
Analyzing the provided code diff, here's the security assessment: Vulnerability Existed: no [No specific vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/line-styles/2d.line.join.valid.worker.js] [Lines 13-14] [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 changes appear to be purely cosmetic/refactoring, renaming the variable from 'offscreenCanvas' to 'canvas'. There are no security-related changes in this diff. The modification doesn't affect any security controls, input validation, or sensitive operations. This is likely a code style 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/tests/mochitests/test_peerConnection_videoCodecs.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/media/webrtc/tests/mochitests/test_peerConnection_videoCodecs.html@@ -2,6 +2,7 @@ <html> <head> <script type="application/javascript" src="pc.js"></script>+ <script type="application/javascript" src="stats.js"></script> <script type="application/javascript" src="/tests/dom/canvas/test/captureStream_common.js"></script> </head> <body>@@ -16,6 +17,7 @@ const test = new PeerConnectionTest(options); test.setMediaConstraints([{video: true}], []);+ let payloadType; test.chain.insertBefore("PC_LOCAL_SET_LOCAL_DESCRIPTION", [ function PC_LOCAL_FILTER_OUT_CODECS() { const otherCodec = codecs.find(c => c != codec);@@ -23,6 +25,7 @@ const otherRtpmapMatcher = new RegExp(`a=rtpmap:${otherId}.*\\r\\n`, "gi"); const id = sdputils.findCodecId(test.originalOffer.sdp, codec.name, codec.offset);+ payloadType = Number(id); if (codec.offset) { isnot(id, sdputils.findCodecId(test.originalOffer.sdp, codec.name, 0), "Different offsets should return different payload types");@@ -41,7 +44,37 @@ }, ]);+ test.chain.insertAfter("PC_LOCAL_WAIT_FOR_MEDIA_FLOW",+ [PC_LOCAL_TEST_LOCAL_STATS]);++ test.chain.insertAfter("PC_REMOTE_WAIT_FOR_MEDIA_FLOW",+ [PC_REMOTE_TEST_REMOTE_STATS]);+ test.chain.append([+ async function PC_LOCAL_TEST_CODEC() {+ const stats = await test.pcLocal._pc.getStats();+ let codecCount = 0;+ stats.forEach(stat => {+ if (stat.type == "codec") {+ is(codecCount++, 0, "expected only one encode codec stat");+ is(stat.payloadType, payloadType, "payloadType as expected");+ is(stat.mimeType, `video/${codec.name}`, "mimeType as expected");+ is(stat.codecType, "encode", "codecType as expected");+ }+ });+ },+ async function PC_REMOTE_TEST_CODEC() {+ const stats = await test.pcRemote._pc.getStats();+ let codecCount = 0;+ stats.forEach(stat => {+ if (stat.type == "codec") {+ is(codecCount++, 0, "expected only one decode codec stat");+ is(stat.payloadType, payloadType, "payloadType as expected");+ is(stat.mimeType, `video/${codec.name}`, "mimeType as expected");+ is(stat.codecType, "decode", "codecType as expected");+ }+ });+ }, async function CHECK_VIDEO_FLOW() { try { const h = new VideoStreamHelper();
Based on the provided code diff, I'll analyze it for potential security vulnerabilities: 1. Vulnerability Existed: no No specific security vulnerability is being fixed in this diff. The changes appear to be functional test improvements rather than security fixes. 2. Vulnerability Existed: not sure [Potential Information Leak] [dom/media/webrtc/tests/mochitests/test_peerConnection_videoCodecs.html] [Lines 2,16,23,41-74] [Old Code] No stats.js included No stats collection/verification [Fixed Code] Added stats.js inclusion Added stats collection and verification code While not clearly a security vulnerability, the addition of stats collection could potentially expose more information than intended if not properly secured. However, this appears to be test code for verification purposes. The main changes in this diff are: 1. Adding a new script include for stats.js 2. Adding stats collection and verification code for WebRTC codecs 3. Adding payload type tracking 4. Adding new test functions for codec verification These changes appear to be test improvements rather than security fixes. The code is adding more thorough verification of WebRTC functionality, particularly around codec statistics and payload types.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/layout/style/CSSPageRule.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/layout/style/CSSPageRule.h@@ -71,6 +71,9 @@ void GetCssText(nsACString& aCssText) const final; nsICSSDeclaration* Style();+ void GetSelectorText(nsACString& aSelectorText) const;+ void SetSelectorText(const nsACString& aSelectorText);+ size_t SizeOfIncludingThis(MallocSizeOf aMallocSizeOf) const final; #ifdef DEBUG
Based on the provided diff, I'll analyze it for potential security vulnerabilities: 1. Vulnerability Existed: not sure [Potential Missing Access Control] [CSSPageRule.h] [Lines 71-73] [Old Code: (no selector text methods)] [Fixed Code: Added GetSelectorText and SetSelectorText methods] Additional Details: - The diff shows the addition of two new methods for handling selector text in CSSPageRule.h - Without seeing the implementation of these methods, we can't be certain if there were security issues - The addition could be related to fixing potential improper access control or input validation issues with CSS page rule selectors - The change might be addressing CWE-284 (Improper Access Control) if the methods were added to properly validate or control access to selector text Note: Since we only see the header file change and not the implementation, we can't definitively identify any specific vulnerabilities that were fixed. The changes could be purely functional rather than security-related.
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/attrs/attr/filters.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/python/attrs/attr/filters.py@@ -1,5 +1,5 @@ """-Commonly useful filters for :func:`attr.asdict`.+Commonly useful filters for `attr.asdict`. """ from __future__ import absolute_import, division, print_function@@ -23,9 +23,9 @@ Whitelist *what*. :param what: What to whitelist.- :type what: :class:`list` of :class:`type` or :class:`attr.Attribute`\\ s+ :type what: `list` of `type` or `attr.Attribute`\\ s- :rtype: :class:`callable`+ :rtype: `callable` """ cls, attrs = _split_what(what)@@ -40,9 +40,9 @@ Blacklist *what*. :param what: What to blacklist.- :type what: :class:`list` of classes or :class:`attr.Attribute`\\ s.+ :type what: `list` of classes or `attr.Attribute`\\ s.- :rtype: :class:`callable`+ :rtype: `callable` """ cls, attrs = _split_what(what)
After analyzing the provided code diff, I can identify that this is primarily a documentation change rather than a security fix. Here's my analysis: Vulnerability Existed: no Documentation Format Change [third_party/python/attrs/attr/filters.py] [1,23,40] [Old Code] -Commonly useful filters for :func:`attr.asdict`. -:type what: :class:`list` of :class:`type` or :class:`attr.Attribute`\\ s -:rtype: :class:`callable` +:type what: `list` of `type` or `attr.Attribute`\\ s +:rtype: `callable` [Fixed Code] +Commonly useful filters for `attr.asdict`. +:type what: `list` of `type` or `attr.Attribute`\\ s +:rtype: `callable` The changes involve: 1. Changing documentation format from Sphinx-style (using :func:, :class:) to plain backticks 2. No functional code changes were made 3. No security-related modifications were identified The diff shows only documentation formatting updates, with no changes to the actual implementation or security-related aspects of the code. The functionality remains identical between versions.
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/talos/talos/output.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/talos/talos/output.py@@ -218,8 +218,16 @@ # This is the output that treeherder expects to find when parsing the # log file- if "gecko-profile" not in self.results.extra_options:- LOG.info("PERFHERDER_DATA: %s" % json.dumps(results, ignore_nan=True))+ if "gecko-profile" in self.results.extra_options:+ LOG.info("gecko-profile enabled")++ for suite in results["suites"]:+ suite["shouldAlert"] = False+ for subtest in suite["subtests"]:+ subtest["shouldAlert"] = False++ LOG.info("PERFHERDER_DATA: %s" % json.dumps(results, ignore_nan=True))+ if results_scheme in ("file"): json.dump( results,
Analyzing the provided code diff for security fixes: 1. Vulnerability Existed: not sure [Potential Information Exposure] [testing/talos/talos/output.py] [Lines 218-226] [Old Code] ```python if "gecko-profile" not in self.results.extra_options: LOG.info("PERFHERDER_DATA: %s" % json.dumps(results, ignore_nan=True)) ``` [Fixed Code] ```python if "gecko-profile" in self.results.extra_options: LOG.info("gecko-profile enabled") for suite in results["suites"]: suite["shouldAlert"] = False for subtest in suite["subtests"]: subtest["shouldAlert"] = False LOG.info("PERFHERDER_DATA: %s" % json.dumps(results, ignore_nan=True)) ``` Additional Details: The change modifies how performance data is logged, potentially addressing information exposure concerns by disabling alerts when gecko-profile is enabled. However, without more context about the data being logged, this is uncertain. 2. Vulnerability Existed: not sure [Potential JSON Injection] [testing/talos/talos/output.py] [Lines 218-226] [Old Code] ```python LOG.info("PERFHERDER_DATA: %s" % json.dumps(results, ignore_nan=True)) ``` [Fixed Code] ```python LOG.info("PERFHERDER_DATA: %s" % json.dumps(results, ignore_nan=True)) ``` Additional Details: The JSON dumping remains unchanged, but the context suggests this might be related to preventing injection attacks. The use of `ignore_nan=True` helps with safe JSON serialization, though this isn't a clear security fix. Note: The changes appear more focused on functionality (disabling alerts for gecko-profile cases) than explicit security fixes. No clear CVEs or standard vulnerability patterns are evident 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/devtools/server/actors/descriptors/process.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/server/actors/descriptors/process.js@@ -8,6 +8,9 @@ const { DevToolsServer } = require("devtools/server/devtools-server"); const { Cc, Ci } = require("chrome");+const {+ createBrowserSessionContext,+} = require("devtools/server/actors/watcher/session-context"); const { ActorClassWithSpec, Actor } = require("devtools/shared/protocol"); const { processDescriptorSpec,@@ -89,6 +92,7 @@ // the BrowserToolbox and isTopLevelTarget should always be true here. // (It isn't the typical behavior of WindowGlobalTargetActor's base class) isTopLevelTarget: true,+ sessionContext: createBrowserSessionContext(), }); // this is a special field that only parent process with a browsing context // have, as they are the only processes at the moment that have child@@ -157,9 +161,7 @@ */ getWatcher() { if (!this.watcher) {- this.watcher = new WatcherActor(this.conn, {- type: "all",- });+ this.watcher = new WatcherActor(this.conn, createBrowserSessionContext()); this.manage(this.watcher); } return this.watcher;
Here's the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: not sure [Potential Session Context Vulnerability] [devtools/server/actors/descriptors/process.js] [Lines 89-92, 157-161] [Old Code] ``` isTopLevelTarget: true, ``` ``` this.watcher = new WatcherActor(this.conn, { type: "all", }); ``` [Fixed Code] ``` isTopLevelTarget: true, sessionContext: createBrowserSessionContext(), ``` ``` this.watcher = new WatcherActor(this.conn, createBrowserSessionContext()); ``` Additional Details: The changes introduce a session context creation through `createBrowserSessionContext()` for both the process descriptor and watcher actor. While not explicitly fixing a known vulnerability, this appears to be adding proper session isolation which could prevent potential session-related security issues. The change from a simple `{type: "all"}` configuration to a proper session context suggests improved security controls around session management. Note: Without more context about the specific security implications of the previous implementation or the exact functionality of `createBrowserSessionContext()`, I can't definitively identify a specific vulnerability being fixed, but the change appears to be security-related.
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/CSS2/floats/floats-line-wrap-shifted-001.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/CSS2/floats/floats-line-wrap-shifted-001.html@@ -2,7 +2,6 @@ <link rel="author" title="Koji Ishii" href="[email protected]"> <link rel="help" href="https://drafts.csswg.org/css2/visuren.html#float-position"> <link rel="match" href="floats-line-wrap-shifted-001-ref.html">-<meta name="flags" content="" /> <meta name="assert" content="Float may not be higher than line-box containing a box generated by an element earlier in the source document." /> <style>
Analysis of the provided code diff: 1. Vulnerability Existed: no No security vulnerability found [File] [Lines 2-7] Old Code: `<meta name="flags" content="" />` Fixed Code: (removed line) Additional Details: - The diff shows removal of an empty meta tag with name="flags". This appears to be a cleanup change rather than a security fix. - No known vulnerabilities are associated with this change. - The change is likely related to test configuration rather than 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/testing/web-platform/tests/html/canvas/offscreen/the-offscreen-canvas/2d.getcontext.exists.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/the-offscreen-canvas/2d.getcontext.exists.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); var offscreenCanvas2 = new OffscreenCanvas(100, 50); _assertDifferent(offscreenCanvas2.getContext('2d'), null, "offscreenCanvas2.getContext('2d')", "null");
Let me analyze the provided code diff for security fixes. Vulnerability Existed: no [No specific vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/the-offscreen-canvas/2d.getcontext.exists.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'); The changes appear to be purely variable naming changes (from 'offscreenCanvas' to 'canvas') and don't indicate any security fixes. The functionality remains the same, just with improved variable naming consistency. There are no security-related patterns or known vulnerabilities being addressed 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/js/src/vm/Runtime.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/vm/Runtime.h@@ -60,7 +60,7 @@ #include "js/WrapperCallbacks.h" #include "js/Zone.h" #include "threading/Thread.h"-#include "vm/Caches.h"+#include "vm/Caches.h" // js::RuntimeCaches #include "vm/CodeCoverage.h" #include "vm/CommonPropertyNames.h" #include "vm/GeckoProfiler.h"@@ -101,6 +101,8 @@ extern MOZ_COLD void ReportOutOfMemory(JSContext* cx); extern MOZ_COLD void ReportAllocationOverflow(JSContext* maybecx);+extern MOZ_COLD void ReportOversizedAllocation(JSContext* cx,+ const unsigned errorNumber); class Activation; class ActivationIterator;@@ -993,7 +995,7 @@ } private:- js::MainThreadData<js::RuntimeCaches> caches_;+ js::MainThreadOrParseData<js::RuntimeCaches> caches_; public: js::RuntimeCaches& caches() { return caches_.ref(); }
Here's the analysis of the provided code diff following the specified format: 1. Vulnerability Existed: not sure [Potential Thread Safety Issue] [File: js/src/vm/Runtime.h] [Lines: ~993] [Old Code] `js::MainThreadData<js::RuntimeCaches> caches_;` [Fixed Code] `js::MainThreadOrParseData<js::RuntimeCaches> caches_;` Additional Details: The change from MainThreadData to MainThreadOrParseData suggests improved thread safety handling, but without more context it's unclear if this was fixing an actual vulnerability or just a precautionary measure. 2. Vulnerability Existed: not sure [Potential Memory Allocation Vulnerability] [File: js/src/vm/Runtime.h] [Lines: ~101] [Old Code] (No previous declaration of ReportOversizedAllocation) [Fixed Code] `extern MOZ_COLD void ReportOversizedAllocation(JSContext* cx, const unsigned errorNumber);` Additional Details: The addition of ReportOversizedAllocation suggests improved handling of large memory allocations, but without seeing the implementation or knowing the context, we can't be certain if this fixes an existing vulnerability. Note: The diff shows two main changes: 1. A comment was added to clarify the include statement 2. The caches_ member variable type was changed to potentially support different thread contexts 3. A new function declaration was added for oversized allocation reporting Without more context about actual vulnerabilities that were fixed or security bulletins related to these changes, we can only speculate about potential security implications. The changes appear to be related to memory management and thread safety improvements, which often have security implications, but we can't definitively say these were fixing known vulnerabilities.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.pattern.paint.repeat.coord2.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.pattern.paint.repeat.coord2.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); var promise = new Promise(function(resolve, reject) { var xhr = new XMLHttpRequest();@@ -30,10 +30,10 @@ var pattern = ctx.createPattern(bitmap, 'no-repeat'); ctx.fillStyle = pattern; ctx.fillRect(0, 0, 100, 50);- _assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");- _assertPixel(offscreenCanvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");- _assertPixel(offscreenCanvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");- _assertPixel(offscreenCanvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255");+ _assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");+ _assertPixel(canvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");+ _assertPixel(canvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");+ _assertPixel(canvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255"); }, t_fail); }).then(t_pass, t_fail);
Analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and corresponding updates to the variable name in the assertions. There's no change in security-related functionality. Here's the structured response: Vulnerability Existed: no No security vulnerability found File: testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.pattern.paint.repeat.coord2.worker.js Old Code: var offscreenCanvas = new OffscreenCanvas(100, 50); Fixed Code: var canvas = new OffscreenCanvas(100, 50); The changes are purely cosmetic/refactoring in nature and don't address any security issues. The functionality remains identical, 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/css/css-tables/subpixel-collapsed-borders-003.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-tables/subpixel-collapsed-borders-003.html@@ -4,7 +4,6 @@ <link rel="help" href="https://drafts.csswg.org/css-tables-3/#border-conflict-resolution-algorithm"> <link rel="help" href="https://github.com/w3c/csswg-drafts/issues/606"> <link rel="match" href="subpixel-collapsed-borders-003-ref.html">-<meta name="flags" content="" /> <meta name="assert" content="When collapsed border tables have border widths larger than cells', the table border wins even when the floored table border is the same size as the cell's." /> <style>
After analyzing the provided code diff, here's the security assessment: Vulnerability Existed: no No security vulnerability found [File] testing/web-platform/tests/css/css-tables/subpixel-collapsed-borders-003.html [Lines] 4 Old Code: <meta name="flags" content="" /> Fixed Code: (removed line) Additional Details: 1. The change simply removes an empty meta tag for "flags" which appears to be test-related metadata. 2. This modification doesn't appear to address any security vulnerability, but rather cleans up test markup. 3. The empty flags attribute wasn't serving any security purpose and its removal doesn't impact security. Note: If this were a security-related change, we would expect to see modifications to actual functionality or input handling rather than just test metadata cleanup.
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/jsapi/PeerConnectionImpl.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/media/webrtc/jsapi/PeerConnectionImpl.cpp@@ -669,7 +669,7 @@ } void operator()(UniquePtr<JsepCodecDescription>& codec) const {- switch (codec->mType) {+ switch (codec->Type()) { case SdpMediaSection::kAudio: { JsepAudioCodecDescription& audioCodec = static_cast<JsepAudioCodecDescription&>(*codec);@@ -769,7 +769,7 @@ } void operator()(UniquePtr<JsepCodecDescription>& codec) const {- if (codec->mType == SdpMediaSection::kVideo && codec->mEnabled == false) {+ if (codec->Type() == SdpMediaSection::kVideo && !codec->mEnabled) { uint8_t pt = (uint8_t)strtoul(codec->mDefaultPt.c_str(), nullptr, 10); // don't search for the codec payload type unless we have a valid // conversion (non-zero)@@ -906,11 +906,11 @@ } for (const auto& codec : encoding.GetCodecs()) {- if (codec->mType != SdpMediaSection::kApplication) {+ if (codec->Type() != SdpMediaSection::kApplication) { CSFLogError(LOGTAG, "%s: Codec type for m=application was %u, this " "is a bug.",- __FUNCTION__, static_cast<unsigned>(codec->mType));+ __FUNCTION__, static_cast<unsigned>(codec->Type())); MOZ_ASSERT(false, "Codec for m=application was not \"application\""); return NS_ERROR_FAILURE; }@@ -2560,20 +2560,21 @@ // TODO(bug 1616937): Move this to RTCRtpSender. nsTArray<RefPtr<dom::RTCStatsPromise>> PeerConnectionImpl::GetSenderStats(- const RefPtr<MediaPipelineTransmit>& aPipeline) {+ const RefPtr<TransceiverImpl>& aTransceiver) { MOZ_ASSERT(NS_IsMainThread());+ RefPtr<MediaPipelineTransmit> pipeline = aTransceiver->GetSendPipeline(); nsTArray<RefPtr<RTCStatsPromise>> promises(2); nsAutoString trackName;- if (auto track = aPipeline->GetTrack()) {+ if (auto track = pipeline->GetTrack()) { track->GetId(trackName); } { // Add bandwidth estimation stats promises.AppendElement(InvokeAsync(- aPipeline->mCallThread, __func__,- [conduit = aPipeline->mConduit, trackName]() mutable {+ pipeline->mCallThread, __func__,+ [conduit = pipeline->mConduit, trackName]() mutable { auto report = MakeUnique<dom::RTCStatsCollection>(); Maybe<webrtc::Call::Stats> stats = conduit->GetCallStats(); stats.apply([&](const auto aStats) {@@ -2596,21 +2597,21 @@ } promises.AppendElement(- InvokeAsync(aPipeline->mCallThread, __func__, [aPipeline] {+ InvokeAsync(pipeline->mCallThread, __func__, [pipeline] { auto report = MakeUnique<dom::RTCStatsCollection>();- auto asAudio = aPipeline->mConduit->AsAudioSessionConduit();- auto asVideo = aPipeline->mConduit->AsVideoSessionConduit();+ auto asAudio = pipeline->mConduit->AsAudioSessionConduit();+ auto asVideo = pipeline->mConduit->AsVideoSessionConduit(); nsString kind = asVideo.isNothing() ? u"audio"_ns : u"video"_ns; nsString idstr = kind + u"_"_ns;- idstr.AppendInt(static_cast<uint32_t>(aPipeline->Level()));-- for (uint32_t ssrc : aPipeline->mConduit->GetLocalSSRCs()) {+ idstr.AppendInt(static_cast<uint32_t>(pipeline->Level()));++ for (uint32_t ssrc : pipeline->mConduit->GetLocalSSRCs()) { nsString localId = u"outbound_rtp_"_ns + idstr + u"_"_ns; localId.AppendInt(ssrc); nsString remoteId; Maybe<uint16_t> base_seq =- aPipeline->mConduit->RtpSendBaseSeqFor(ssrc);+ pipeline->mConduit->RtpSendBaseSeqFor(ssrc); auto constructCommonRemoteInboundRtpStats = [&](RTCRemoteInboundRtpStreamStats& aRemote,@@ -2618,7 +2619,7 @@ remoteId = u"outbound_rtcp_"_ns + idstr + u"_"_ns; remoteId.AppendInt(ssrc); aRemote.mTimestamp.Construct(- aPipeline->GetTimestampMaker().ConvertNtpToDomTime(+ pipeline->GetTimestampMaker().ConvertNtpToDomTime( webrtc::Timestamp::Micros( aRtcpData.report_block_timestamp_utc_us()) + webrtc::TimeDelta::Seconds(webrtc::kNtpJan1970)));@@ -2646,7 +2647,7 @@ [&](RTCOutboundRtpStreamStats& aLocal) { aLocal.mSsrc.Construct(ssrc); aLocal.mTimestamp.Construct(- aPipeline->GetTimestampMaker().GetNow());+ pipeline->GetTimestampMaker().GetNow()); aLocal.mId.Construct(localId); aLocal.mType.Construct(RTCStatsType::Outbound_rtp); aLocal.mMediaType.Construct(@@ -2661,6 +2662,13 @@ Maybe<webrtc::AudioSendStream::Stats> audioStats = aConduit->GetSenderStats(); if (audioStats.isNothing()) {+ return;+ }++ if (audioStats->packets_sent == 0) {+ // By spec: "The lifetime of all RTP monitored objects starts+ // when the RTP stream is first used: When the first RTP packet+ // is sent or received on the SSRC it represents" return; }@@ -2744,10 +2752,18 @@ streamStats = Some(kv->second); }+ if (!streamStats ||+ streamStats->rtp_stats.first_packet_time_ms == -1) {+ // By spec: "The lifetime of all RTP monitored objects starts+ // when the RTP stream is first used: When the first RTP packet+ // is sent or received on the SSRC it represents"+ return;+ }+ // First, fill in remote stat with rtcp receiver data, if present. // ReceiverReports have less information than SenderReports, so fill // in what we can.- if (streamStats && streamStats->report_block_data) {+ if (streamStats->report_block_data) { const webrtc::ReportBlockData& rtcpReportData = *streamStats->report_block_data; RTCRemoteInboundRtpStreamStats remote;@@ -2781,31 +2797,29 @@ // present) RTCOutboundRtpStreamStats local; constructCommonOutboundRtpStats(local);- streamStats.apply([&](auto& aStreamStats) {- local.mPacketsSent.Construct(- aStreamStats.rtp_stats.transmitted.packets);- local.mBytesSent.Construct(- aStreamStats.rtp_stats.transmitted.payload_bytes);- local.mNackCount.Construct(- aStreamStats.rtcp_packet_type_counts.nack_packets);- local.mFirCount.Construct(- aStreamStats.rtcp_packet_type_counts.fir_packets);- local.mPliCount.Construct(- aStreamStats.rtcp_packet_type_counts.pli_packets);- local.mFramesEncoded.Construct(aStreamStats.frames_encoded);- if (aStreamStats.qp_sum) {- local.mQpSum.Construct(*aStreamStats.qp_sum);- }- });+ local.mPacketsSent.Construct(+ streamStats->rtp_stats.transmitted.packets);+ local.mBytesSent.Construct(+ streamStats->rtp_stats.transmitted.payload_bytes);+ local.mNackCount.Construct(+ streamStats->rtcp_packet_type_counts.nack_packets);+ local.mFirCount.Construct(+ streamStats->rtcp_packet_type_counts.fir_packets);+ local.mPliCount.Construct(+ streamStats->rtcp_packet_type_counts.pli_packets);+ local.mFramesEncoded.Construct(streamStats->frames_encoded);+ if (streamStats->qp_sum) {+ local.mQpSum.Construct(*streamStats->qp_sum);+ } /* * Potential new stats that are now available upstream. local.mHeaderBytesSent.Construct(- aStreamStats.rtp_stats.transmitted.header_bytes +- aStreamStats.rtp_stats.transmitted.padding_bytes);+ streamStats->rtp_stats.transmitted.header_bytes ++ streamStats->rtp_stats.transmitted.padding_bytes); local.mRetransmittedPacketsSent.Construct(- aStreamStats.rtp_stats.retransmitted.packets);+ streamStats->rtp_stats.retransmitted.packets); local.mRetransmittedBytesSent.Construct(- aStreamStats.rtp_stats.retransmitted.payload_bytes);+ streamStats->rtp_stats.retransmitted.payload_bytes); local.mTargetBitrate.Construct(videoStats->target_media_bitrate_bps); local.mTotalEncodedBytesTarget.Construct( videoStats->total_encoded_bytes_target);@@ -2870,33 +2884,160 @@ } }+nsTArray<dom::RTCCodecStats> PeerConnectionImpl::GetCodecStats(+ DOMHighResTimeStamp aNow) {+ MOZ_ASSERT(NS_IsMainThread());+ nsTArray<dom::RTCCodecStats> result;++ if (!mMedia) {+ return result;+ }++ struct CodecComparator {+ bool operator()(const JsepCodecDescription* aA,+ const JsepCodecDescription* aB) const {+ return aA->StatsId() < aB->StatsId();+ }+ };++ // transportId -> codec; per direction (whether the codecType+ // shall be "encode", "decode" or absent (if a codec exists in both maps for a+ // transport)). These do the bookkeeping to ensure codec stats get coalesced+ // to transport level.+ std::map<std::string, std::set<JsepCodecDescription*, CodecComparator>>+ sendCodecMap;+ std::map<std::string, std::set<JsepCodecDescription*, CodecComparator>>+ recvCodecMap;++ // Find all JsepCodecDescription instances we want to turn into codec stats.+ for (const auto& transceiver : mMedia->GetTransceivers()) {+ auto sendCodecs = transceiver->GetNegotiatedSendCodecs();+ auto recvCodecs = transceiver->GetNegotiatedRecvCodecs();++ const std::string transportId = transceiver->GetTransportId();+ // This ensures both codec maps have the same size.+ auto& sendMap = sendCodecMap[transportId];+ auto& recvMap = recvCodecMap[transportId];++ sendCodecs.apply([&](const auto& aCodecs) {+ for (const auto& codec : aCodecs) {+ sendMap.insert(codec.get());+ }+ });+ recvCodecs.apply([&](const auto& aCodecs) {+ for (const auto& codec : aCodecs) {+ recvMap.insert(codec.get());+ }+ });+ }++ auto createCodecStat = [&](const JsepCodecDescription* aCodec,+ const nsString& aTransportId,+ Maybe<RTCCodecType> aCodecType) {+ uint16_t pt;+ {+ DebugOnly<bool> rv = aCodec->GetPtAsInt(&pt);+ MOZ_ASSERT(rv);+ }+ nsString mimeType;+ mimeType.AppendPrintf(+ "%s/%s", aCodec->Type() == SdpMediaSection::kVideo ? "video" : "audio",+ aCodec->mName.c_str());+ nsString id = aTransportId;+ id.Append(u"_");+ id.Append(aCodec->StatsId());++ dom::RTCCodecStats codec;+ codec.mId.Construct(std::move(id));+ codec.mTimestamp.Construct(aNow);+ codec.mType.Construct(RTCStatsType::Codec);+ codec.mPayloadType = pt;+ if (aCodecType) {+ codec.mCodecType.Construct(*aCodecType);+ }+ codec.mTransportId = aTransportId;+ codec.mMimeType = std::move(mimeType);+ codec.mClockRate.Construct(aCodec->mClock);+ if (aCodec->Type() == SdpMediaSection::MediaType::kAudio) {+ codec.mChannels.Construct(aCodec->mChannels);+ }+ if (aCodec->mSdpFmtpLine) {+ codec.mSdpFmtpLine.Construct(+ NS_ConvertUTF8toUTF16(aCodec->mSdpFmtpLine->c_str()));+ }++ result.AppendElement(std::move(codec));+ };++ // Create codec stats for the gathered codec descriptions, sorted primarily+ // by transportId, secondarily by payload type (from StatsId()).+ for (const auto& [transportId, sendCodecs] : sendCodecMap) {+ const auto& recvCodecs = recvCodecMap[transportId];+ const nsString tid = NS_ConvertASCIItoUTF16(transportId);+ AutoTArray<JsepCodecDescription*, 16> bidirectionalCodecs;+ AutoTArray<JsepCodecDescription*, 16> unidirectionalCodecs;+ std::set_intersection(sendCodecs.cbegin(), sendCodecs.cend(),+ recvCodecs.cbegin(), recvCodecs.cend(),+ MakeBackInserter(bidirectionalCodecs),+ CodecComparator());+ std::set_symmetric_difference(sendCodecs.cbegin(), sendCodecs.cend(),+ recvCodecs.cbegin(), recvCodecs.cend(),+ MakeBackInserter(unidirectionalCodecs),+ CodecComparator());+ for (const auto* codec : bidirectionalCodecs) {+ createCodecStat(codec, tid, Nothing());+ }+ for (const auto* codec : unidirectionalCodecs) {+ createCodecStat(+ codec, tid,+ Some(codec->mDirection == sdp::kSend ? RTCCodecType::Encode+ : RTCCodecType::Decode));+ }+ }++ return result;+}+ RefPtr<dom::RTCStatsReportPromise> PeerConnectionImpl::GetStats( dom::MediaStreamTrack* aSelector, bool aInternalStats) { MOZ_ASSERT(NS_IsMainThread()); nsTArray<RefPtr<dom::RTCStatsPromise>> promises; DOMHighResTimeStamp now = mTimestampMaker.GetNow();+ nsTArray<dom::RTCCodecStats> codecStats = GetCodecStats(now);+ if (mMedia) {- nsTArray<RefPtr<MediaPipelineTransmit>> sendPipelines;- // Gather up pipelines from mMedia so they may be inspected on STS- // TODO(bug 1616937): Use RTCRtpSender for these instead.- mMedia->GetTransmitPipelinesMatching(aSelector, &sendPipelines);- if (!sendPipelines.Length()) {- CSFLogError(LOGTAG, "%s: Found no pipelines matching selector.",- __FUNCTION__);- }-- for (const auto& pipeline : sendPipelines) {- promises.AppendElements(GetSenderStats(pipeline));- }-+ nsTArray<+ std::tuple<TransceiverImpl*, RefPtr<RTCStatsPromise::AllPromiseType>>>+ transceiverStatsPromises; for (const auto& transceiver : mMedia->GetTransceivers()) {- if (transceiver->Receiver()->HasTrack(aSelector)) {+ const bool sendSelected = transceiver->HasSendTrack(aSelector);+ const bool recvSelected = transceiver->Receiver()->HasTrack(aSelector);+ if (!sendSelected && !recvSelected) {+ continue;+ }+ nsTArray<RefPtr<RTCStatsPromise>> rtpStreamPromises;+ // Get all rtp stream stats for the given selector. Then filter away any+ // codec stat not related to the selector, and assign codec ids to the+ // stream stats.+ if (sendSelected) {+ // TODO(bug 1616937): Use RTCRtpSender for these instead.+ rtpStreamPromises.AppendElements(GetSenderStats(transceiver));+ }+ if (recvSelected) { // Right now, returns two promises; one for RTP/RTCP stats, and // another for ICE stats.- promises.AppendElements(transceiver->Receiver()->GetStatsInternal());+ rtpStreamPromises.AppendElements(+ transceiver->Receiver()->GetStatsInternal()); }- }+ transceiverStatsPromises.AppendElement(+ std::make_tuple(transceiver.get(),+ RTCStatsPromise::All(GetMainThreadSerialEventTarget(),+ rtpStreamPromises)));+ }++ promises.AppendElement(TransceiverImpl::ApplyCodecStats(+ std::move(codecStats), std::move(transceiverStatsPromises))); // TODO(bug 1616937): We need to move this is RTCRtpSender, to make // getStats on those objects work properly. It might be worth optimizing@@ -2974,9 +3115,8 @@ ->Then( mThread, __func__, [report = std::move(report), idGen = mIdGenerator](- const nsTArray<UniquePtr<dom::RTCStatsCollection>>&- aStats) mutable {- idGen->RewriteIds(aStats, report.get());+ nsTArray<UniquePtr<dom::RTCStatsCollection>> aStats) mutable {+ idGen->RewriteIds(std::move(aStats), report.get()); return dom::RTCStatsReportPromise::CreateAndResolve( std::move(report), __func__); },
I'll analyze the code diff for security fixes following the specified format: 1. First vulnerability analysis: Vulnerability Existed: yes Direct Member Access Vulnerability [dom/media/webrtc/jsapi/PeerConnectionImpl.cpp] [Lines 669, 769, 906] [Old Code] switch (codec->mType) if (codec->mType == SdpMediaSection::kVideo && codec->mEnabled == false) __FUNCTION__, static_cast<unsigned>(codec->mType) [Fixed Code] switch (codec->Type()) if (codec->Type() == SdpMediaSection::kVideo && !codec->mEnabled) __FUNCTION__, static_cast<unsigned>(codec->Type()) Details: The changes replace direct member access (mType) with method calls (Type()), which is generally safer as it allows for validation and encapsulation. 2. Second vulnerability analysis: Vulnerability Existed: yes Null Pointer Dereference Vulnerability [dom/media/webrtc/jsapi/PeerConnectionImpl.cpp] [Lines 2662-2668] [Old Code] (No null check before accessing audioStats) [Fixed Code] if (audioStats->packets_sent == 0) { return; } Details: Added check for packets_sent to prevent potential null pointer dereference when no packets have been sent. 3. Third vulnerability analysis: Vulnerability Existed: yes Null Pointer Dereference Vulnerability [dom/media/webrtc/jsapi/PeerConnectionImpl.cpp] [Lines 2752-2758] [Old Code] if (streamStats && streamStats->report_block_data) [Fixed Code] if (!streamStats || streamStats->rtp_stats.first_packet_time_ms == -1) { return; } if (streamStats->report_block_data) Details: Added more comprehensive null checks for streamStats and additional validation for first_packet_time_ms. 4. Fourth vulnerability analysis: Vulnerability Existed: not sure Potential Information Leak Vulnerability [dom/media/webrtc/jsapi/PeerConnectionImpl.cpp] [Lines 2560-2561] [Old Code] GetSenderStats(const RefPtr<MediaPipelineTransmit>& aPipeline) [Fixed Code] GetSenderStats(const RefPtr<TransceiverImpl>& aTransceiver) Details: The change in parameter type might be related to better encapsulation and information hiding, but it's not clear if this was fixing a specific security issue. 5. Fifth vulnerability analysis: Vulnerability Existed: not sure Potential Race Condition Vulnerability [dom/media/webrtc/jsapi/PeerConnectionImpl.cpp] [Lines 3115-3118] [Old Code] const nsTArray<UniquePtr<dom::RTCStatsCollection>>& aStats [Fixed Code] nsTArray<UniquePtr<dom::RTCStatsCollection>> aStats Details: The change from const reference to move semantics might be related to thread safety, but the exact security implication is unclear. Note: The diff also includes significant additions for codec stats handling (GetCodecStats function), but I don't see obvious security vulnerabilities in that new code. The changes appear to be more about functionality improvements 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/devtools/client/debugger/src/utils/editor/token-events.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/debugger/src/utils/editor/token-events.js@@ -3,7 +3,6 @@ * file, You can obtain one at <http://mozilla.org/MPL/2.0/>. */ import { getTokenLocation } from ".";-import { isEqual } from "lodash"; function isInvalidTarget(target) { if (!target || !target.innerText) {@@ -78,7 +77,10 @@ const tokenPos = getTokenLocation(codeMirror, target);- if (!isEqual(prevTokenPos, tokenPos)) {+ if (+ prevTokenPos?.line !== tokenPos?.line ||+ prevTokenPos?.column !== tokenPos?.column+ ) { addMouseLeave(target); dispatch(codeMirror, "tokenenter", {
Here's the analysis of the provided code diff: 1. Vulnerability Existed: not sure [Potential Performance Improvement] [devtools/client/debugger/src/utils/editor/token-events.js] [Lines 3, 78-83] [Old Code] import { isEqual } from "lodash"; ... if (!isEqual(prevTokenPos, tokenPos)) { [Fixed Code] (lodash import removed) ... if ( prevTokenPos?.line !== tokenPos?.line || prevTokenPos?.column !== tokenPos?.column ) { Notes: While not a security vulnerability, this change removes a lodash dependency and replaces a deep equality check with a more specific comparison of line and column properties. This could potentially improve performance by avoiding unnecessary deep comparisons. 2. Vulnerability Existed: no [No Security Vulnerability Found] [devtools/client/debugger/src/utils/editor/token-events.js] [Entire diff] [No specific security-related changes found in the diff] The main change appears to be a refactoring that replaces lodash's isEqual with direct property comparisons. This doesn't appear to address any security vulnerability but rather improves code efficiency and reduces dependencies. The functionality remains the same while being more explicit about what properties are being compared.
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/AudioSegment.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/media/AudioSegment.h@@ -336,9 +336,11 @@ bufferPtrs.SetLength(channels); uint32_t inFrames = c.mDuration; // Round up to allocate; the last frame may not be used.- NS_ASSERTION((UINT32_MAX - aInRate + 1) / c.mDuration >= aOutRate,+ NS_ASSERTION((UINT64_MAX - aInRate + 1) / c.mDuration >= aOutRate, "Dropping samples");- uint32_t outSize = (c.mDuration * aOutRate + aInRate - 1) / aInRate;+ uint32_t outSize =+ (static_cast<uint64_t>(c.mDuration) * aOutRate + aInRate - 1) /+ aInRate; for (uint32_t i = 0; i < channels; i++) { T* out = output[i].AppendElements(outSize); uint32_t outFrames = outSize;@@ -445,6 +447,13 @@ return; }+ if (!mChunks.IsEmpty() &&+ mChunks.LastElement().CanCombineWithFollowing(aChunk)) {+ mChunks.LastElement().mDuration += aChunk.GetDuration();+ mDuration += aChunk.GetDuration();+ return;+ }+ chunk = AppendChunk(aChunk.mDuration); } void ApplyVolume(float aVolume);
Analyzing the provided code diff for security fixes: 1. Vulnerability Existed: yes Integer Overflow Vulnerability [File] dom/media/AudioSegment.h [Lines] 336-339 [Old Code] ```cpp NS_ASSERTION((UINT32_MAX - aInRate + 1) / c.mDuration >= aOutRate, "Dropping samples"); uint32_t outSize = (c.mDuration * aOutRate + aInRate - 1) / aInRate; ``` [Fixed Code] ```cpp NS_ASSERTION((UINT64_MAX - aInRate + 1) / c.mDuration >= aOutRate, "Dropping samples"); uint32_t outSize = (static_cast<uint64_t>(c.mDuration) * aOutRate + aInRate - 1) / aInRate; ``` Additional Details: The fix changes from UINT32_MAX to UINT64_MAX and adds a static_cast to uint64_t for the calculation, preventing potential integer overflow in the arithmetic operations. 2. Vulnerability Existed: not sure [No specific vulnerability name] [File] dom/media/AudioSegment.h [Lines] 447-453 [Old Code] ```cpp // No equivalent code existed before ``` [Fixed Code] ```cpp if (!mChunks.IsEmpty() && mChunks.LastElement().CanCombineWithFollowing(aChunk)) { mChunks.LastElement().mDuration += aChunk.GetDuration(); mDuration += aChunk.GetDuration(); return; } ``` Additional Details: This appears to be a logic improvement rather than a security fix, adding chunk combination capability. No obvious security vulnerability is addressed here. The first change clearly addresses an integer overflow vulnerability by using wider integer types and safer arithmetic. The second change appears to be a functional improvement without clear 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/testing/web-platform/tests/css/css-values/calc-min-width-block-intrinsic-1-ref.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-values/calc-min-width-block-intrinsic-1-ref.html@@ -3,7 +3,6 @@ <head> <title>CSS Reference: intrinsic width of min-width: calc() on blocks</title> <link rel="author" title="L. David Baron" href="https://dbaron.org/">- <meta name="flags" content=""> <style type="text/css"> body > div { margin: 0 0 1px 0; background: blue; color: white; height: 5px }
Analyzing the provided code diff, here's the security analysis: Vulnerability Existed: no [No specific vulnerability found] [testing/web-platform/tests/css/css-values/calc-min-width-block-intrinsic-1-ref.html] [Lines 3-6] [Old Code] <meta name="flags" content=""> [Fixed Code] [Removed line] Additional Details: - The change simply removes an empty meta tag with a "flags" attribute that wasn't serving any security-relevant purpose - No security vulnerability is being fixed here - this appears to be a minor cleanup of test metadata - The "flags" meta tag is typically used for test configuration in web platform tests and doesn't pose security risks when empty No other vulnerabilities or suspicious changes were detected in this diff. The modification appears to be a benign test file cleanup 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.