Shared security patch analysis results
AI Used: DEEPSEEK deepseek-chat--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/pin-project/src/lib.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/pin-project/src/lib.rs@@ -42,7 +42,7 @@ attr(deny(warnings, rust_2018_idioms, single_use_lifetimes), allow(dead_code)) ))] #![warn(missing_docs, rust_2018_idioms, single_use_lifetimes, unreachable_pub)]-#![warn(clippy::all, clippy::default_trait_access)]+#![warn(clippy::default_trait_access, clippy::wildcard_imports)] // mem::take and #[non_exhaustive] requires Rust 1.40 #![allow(clippy::mem_replace_with_default, clippy::manual_non_exhaustive)] #![allow(clippy::needless_doctest_main)]
Based on the provided diff, I'll analyze it for security fixes: Vulnerability Existed: not sure [Linter Configuration Change] [third_party/rust/pin-project/src/lib.rs] [Lines 42] [Old Code] #![warn(clippy::all, clippy::default_trait_access)] [Fixed Code] #![warn(clippy::default_trait_access, clippy::wildcard_imports)] Additional Details: - The change modifies the linter configuration by removing `clippy::all` and adding `clippy::wildcard_imports` - While this isn't directly a security vulnerability fix, it could be related to improving code quality or preventing potential issues - Wildcard imports can sometimes lead to naming conflicts or unintended behavior, but this is more of a code style/quality issue than a security vulnerability - The removal of `clippy::all` might indicate a more targeted approach to linting No clear security vulnerability is being fixed here, but the changes could be part of a broader security hardening effort by being more specific about which lints to enable.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/browser/components/newtab/test/unit/content-src/components/DiscoveryStreamComponents/CardGrid.test.jsx+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/components/newtab/test/unit/content-src/components/DiscoveryStreamComponents/CardGrid.test.jsx@@ -42,13 +42,22 @@ assert.ok(wrapper.find(".ds-card-grid-hero").exists()); });- it("should add compact classname to card grid", () => {+ it("should add 4 card classname to card grid", () => { wrapper.setProps({- compact: true,+ fourCardLayout: true, data: { recommendations: [{}, {}] }, });- assert.ok(wrapper.find(".ds-card-grid-compact-variant").exists());+ assert.ok(wrapper.find(".ds-card-grid-four-card-variant").exists());+ });++ it("should add no description classname to card grid", () => {+ wrapper.setProps({+ hideCardBackground: true,+ data: { recommendations: [{}, {}] },+ });++ assert.ok(wrapper.find(".ds-card-grid-hide-background").exists()); }); it("should render sub header in the middle of the card grid for both regular and compact", () => {@@ -87,7 +96,7 @@ wrapper.setProps({ dispatch, compact: true,- loadMoreEnabled: true,+ loadMore: true, lastCardMessageEnabled: true, loadMoreThreshold: 2, data: {@@ -114,7 +123,7 @@ it("should only show load more with more than threshold number of stories", () => { wrapper.setProps({- loadMoreEnabled: true,+ loadMore: true, loadMoreThreshold: 2, data: { recommendations: [{}, {}, {}],
After analyzing the provided code diff, I don't find any security vulnerabilities. The changes appear to be focused on test cases and class name updates for UI components rather than security fixes. Here's the analysis: 1. Vulnerability Existed: no No security vulnerability found [File] [Lines 42-58] [Old Code] - Test for compact classname [Fixed Code] - Tests for four-card layout and hide background features 2. Vulnerability Existed: no No security vulnerability found [File] [Lines 87-114] [Old Code] - Test using loadMoreEnabled prop [Fixed Code] - Test using loadMore prop 3. Vulnerability Existed: no No security vulnerability found [File] [Lines 114-123] [Old Code] - Test using loadMoreEnabled prop [Fixed Code] - Test using loadMore prop The changes are primarily: 1. Renaming test cases and class names from "compact" to "four-card" variant 2. Adding a new test case for hiding card background 3. Changing property names from "loadMoreEnabled" to "loadMore" 4. No security-related changes were detected in this test file diff
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/gfx/layers/ipc/CompositorBridgeChild.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/gfx/layers/ipc/CompositorBridgeChild.h@@ -29,11 +29,6 @@ class BrowserChild; } // namespace dom-namespace webgpu {-class PWebGPUChild;-class WebGPUChild;-} // namespace webgpu- namespace widget { class CompositorWidget; } // namespace widget@@ -102,18 +97,14 @@ mozilla::ipc::IPCResult RecvParentAsyncMessages( nsTArray<AsyncParentMessageData>&& aMessages);- PTextureChild* CreateTexture(const SurfaceDescriptor& aSharedData,- ReadLockDescriptor&& aReadLock,- LayersBackend aLayersBackend,- TextureFlags aFlags, uint64_t aSerial,- wr::MaybeExternalImageId& aExternalImageId,- nsISerialEventTarget* aTarget) override;+ PTextureChild* CreateTexture(+ const SurfaceDescriptor& aSharedData, ReadLockDescriptor&& aReadLock,+ LayersBackend aLayersBackend, TextureFlags aFlags, uint64_t aSerial,+ wr::MaybeExternalImageId& aExternalImageId) override; already_AddRefed<CanvasChild> GetCanvasChild() final; void EndCanvasTransaction();-- RefPtr<webgpu::WebGPUChild> GetWebGPUChild(); // Beware that these methods don't override their super-class equivalent // (which are not virtual), they just overload them. All of these Send*@@ -184,9 +175,6 @@ const WindowKind&); bool DeallocPWebRenderBridgeChild(PWebRenderBridgeChild* aActor);- webgpu::PWebGPUChild* AllocPWebGPUChild();- bool DeallocPWebGPUChild(webgpu::PWebGPUChild* aActor);- wr::MaybeExternalImageId GetNextExternalImageId() override; wr::PipelineId GetNextPipelineId();@@ -235,7 +223,7 @@ /** * Transaction id of ShadowLayerForwarder.- * It is incrementaed by UpdateFwdTransactionId() in each BeginTransaction()+ * It is incremented by UpdateFwdTransactionId() in each BeginTransaction() * call. */ uint64_t mFwdTransactionId;@@ -259,27 +247,7 @@ // is only accessed on the main thread. nsTArray<RefPtr<TextureClient>> mTextureClientsForAsyncPaint;- // Off-Main-Thread Painting state. This covers access to the OMTP-related- // state below.- Monitor mPaintLock;-- // Contains the number of asynchronous paints that were queued since the- // beginning of the last async transaction, and the time stamp of when- // that was- size_t mTotalAsyncPaints;- TimeStamp mAsyncTransactionBegin;-- // True if this CompositorBridge is currently delaying its messages until the- // paint thread completes. This is R/W on both the main and paint threads, and- // must be accessed within the paint lock.- bool mIsDelayingForAsyncPaints;-- uintptr_t mSlowFlushCount;- uintptr_t mTotalFlushCount;- RefPtr<CanvasChild> mCanvasChild;-- RefPtr<webgpu::WebGPUChild> mWebGPUChild; }; } // namespace layers
Analyzing the provided code diff, I'll identify potential security vulnerabilities. The changes primarily involve removing WebGPU-related code and some OMTP (Off-Main-Thread Painting) state management.
1. First potential issue:
Vulnerability Existed: not sure
[WebGPU Child Removal] [gfx/layers/ipc/CompositorBridgeChild.h] [Lines 29-33, 104, 177-178, 259]
[Old Code]
namespace webgpu {
class PWebGPUChild;
class WebGPUChild;
} // namespace webgpu
...
RefPtr<webgpu::WebGPUChild> GetWebGPUChild();
...
webgpu::PWebGPUChild* AllocPWebGPUChild();
bool DeallocPWebGPUChild(webgpu::PWebGPUChild* aActor);
...
RefPtr<webgpu::WebGPUChild> mWebGPUChild;
[Fixed Code]
[Removed entirely]
Additional Details: The removal of WebGPU-related code might indicate a security issue was addressed, but without more context about why these were removed, we can't be certain. This could be related to security hardening by removing unused or potentially vulnerable components.
2. Second potential issue:
Vulnerability Existed: not sure
[OMTP State Removal] [gfx/layers/ipc/CompositorBridgeChild.h] [Lines 259-273]
[Old Code]
Monitor mPaintLock;
size_t mTotalAsyncPaints;
TimeStamp mAsyncTransactionBegin;
bool mIsDelayingForAsyncPaints;
uintptr_t mSlowFlushCount;
uintptr_t mTotalFlushCount;
[Fixed Code]
[Removed entirely]
Additional Details: The removal of Off-Main-Thread Painting state management could indicate a security fix related to race conditions or synchronization issues, but without more context, we can't be certain.
3. Third potential issue:
Vulnerability Existed: not sure
[CreateTexture Parameter Change] [gfx/layers/ipc/CompositorBridgeChild.h] [Lines 102-107]
[Old Code]
PTextureChild* CreateTexture(const SurfaceDescriptor& aSharedData,
ReadLockDescriptor&& aReadLock,
LayersBackend aLayersBackend,
TextureFlags aFlags, uint64_t aSerial,
wr::MaybeExternalImageId& aExternalImageId,
nsISerialEventTarget* aTarget) override;
[Fixed Code]
PTextureChild* CreateTexture(
const SurfaceDescriptor& aSharedData, ReadLockDescriptor&& aReadLock,
LayersBackend aLayersBackend, TextureFlags aFlags, uint64_t aSerial,
wr::MaybeExternalImageId& aExternalImageId) override;
Additional Details: The removal of the nsISerialEventTarget* parameter might indicate a security fix related to improper event handling or potential race conditions, but without more context, we can't be certain.
Note: The diff also includes a typo fix ("incrementaed" to "incremented") which doesn't appear to be security-related. The changes appear to be primarily cleanup/refactoring, but could potentially address security issues that aren't immediately obvious from the diff alone.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/layout/generic/nsFontInflationData.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/layout/generic/nsFontInflationData.cpp@@ -352,8 +352,8 @@ // Don't just recurse down to the list control inside, since we // need to exclude the display frame. nscoord fontSize = kid->StyleFont()->mFont.size.ToAppUnits();- int32_t charCount = CharCountOfLargestOption(- static_cast<nsComboboxControlFrame*>(kid)->GetDropDown());+ int32_t charCount = static_cast<nsComboboxControlFrame*>(kid)+ ->CharCountOfLargestOptionForInflation(); mTextAmount += charCount * fontSize; } else if (fType == LayoutFrameType::ListControl) { // See textInputFrame above (with s/amount of text/selected option/).
Analyzing the provided code diff for security fixes:
1. Vulnerability Existed: not sure
[Potential Information Exposure] [layout/generic/nsFontInflationData.cpp] [Lines 352-356]
[Old Code]
```cpp
int32_t charCount = CharCountOfLargestOption(
static_cast<nsComboboxControlFrame*>(kid)->GetDropDown());
```
[Fixed Code]
```cpp
int32_t charCount = static_cast<nsComboboxControlFrame*>(kid)
->CharCountOfLargestOptionForInflation();
```
Additional Details: The change moves the character counting logic into a dedicated method rather than using a direct function call on the dropdown. This could potentially address information exposure or improper access control, but without more context about the implementation details of these methods, we can't be certain.
2. Vulnerability Existed: not sure
[Potential Improper Access Control] [layout/generic/nsFontInflationData.cpp] [Same lines as above]
[Old Code]
Same as above
[Fixed Code]
Same as above
Additional Details: The change might be related to better encapsulation of frame operations, which could potentially prevent improper access to frame data. However, without knowing the security implications of the original vs new implementation, we can't confirm this is a security fix.
Note: The diff appears to be a refactoring change rather than an explicit security fix. The modifications involve how character counting is performed for font inflation calculations, but there's no clear evidence of a specific vulnerability being addressed. The changes might be related to code organization or performance improvements 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/dom/ipc/WindowGlobalChild.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/ipc/WindowGlobalChild.h@@ -187,7 +187,8 @@ const dom::sessionstore::DocShellRestoreState& aState, RestoreDocShellStateResolver&& aResolve);- mozilla::ipc::IPCResult RecvRestoreTabContent(+ // TODO: Use MOZ_CAN_RUN_SCRIPT when it gains IPDL support (bug 1539864)+ MOZ_CAN_RUN_SCRIPT_BOUNDARY mozilla::ipc::IPCResult RecvRestoreTabContent( dom::SessionStoreRestoreData* aData, RestoreTabContentResolver&& aResolve);
Here's the analysis of the provided code diff: Vulnerability Existed: not sure Potential Race Condition or Unsafe Execution [File] dom/ipc/WindowGlobalChild.h [Lines] 187-190 [Old Code] `mozilla::ipc::IPCResult RecvRestoreTabContent(` [Fixed Code] `MOZ_CAN_RUN_SCRIPT_BOUNDARY mozilla::ipc::IPCResult RecvRestoreTabContent(` Additional Details: 1. The change adds `MOZ_CAN_RUN_SCRIPT_BOUNDARY` annotation to indicate this IPDL method can run script. 2. While not a direct security fix, this change helps prevent potential race conditions or unsafe script execution by properly annotating the method's capabilities. 3. The TODO comment suggests this is preparatory work for future IPDL support of MOZ_CAN_RUN_SCRIPT (bug 1539864). 4. Without more context about the implementation, we can't be certain if this was fixing an actual vulnerability or just improving safety annotations. Note: This doesn't appear to fix a specific named vulnerability, but rather improves the code's safety characteristics regarding script execution in IPC handlers.
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/network-events.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/server/actors/resources/network-events.js@@ -6,6 +6,9 @@ const Services = require("Services"); const { Pool } = require("devtools/shared/protocol/Pool");+const {+ isWindowGlobalPartOfContext,+} = require("devtools/server/actors/watcher/browsing-context-helpers.jsm"); loader.lazyRequireGetter( this,@@ -154,19 +157,13 @@ if (this.persist || this.watcherActor.sessionContext.type == "all") { return; }- // If the watcher is bound to one browser element (i.e. a tab), ignore- // windowGlobals related to other browser elements+ // Only process WindowGlobals which are related to the debugged scope. if (- this.watcherActor.sessionContext.type == "browser-element" &&- windowGlobal.browsingContext.browserId !=- this.watcherActor.sessionContext.browserId+ !isWindowGlobalPartOfContext(+ windowGlobal,+ this.watcherActor.sessionContext+ ) ) {- return;- }- // Also ignore the initial document as:- // - it shouldn't spawn/store any request?- // - it would clear the navigation request too early- if (windowGlobal.isInitialDocument) { return; } const { innerWindowId } = windowGlobal;
Here's the analysis of the provided code diff:
1. Vulnerability Existed: not sure
[Potential Cross-Origin Information Leak] [devtools/server/actors/resources/network-events.js] [Lines 154-167]
[Old Code]
if (
this.watcherActor.sessionContext.type == "browser-element" &&
windowGlobal.browsingContext.browserId !=
this.watcherActor.sessionContext.browserId
) {
return;
}
// Also ignore the initial document as:
// - it shouldn't spawn/store any request?
// - it would clear the navigation request too early
if (windowGlobal.isInitialDocument) {
return;
}
[Fixed Code]
if (
!isWindowGlobalPartOfContext(
windowGlobal,
this.watcherActor.sessionContext
)
) {
return;
}
Additional Details:
- The change replaces a direct browserId comparison with a more comprehensive context check using `isWindowGlobalPartOfContext`
- This might prevent potential cross-origin information leaks by more accurately determining which window globals should be processed
- The removal of the `isInitialDocument` check suggests this was either unnecessary or potentially causing issues with navigation tracking
- Without seeing the implementation of `isWindowGlobalPartOfContext`, it's hard to determine if this was fixing a specific known vulnerability or just improving security generally
Note: The change appears to be a security improvement, but without more context about the threat model and the implementation details of `isWindowGlobalPartOfContext`, I can't definitively identify a specific vulnerability being fixed.
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/unicode-normalization/src/decompose.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/unicode-normalization/src/decompose.rs@@ -7,25 +7,7 @@ // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms.- use std::fmt::{self, Write};--// Helper functions used for Unicode normalization-fn canonical_sort(comb: &mut [(char, u8)]) {- let len = comb.len();- for i in 0..len {- let mut swapped = false;- for j in 1..len-i {- let class_a = comb[j-1].1;- let class_b = comb[j].1;- if class_a != 0 && class_b != 0 && class_a > class_b {- comb.swap(j-1, j);- swapped = true;- }- }- if !swapped { break; }- }-} #[derive(Clone)] enum DecompositionType {@@ -38,27 +20,71 @@ pub struct Decompositions<I> { kind: DecompositionType, iter: I,- buffer: Vec<(char, u8)>,- sorted: bool+ done: bool,++ // This buffer stores pairs of (canonical combining class, character),+ // pushed onto the end in text order.+ //+ // It's split into two contiguous regions by the `ready` offset. The first+ // `ready` pairs are sorted and ready to emit on demand. The "pending"+ // suffix afterwards still needs more characters for us to be able to sort+ // in canonical order and is not safe to emit.+ buffer: Vec<(u8, char)>,+ ready: usize, } #[inline] pub fn new_canonical<I: Iterator<Item=char>>(iter: I) -> Decompositions<I> { Decompositions {+ kind: self::DecompositionType::Canonical, iter: iter,+ done: false, buffer: Vec::new(),- sorted: false,- kind: self::DecompositionType::Canonical,+ ready: 0, } } #[inline] pub fn new_compatible<I: Iterator<Item=char>>(iter: I) -> Decompositions<I> { Decompositions {+ kind: self::DecompositionType::Compatible, iter: iter,+ done: false, buffer: Vec::new(),- sorted: false,- kind: self::DecompositionType::Compatible,+ ready: 0,+ }+}++impl<I> Decompositions<I> {+ #[inline]+ fn push_back(&mut self, ch: char) {+ let class = super::char::canonical_combining_class(ch);+ if class == 0 {+ self.sort_pending();+ }+ self.buffer.push((class, ch));+ }++ #[inline]+ fn sort_pending(&mut self) {+ if self.ready == 0 && self.buffer.is_empty() {+ return;+ }++ // NB: `sort_by_key` is stable, so it will preserve the original text's+ // order within a combining class.+ self.buffer[self.ready..].sort_by_key(|k| k.0);+ self.ready = self.buffer.len();+ }++ #[inline]+ fn pop_front(&mut self) -> Option<char> {+ if self.ready == 0 {+ None+ } else {+ self.ready -= 1;+ Some(self.buffer.remove(0).1)+ } } }@@ -67,66 +93,21 @@ #[inline] fn next(&mut self) -> Option<char> {- use self::DecompositionType::*;-- match self.buffer.first() {- Some(&(c, 0)) => {- self.sorted = false;- self.buffer.remove(0);- return Some(c);- }- Some(&(c, _)) if self.sorted => {- self.buffer.remove(0);- return Some(c);- }- _ => self.sorted = false- }-- if !self.sorted {- for ch in self.iter.by_ref() {- let buffer = &mut self.buffer;- let sorted = &mut self.sorted;- {- let callback = |d| {- let class =- super::char::canonical_combining_class(d);- if class == 0 && !*sorted {- canonical_sort(buffer);- *sorted = true;- }- buffer.push((d, class));- };- match self.kind {- Canonical => {- super::char::decompose_canonical(ch, callback)- }- Compatible => {- super::char::decompose_compatible(ch, callback)- }- }- }- if *sorted {- break- }+ while self.ready == 0 && !self.done {+ match (self.iter.next(), &self.kind) {+ (Some(ch), &DecompositionType::Canonical) => {+ super::char::decompose_canonical(ch, |d| self.push_back(d));+ },+ (Some(ch), &DecompositionType::Compatible) => {+ super::char::decompose_compatible(ch, |d| self.push_back(d));+ },+ (None, _) => {+ self.sort_pending();+ self.done = true;+ }, } }-- if !self.sorted {- canonical_sort(&mut self.buffer);- self.sorted = true;- }-- if self.buffer.is_empty() {- None- } else {- match self.buffer.remove(0) {- (c, 0) => {- self.sorted = false;- Some(c)- }- (c, _) => Some(c),- }- }+ self.pop_front() } fn size_hint(&self) -> (usize, Option<usize>) {
Analyzing the provided code diff for security fixes:
1. Vulnerability Existed: not sure
Potential Buffer Handling Issue [third_party/rust/unicode-normalization/src/decompose.rs] [Lines modified]
Old Code:
```rust
fn canonical_sort(comb: &mut [(char, u8)]) {
let len = comb.len();
for i in 0..len {
let mut swapped = false;
for j in 1..len-i {
let class_a = comb[j-1].1;
let class_b = comb[j].1;
if class_a != 0 && class_b != 0 && class_a > class_b {
comb.swap(j-1, j);
swapped = true;
}
}
if !swapped { break; }
}
}
```
Fixed Code:
```rust
fn sort_pending(&mut self) {
if self.ready == 0 && self.buffer.is_empty() {
return;
}
self.buffer[self.ready..].sort_by_key(|k| k.0);
self.ready = self.buffer.len();
}
```
2. Vulnerability Existed: not sure
Potential Data Structure Consistency Issue [third_party/rust/unicode-normalization/src/decompose.rs] [Lines modified]
Old Code:
```rust
pub struct Decompositions<I> {
kind: DecompositionType,
iter: I,
buffer: Vec<(char, u8)>,
sorted: bool
}
```
Fixed Code:
```rust
pub struct Decompositions<I> {
kind: DecompositionType,
iter: I,
done: bool,
buffer: Vec<(u8, char)>,
ready: usize
}
```
The changes appear to be primarily about improving the implementation of Unicode normalization rather than fixing specific security vulnerabilities. The modifications:
1. Replace a custom bubble sort implementation with Rust's built-in stable sort
2. Restructure the data handling to be more efficient and maintain better state tracking
3. Change the tuple order in the buffer from (char, u8) to (u8, char) to better match the sorting needs
While these changes improve code quality and potentially performance, I couldn't identify any clear security vulnerabilities that were fixed. The changes seem more focused on correctness and efficiency of Unicode normalization rather than addressing security flaws.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.invalid.css-color-4-rgb-3.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.invalid.css-color-4-rgb-3.worker.js@@ -13,14 +13,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#0f0'; try { ctx.fillStyle = 'rgb(255, 0 0)'; } catch (e) { } // this shouldn't throw, but it shouldn't matter here if it does ctx.fillRect(0, 0, 100, 50);-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255"); t.done(); });
Based on the provided diff, I'll analyze it for security vulnerabilities:
1. Vulnerability Existed: no
No specific vulnerability found [File] [Lines 13-14, 20]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes appear to be purely variable renaming (from 'offscreenCanvas' to 'canvas') and don't indicate any security fixes. The functionality remains the same, and there's no indication of any security vulnerability being addressed in this change. The test still performs the same canvas operations and assertions.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/css-pseudo/active-selection-012.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-pseudo/active-selection-012.html@@ -9,7 +9,6 @@ <link rel="help" href="https://www.w3.org/TR/css-pseudo-4/#highlight-styling"> <link rel="match" href="reference/active-selection-012-ref.html">- <meta content="" name="flags"> <link rel="stylesheet" href="support/highlights.css"> <style>
Based on the provided code diff, here's the analysis: Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/css/css-pseudo/active-selection-012.html [Lines] 9 [Old Code] `<meta content="" name="flags">` [Fixed Code] (Line removed) Additional Details: The change simply removes an empty meta tag with a "flags" attribute. This doesn't appear to be a security fix but rather a cleanup of unnecessary markup. The "flags" meta tag isn't associated with any known security vulnerabilities in this context, and its removal doesn't indicate any security improvement. The change is more likely related to test maintenance or code 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/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.attributes.shadowOffset.initial.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.attributes.shadowOffset.initial.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'); _assertSame(ctx.shadowOffsetX, 0, "ctx.shadowOffsetX", "0"); _assertSame(ctx.shadowOffsetY, 0, "ctx.shadowOffsetY", "0");
After analyzing the provided code diff, here's the security assessment:
Vulnerability Existed: no
[Variable Renaming] [testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.attributes.shadowOffset.initial.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:
- This appears to be a simple variable renaming change from 'offscreenCanvas' to 'canvas'
- No security vulnerability is being fixed here
- The change seems to be for code consistency or readability purposes
- The functionality remains exactly the same, just with a different variable name
- No security-related properties or methods are being modified in this change
There are no other changes in the diff to analyze for potential 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/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp@@ -13,11 +13,18 @@ #include "VideoUtils.h" #include "VPXDecoder.h" #include "mozilla/layers/KnowsCompositor.h"+#if defined(MOZ_AV1) && defined(FFVPX_VERSION) && defined(MOZ_WAYLAND)+# include "AOMDecoder.h"+#endif+#if LIBAVCODEC_VERSION_MAJOR >= 57+# include "mozilla/layers/TextureClient.h"+#endif #ifdef MOZ_WAYLAND_USE_VAAPI # include "H264.h" # include "mozilla/layers/DMABUFSurfaceImage.h" # include "mozilla/widget/DMABufLibWrapper.h" # include "FFmpegVideoFramePool.h"+# include "va/va.h" #endif #include "libavutil/pixfmt.h"@@ -33,7 +40,6 @@ # define AV_PIX_FMT_NONE PIX_FMT_NONE #endif #include "mozilla/PodOperations.h"-#include "mozilla/ScopeExit.h" #include "mozilla/StaticPrefs_media.h" #include "mozilla/TaskQueue.h" #include "nsThreadUtils.h"@@ -50,10 +56,18 @@ // Use some extra HW frames for potential rendering lags. #define EXTRA_HW_FRAMES 6+#if LIBAVCODEC_VERSION_MAJOR >= 57 && LIBAVUTIL_VERSION_MAJOR >= 56+# define CUSTOMIZED_BUFFER_ALLOCATION 1+#endif+ typedef mozilla::layers::Image Image; typedef mozilla::layers::PlanarYCbCrImage PlanarYCbCrImage; namespace mozilla {++#ifdef MOZ_WAYLAND_USE_VAAPI+nsTArray<AVCodecID> FFmpegVideoDecoder<LIBAV_VER>::mAcceleratedFormats;+#endif using media::TimeUnit;@@ -128,7 +142,11 @@ } AVCodec* FFmpegVideoDecoder<LIBAV_VER>::FindVAAPICodec() {- AVCodec* decoder = mLib->avcodec_find_decoder(mCodecID);+ AVCodec* decoder = FindHardwareAVCodec(mLib, mCodecID);+ if (!decoder) {+ FFMPEG_LOG(" We're missing hardware accelerated decoder");+ return nullptr;+ } for (int i = 0;; i++) { const AVCodecHWConfig* config = mLib->avcodec_get_hw_config(decoder, i); if (!config) {@@ -140,7 +158,7 @@ } }- FFMPEG_LOG("Decoder does not support VAAPI device type");+ FFMPEG_LOG(" HW Decoder does not support VAAPI device type"); return nullptr; }@@ -171,6 +189,7 @@ bool FFmpegVideoDecoder<LIBAV_VER>::CreateVAAPIDeviceContext() { mVAAPIDeviceContext = mLib->av_hwdevice_ctx_alloc(AV_HWDEVICE_TYPE_VAAPI); if (!mVAAPIDeviceContext) {+ FFMPEG_LOG(" av_hwdevice_ctx_alloc failed."); return false; }@@ -180,24 +199,10 @@ AVHWDeviceContext* hwctx = (AVHWDeviceContext*)mVAAPIDeviceContext->data; AVVAAPIDeviceContext* vactx = (AVVAAPIDeviceContext*)hwctx->hwctx;- if (StaticPrefs::media_ffmpeg_vaapi_drm_display_enabled()) {- mDisplay =- mLib->vaGetDisplayDRM(widget::GetDMABufDevice()->GetGbmDeviceFd());- if (!mDisplay) {- FFMPEG_LOG("Can't get DRM VA-API display.");- return false;- }- } else {- wl_display* display = widget::WaylandDisplayGetWLDisplay();- if (!display) {- FFMPEG_LOG("Can't get default wayland display.");- return false;- }- mDisplay = mLib->vaGetDisplayWl(display);- if (!mDisplay) {- FFMPEG_LOG("Can't get Wayland VA-API display.");- return false;- }+ mDisplay = mLib->vaGetDisplayDRM(widget::GetDMABufDevice()->GetDRMFd());+ if (!mDisplay) {+ FFMPEG_LOG(" Can't get DRM VA-API display.");+ return false; } hwctx->user_opaque = new VAAPIDisplayHolder<LIBAV_VER>(mLib, mDisplay);@@ -206,11 +211,13 @@ int major, minor; int status = mLib->vaInitialize(mDisplay, &major, &minor); if (status != VA_STATUS_SUCCESS) {+ FFMPEG_LOG(" vaInitialize failed."); return false; } vactx->display = mDisplay; if (mLib->av_hwdevice_ctx_init(mVAAPIDeviceContext) < 0) {+ FFMPEG_LOG(" av_hwdevice_ctx_init failed."); return false; }@@ -222,30 +229,53 @@ MediaResult FFmpegVideoDecoder<LIBAV_VER>::InitVAAPIDecoder() { FFMPEG_LOG("Initialising VA-API FFmpeg decoder");+ StaticMutexAutoLock mon(sMutex);++ // mAcceleratedFormats is already configured so check supported+ // formats before we do anything.+ if (mAcceleratedFormats.Length()) {+ if (!IsFormatAccelerated(mCodecID)) {+ FFMPEG_LOG(" Format %s is not accelerated",+ mLib->avcodec_get_name(mCodecID));+ return NS_ERROR_NOT_AVAILABLE;+ } else {+ FFMPEG_LOG(" Format %s is accelerated",+ mLib->avcodec_get_name(mCodecID));+ }+ }+ if (!mLib->IsVAAPIAvailable()) {- FFMPEG_LOG("libva library or symbols are missing.");+ FFMPEG_LOG(" libva library or symbols are missing."); return NS_ERROR_NOT_AVAILABLE; } AVCodec* codec = FindVAAPICodec(); if (!codec) {- FFMPEG_LOG("Couldn't find ffmpeg VA-API decoder");+ FFMPEG_LOG(" couldn't find ffmpeg VA-API decoder"); return NS_ERROR_DOM_MEDIA_FATAL_ERR; }-- StaticMutexAutoLock mon(sMutex);+ FFMPEG_LOG(" codec %s : %s", codec->name, codec->long_name); if (!(mCodecContext = mLib->avcodec_alloc_context3(codec))) {- FFMPEG_LOG("Couldn't init VA-API ffmpeg context");+ FFMPEG_LOG(" couldn't init VA-API ffmpeg context"); return NS_ERROR_OUT_OF_MEMORY; } mCodecContext->opaque = this; InitVAAPICodecContext();++ auto releaseVAAPIdecoder = MakeScopeExit([&] {+ if (mVAAPIDeviceContext) {+ mLib->av_buffer_unref(&mVAAPIDeviceContext);+ }+ if (mCodecContext) {+ mLib->av_freep(&mCodecContext);+ }+ }); if (!CreateVAAPIDeviceContext()) { mLib->av_freep(&mCodecContext);- FFMPEG_LOG("Failed to create VA-API device context");+ FFMPEG_LOG(" Failed to create VA-API device context"); return NS_ERROR_DOM_MEDIA_FATAL_ERR; }@@ -259,11 +289,21 @@ if (mLib->avcodec_open2(mCodecContext, codec, nullptr) < 0) { mLib->av_buffer_unref(&mVAAPIDeviceContext); mLib->av_freep(&mCodecContext);- FFMPEG_LOG("Couldn't initialise VA-API decoder");+ FFMPEG_LOG(" Couldn't initialise VA-API decoder"); return NS_ERROR_DOM_MEDIA_FATAL_ERR; }- FFMPEG_LOG("VA-API FFmpeg init successful");+ if (mAcceleratedFormats.IsEmpty()) {+ mAcceleratedFormats = GetAcceleratedFormats();+ if (!IsFormatAccelerated(mCodecID)) {+ FFMPEG_LOG(" Format %s is not accelerated",+ mLib->avcodec_get_name(mCodecID));+ return NS_ERROR_NOT_AVAILABLE;+ }+ }++ FFMPEG_LOG(" VA-API FFmpeg init successful");+ releaseVAAPIdecoder.release(); return NS_OK; }@@ -320,13 +360,6 @@ mEnableHardwareDecoding = false; FFMPEG_LOG("VA-API is disabled by pref."); }-- if (mEnableHardwareDecoding) {- mUseDMABufSurfaces = widget::GetDMABufDevice()->IsDMABufVideoEnabled();- if (!mUseDMABufSurfaces) {- FFMPEG_LOG("SW encoding to DMABuf textures is disabled by system/pref.");- }- } } #endif@@ -339,7 +372,6 @@ mVAAPIDeviceContext(nullptr), mEnableHardwareDecoding(!aDisableHardwareDecoding), mDisplay(nullptr),- mUseDMABufSurfaces(false), #endif mImageAllocator(aAllocator), mImageContainer(aImageContainer),@@ -351,9 +383,13 @@ mExtraData->AppendElements(*aConfig.mExtraData); #ifdef MOZ_WAYLAND_USE_VAAPI InitHWDecodingPrefs();- if (mUseDMABufSurfaces || mEnableHardwareDecoding) {- mVideoFramePool = MakeUnique<VideoFramePool>(mEnableHardwareDecoding);- }+#endif+}++FFmpegVideoDecoder<LIBAV_VER>::~FFmpegVideoDecoder() {+#ifdef CUSTOMIZED_BUFFER_ALLOCATION+ MOZ_DIAGNOSTIC_ASSERT(mAllocatedImages.IsEmpty(),+ "Should release all shmem buffers before destroy!"); #endif }@@ -366,6 +402,7 @@ if (NS_SUCCEEDED(rv)) { return InitPromise::CreateAndResolve(TrackInfo::kVideoTrack, __func__); }+ mEnableHardwareDecoding = false; } #endif@@ -376,6 +413,296 @@ return InitPromise::CreateAndReject(rv, __func__); }++#ifdef CUSTOMIZED_BUFFER_ALLOCATION+static int GetVideoBufferWrapper(struct AVCodecContext* aCodecContext,+ AVFrame* aFrame, int aFlags) {+ auto* decoder =+ static_cast<FFmpegVideoDecoder<LIBAV_VER>*>(aCodecContext->opaque);+ int rv = decoder->GetVideoBuffer(aCodecContext, aFrame, aFlags);+ return rv < 0 ? decoder->GetVideoBufferDefault(aCodecContext, aFrame, aFlags)+ : rv;+}++static void ReleaseVideoBufferWrapper(void* opaque, uint8_t* data) {+ if (opaque) {+ FFMPEG_LOGV("ReleaseVideoBufferWrapper: PlanarYCbCrImage=%p", opaque);+ RefPtr<ImageBufferWrapper> image = static_cast<ImageBufferWrapper*>(opaque);+ image->ReleaseBuffer();+ }+}++static gfx::YUVColorSpace TransferAVColorSpaceToYUVColorSpace(+ AVColorSpace aSpace) {+ switch (aSpace) {+ case AVCOL_SPC_BT2020_NCL:+ case AVCOL_SPC_BT2020_CL:+ return gfx::YUVColorSpace::BT2020;+ case AVCOL_SPC_BT709:+ return gfx::YUVColorSpace::BT709;+ case AVCOL_SPC_SMPTE170M:+ case AVCOL_SPC_BT470BG:+ return gfx::YUVColorSpace::BT601;+ default:+ return gfx::YUVColorSpace::Default;+ }+}++static bool IsColorFormatSupportedForUsingCustomizedBuffer(+ const AVPixelFormat& aFormat) {+# if XP_WIN+ // Currently the web render doesn't support uploading R16 surface, so we can't+ // use the shmem texture for 10 bit+ videos which would be uploaded by the+ // web render. See Bug 1751498.+ return aFormat == AV_PIX_FMT_YUV420P || aFormat == AV_PIX_FMT_YUVJ420P ||+ aFormat == AV_PIX_FMT_YUV444P;+# else+ // For now, we only support for YUV420P, YUVJ420P and YUV444 which are the+ // only non-HW accelerated format supported by FFmpeg's H264 and VP9 decoder.+ return aFormat == AV_PIX_FMT_YUV420P || aFormat == AV_PIX_FMT_YUVJ420P ||+ aFormat == AV_PIX_FMT_YUV420P10LE ||+ aFormat == AV_PIX_FMT_YUV420P12LE || aFormat == AV_PIX_FMT_YUV444P ||+ aFormat == AV_PIX_FMT_YUV444P10LE || aFormat == AV_PIX_FMT_YUV444P12LE;+# endif+}++static gfx::ColorDepth GetColorDepth(const AVPixelFormat& aFormat) {+ switch (aFormat) {+ case AV_PIX_FMT_YUV420P:+ case AV_PIX_FMT_YUVJ420P:+ case AV_PIX_FMT_YUV422P:+ case AV_PIX_FMT_YUV444P:+ return gfx::ColorDepth::COLOR_8;+ case AV_PIX_FMT_YUV420P10LE:+ case AV_PIX_FMT_YUV422P10LE:+ case AV_PIX_FMT_YUV444P10LE:+ return gfx::ColorDepth::COLOR_10;+ case AV_PIX_FMT_YUV420P12LE:+ case AV_PIX_FMT_YUV422P12LE:+ case AV_PIX_FMT_YUV444P12LE:+ return gfx::ColorDepth::COLOR_12;+ default:+ MOZ_ASSERT_UNREACHABLE("Not supported format?");+ return gfx::ColorDepth::COLOR_8;+ }+}++static bool IsYUV420Sampling(const AVPixelFormat& aFormat) {+ return aFormat == AV_PIX_FMT_YUV420P || aFormat == AV_PIX_FMT_YUVJ420P ||+ aFormat == AV_PIX_FMT_YUV420P10LE || aFormat == AV_PIX_FMT_YUV420P12LE;+}++layers::TextureClient*+FFmpegVideoDecoder<LIBAV_VER>::AllocateTextueClientForImage(+ struct AVCodecContext* aCodecContext, PlanarYCbCrImage* aImage) {+ layers::PlanarYCbCrData data =+ CreateEmptyPlanarYCbCrData(aCodecContext, mInfo);+ // Allocate a shmem buffer for image.+ if (!aImage->CreateEmptyBuffer(data)) {+ return nullptr;+ }+ return aImage->GetTextureClient(mImageAllocator);+}++layers::PlanarYCbCrData+FFmpegVideoDecoder<LIBAV_VER>::CreateEmptyPlanarYCbCrData(+ struct AVCodecContext* aCodecContext, const VideoInfo& aInfo) {+ MOZ_ASSERT(+ IsColorFormatSupportedForUsingCustomizedBuffer(aCodecContext->pix_fmt));++ // FFmpeg will store images with color depth > 8 bits in 16 bits with extra+ // padding.+ const int32_t bytesPerChannel =+ GetColorDepth(aCodecContext->pix_fmt) == gfx::ColorDepth::COLOR_8 ? 1 : 2;++ // If adjusted Ysize is larger than the actual image size (coded_width *+ // coded_height), that means ffmpeg decoder needs extra padding on both width+ // and height. If that happens, the planes will need to be cropped later in+ // order to avoid visible incorrect border on the right and bottom of the+ // actual image.+ //+ // Here are examples of various sizes video in YUV420P format, the width and+ // height would need to be adjusted in order to align padding.+ //+ // Eg1. video (1920*1080)+ // plane Y+ // width 1920 height 1080 -> adjusted-width 1920 adjusted-height 1088+ // plane Cb/Cr+ // width 960 height 540 -> adjusted-width 1024 adjusted-height 544+ //+ // Eg2. video (2560*1440)+ // plane Y+ // width 2560 height 1440 -> adjusted-width 2560 adjusted-height 1440+ // plane Cb/Cr+ // width 1280 height 720 -> adjusted-width 1280 adjusted-height 736+ layers::PlanarYCbCrData data;+ auto paddedYSize =+ gfx::IntSize{aCodecContext->coded_width, aCodecContext->coded_height};+ mLib->avcodec_align_dimensions(aCodecContext, &paddedYSize.width,+ &paddedYSize.height);+ data.mYSize = gfx::IntSize{paddedYSize.Width(), paddedYSize.Height()};+ data.mYStride = data.mYSize.Width() * bytesPerChannel;+ data.mCroppedYSize = Some(+ gfx::IntSize{aCodecContext->coded_width, aCodecContext->coded_height});++ MOZ_ASSERT(+ IsColorFormatSupportedForUsingCustomizedBuffer(aCodecContext->pix_fmt));+ const auto yDims =+ gfx::IntSize{aCodecContext->coded_width, aCodecContext->coded_height};+ auto uvDims = yDims;+ if (IsYUV420Sampling(aCodecContext->pix_fmt)) {+ uvDims.width = (uvDims.width + 1) / 2;+ uvDims.height = (uvDims.height + 1) / 2;+ }+ auto paddedCbCrSize = uvDims;+ mLib->avcodec_align_dimensions(aCodecContext, &paddedCbCrSize.width,+ &paddedCbCrSize.height);+ data.mCbCrSize =+ gfx::IntSize{paddedCbCrSize.Width(), paddedCbCrSize.Height()};+ data.mCbCrStride = data.mCbCrSize.Width() * bytesPerChannel;+ data.mCroppedCbCrSize = Some(gfx::IntSize{uvDims.Width(), uvDims.Height()});++ // Setting other attributes+ data.mPicSize =+ gfx::IntSize{aCodecContext->coded_width, aCodecContext->coded_height};+ const gfx::IntRect picture =+ aInfo.ScaledImageRect(data.mPicSize.Width(), data.mPicSize.Height());+ data.mPicX = picture.x;+ data.mPicY = picture.y;+ data.mStereoMode = aInfo.mStereoMode;+ if (aCodecContext->colorspace != AVCOL_SPC_UNSPECIFIED) {+ data.mYUVColorSpace =+ TransferAVColorSpaceToYUVColorSpace(aCodecContext->colorspace);+ } else {+ data.mYUVColorSpace = aInfo.mColorSpace ? *aInfo.mColorSpace+ : DefaultColorSpace(data.mPicSize);+ }+ data.mColorDepth = GetColorDepth(aCodecContext->pix_fmt);+ data.mColorRange = aCodecContext->color_range == AVCOL_RANGE_JPEG+ ? gfx::ColorRange::FULL+ : gfx::ColorRange::LIMITED;+ FFMPEG_LOGV(+ "Created plane data, YSize=(%d, %d), CbCrSize=(%d, %d), "+ "CroppedYSize=(%d, %d), CroppedCbCrSize=(%d, %d), ColorDepth=%hhu",+ data.mYSize.Width(), data.mYSize.Height(), data.mCbCrSize.Width(),+ data.mCbCrSize.Height(), data.mCroppedYSize->Width(),+ data.mCroppedYSize->Height(), data.mCroppedCbCrSize->Width(),+ data.mCroppedCbCrSize->Height(), static_cast<uint8_t>(data.mColorDepth));+ return data;+}++int FFmpegVideoDecoder<LIBAV_VER>::GetVideoBuffer(+ struct AVCodecContext* aCodecContext, AVFrame* aFrame, int aFlags) {+ FFMPEG_LOGV("GetVideoBuffer: aCodecContext=%p aFrame=%p", aCodecContext,+ aFrame);+ if (!StaticPrefs::media_ffmpeg_customized_buffer_allocation()) {+ return AVERROR(EINVAL);+ }++ if (mIsUsingShmemBufferForDecode && !*mIsUsingShmemBufferForDecode) {+ return AVERROR(EINVAL);+ }++ // Codec doesn't support custom allocator.+ if (!(aCodecContext->codec->capabilities & AV_CODEC_CAP_DR1)) {+ return AVERROR(EINVAL);+ }++ // Pre-allocation is only for sw decoding. During decoding, ffmpeg decoder+ // will need to reference decoded frames, if those frames are on shmem buffer,+ // then it would cause a need to read CPU data from GPU, which is slow.+ if (IsHardwareAccelerated()) {+ return AVERROR(EINVAL);+ }++ if (!IsColorFormatSupportedForUsingCustomizedBuffer(aCodecContext->pix_fmt)) {+ FFMPEG_LOG("Not support color format %d", aCodecContext->pix_fmt);+ return AVERROR(EINVAL);+ }++ if (aCodecContext->lowres != 0) {+ FFMPEG_LOG("Not support low resolution decoding");+ return AVERROR(EINVAL);+ }++ const gfx::IntSize size(aCodecContext->width, aCodecContext->height);+ int rv = mLib->av_image_check_size(size.Width(), size.Height(), 0, nullptr);+ if (rv < 0) {+ FFMPEG_LOG("Invalid image size");+ return rv;+ }++ CheckedInt32 dataSize = mLib->av_image_get_buffer_size(+ aCodecContext->pix_fmt, aCodecContext->coded_width,+ aCodecContext->coded_height, 16);+ if (!dataSize.isValid()) {+ FFMPEG_LOG("Data size overflow!");+ return AVERROR(EINVAL);+ }++ if (!mImageContainer) {+ FFMPEG_LOG("No Image container!");+ return AVERROR(EINVAL);+ }++ RefPtr<PlanarYCbCrImage> image = mImageContainer->CreatePlanarYCbCrImage();+ if (!image) {+ FFMPEG_LOG("Failed to create YCbCr image");+ return AVERROR(EINVAL);+ }++ RefPtr<layers::TextureClient> texture =+ AllocateTextueClientForImage(aCodecContext, image);+ if (!texture) {+ FFMPEG_LOG("Failed to allocate a texture client");+ return AVERROR(EINVAL);+ }++ if (!texture->Lock(layers::OpenMode::OPEN_WRITE)) {+ FFMPEG_LOG("Failed to lock the texture");+ return AVERROR(EINVAL);+ }++ layers::MappedYCbCrTextureData mapped;+ if (!texture->BorrowMappedYCbCrData(mapped)) {+ FFMPEG_LOG("Failed to borrow mapped data for the texture");+ texture->Unlock();+ return AVERROR(EINVAL);+ }++ aFrame->data[0] = mapped.y.data;+ aFrame->data[1] = mapped.cb.data;+ aFrame->data[2] = mapped.cr.data;++ aFrame->linesize[0] = mapped.y.stride;+ aFrame->linesize[1] = mapped.cb.stride;+ aFrame->linesize[2] = mapped.cr.stride;++ aFrame->width = aCodecContext->coded_width;+ aFrame->height = aCodecContext->coded_height;+ aFrame->format = aCodecContext->pix_fmt;+ aFrame->extended_data = aFrame->data;+ aFrame->reordered_opaque = aCodecContext->reordered_opaque;+ MOZ_ASSERT(aFrame->data[0] && aFrame->data[1] && aFrame->data[2]);++ // This will hold a reference to image, and the reference would be dropped+ // when ffmpeg tells us that the buffer is no longer needed.+ auto imageWrapper = MakeRefPtr<ImageBufferWrapper>(image.get(), this);+ aFrame->buf[0] =+ mLib->av_buffer_create(aFrame->data[0], dataSize.value(),+ ReleaseVideoBufferWrapper, imageWrapper.get(), 0);+ if (!aFrame->buf[0]) {+ FFMPEG_LOG("Failed to allocate buffer");+ return AVERROR(EINVAL);+ }++ FFMPEG_LOG("Created av buffer, buf=%p, data=%p, image=%p, sz=%d",+ aFrame->buf[0], aFrame->data[0], image.get(), dataSize.value());+ mAllocatedImages.Insert(imageWrapper.get());+ mIsUsingShmemBufferForDecode = Some(true);+ return 0;+}+#endif void FFmpegVideoDecoder<LIBAV_VER>::InitCodecContext() { mCodecContext->width = mInfo.mImage.width;@@ -409,6 +736,14 @@ // FFmpeg will call back to this to negotiate a video pixel format. mCodecContext->get_format = ChoosePixelFormat;+#ifdef CUSTOMIZED_BUFFER_ALLOCATION+ FFMPEG_LOG("Set get_buffer2 for customized buffer allocation");+ mCodecContext->get_buffer2 = GetVideoBufferWrapper;+ mCodecContext->opaque = this;+# if FF_API_THREAD_SAFE_CALLBACKS+ mCodecContext->thread_safe_callbacks = 1;+# endif+#endif } #ifdef MOZ_WAYLAND_USE_VAAPI@@ -460,11 +795,16 @@ } do { if (!PrepareFrame()) {- NS_WARNING("FFmpeg h264 decoder failed to allocate frame.");+ NS_WARNING("FFmpeg decoder failed to allocate frame."); return MediaResult(NS_ERROR_OUT_OF_MEMORY, __func__); } # ifdef MOZ_WAYLAND_USE_VAAPI+ // Create VideoFramePool in case we need it.+ if (!mVideoFramePool && mEnableHardwareDecoding) {+ mVideoFramePool = MakeUnique<VideoFramePool>();+ }+ // Release unused VA-API surfaces before avcodec_receive_frame() as // ffmpeg recycles VASurface for HW decoding. if (mVideoFramePool) {@@ -474,34 +814,30 @@ res = mLib->avcodec_receive_frame(mCodecContext, mFrame); if (res == int(AVERROR_EOF)) {+ FFMPEG_LOG(" End of stream."); return NS_ERROR_DOM_MEDIA_END_OF_STREAM; } if (res == AVERROR(EAGAIN)) { return NS_OK; } if (res < 0) {- FFMPEG_LOG("avcodec_receive_frame error: %d", res);+ FFMPEG_LOG(" avcodec_receive_frame error: %d", res); return MediaResult(NS_ERROR_DOM_MEDIA_DECODE_ERR, RESULT_DETAIL("avcodec_receive_frame error: %d", res)); } MediaResult rv; # ifdef MOZ_WAYLAND_USE_VAAPI- if (mVAAPIDeviceContext) {+ if (IsHardwareAccelerated()) { rv = CreateImageVAAPI(mFrame->pkt_pos, mFrame->pkt_pts, mFrame->pkt_duration, aResults); // If VA-API playback failed, just quit. Decoder is going to be restarted // without VA-API. if (NS_FAILED(rv)) {+ // Explicitly remove dmabuf surface pool as it's configured+ // for VA-API support.+ mVideoFramePool = nullptr; return rv;- }- } else if (mUseDMABufSurfaces) {- rv = CreateImageDMABuf(mFrame->pkt_pos, mFrame->pkt_pts,- mFrame->pkt_duration, aResults);- if (NS_FAILED(rv)) {- mUseDMABufSurfaces = false;- rv = CreateImage(mFrame->pkt_pos, mFrame->pkt_pts, mFrame->pkt_duration,- aResults); } } else # endif@@ -526,7 +862,7 @@ aSample->mDuration.ToMicroseconds()); if (!PrepareFrame()) {- NS_WARNING("FFmpeg h264 decoder failed to allocate frame.");+ NS_WARNING("FFmpeg decoder failed to allocate frame."); return MediaResult(NS_ERROR_OUT_OF_MEMORY, __func__); }@@ -594,6 +930,8 @@ case AVCOL_SPC_SMPTE170M: case AVCOL_SPC_BT470BG: return gfx::YUVColorSpace::BT601;+ case AVCOL_SPC_RGB:+ return gfx::YUVColorSpace::Identity; default: break; }@@ -628,6 +966,9 @@ #if LIBAVCODEC_VERSION_MAJOR >= 57 || mCodecContext->pix_fmt == AV_PIX_FMT_YUV444P12LE #endif+#if defined(MOZ_AV1) && defined(FFVPX_VERSION) && defined(MOZ_WAYLAND)+ || mCodecContext->pix_fmt == AV_PIX_FMT_GBRP+#endif ) { b.mPlanes[1].mWidth = b.mPlanes[2].mWidth = mFrame->width; b.mPlanes[1].mHeight = b.mPlanes[2].mHeight = mFrame->height;@@ -675,11 +1016,35 @@ : gfx::ColorRange::LIMITED; }- RefPtr<VideoData> v = VideoData::CreateAndCopyData(- mInfo, mImageContainer, aOffset, TimeUnit::FromMicroseconds(aPts),- TimeUnit::FromMicroseconds(aDuration), b, !!mFrame->key_frame,- TimeUnit::FromMicroseconds(-1),- mInfo.ScaledImageRect(mFrame->width, mFrame->height), mImageAllocator);+ RefPtr<VideoData> v;+#ifdef CUSTOMIZED_BUFFER_ALLOCATION+ if (mIsUsingShmemBufferForDecode && *mIsUsingShmemBufferForDecode) {+ RefPtr<ImageBufferWrapper> wrapper = static_cast<ImageBufferWrapper*>(+ mLib->av_buffer_get_opaque(mFrame->buf[0]));+ MOZ_ASSERT(wrapper);+ auto* image = wrapper->AsPlanarYCbCrImage();+ RefPtr<layers::TextureClient> texture = image->GetTextureClient(nullptr);+ if (!texture) {+ NS_WARNING("Failed to get the texture client!");+ } else {+ // Texture was locked to ensure no one can modify or access texture's data+ // except ffmpeg decoder. After finisheing decoding, texture's data would+ // be avaliable for accessing for everyone so we unlock texture.+ texture->Unlock();+ v = VideoData::CreateFromImage(+ mInfo.mDisplay, aOffset, TimeUnit::FromMicroseconds(aPts),+ TimeUnit::FromMicroseconds(aDuration), image, !!mFrame->key_frame,+ TimeUnit::FromMicroseconds(-1));+ }+ }+#endif+ if (!v) {+ v = VideoData::CreateAndCopyData(+ mInfo, mImageContainer, aOffset, TimeUnit::FromMicroseconds(aPts),+ TimeUnit::FromMicroseconds(aDuration), b, !!mFrame->key_frame,+ TimeUnit::FromMicroseconds(-1),+ mInfo.ScaledImageRect(mFrame->width, mFrame->height), mImageAllocator);+ } if (!v) { return MediaResult(NS_ERROR_OUT_OF_MEMORY,@@ -703,10 +1068,6 @@ if (vas != VA_STATUS_SUCCESS) { NS_WARNING("vaSyncSurface() failed."); }-- aVaDesc->width = mFrame->width;- aVaDesc->height = mFrame->height;- return true; }@@ -720,17 +1081,17 @@ VADRMPRIMESurfaceDescriptor vaDesc; if (!GetVAAPISurfaceDescriptor(&vaDesc)) { return MediaResult(- NS_ERROR_OUT_OF_MEMORY,+ NS_ERROR_DOM_MEDIA_DECODE_ERR, RESULT_DETAIL("Unable to get frame by vaExportSurfaceHandle()")); } MOZ_ASSERT(mTaskQueue->IsOnCurrentThread());- auto surface = mVideoFramePool->GetVideoFrameSurface(vaDesc);+ auto surface = mVideoFramePool->GetVideoFrameSurface(vaDesc, mCodecContext,+ mFrame, mLib); if (!surface) {- return MediaResult(NS_ERROR_OUT_OF_MEMORY,+ return MediaResult(NS_ERROR_DOM_MEDIA_DECODE_ERR, RESULT_DETAIL("VAAPI dmabuf allocation error")); }- surface->LockVAAPIData(mCodecContext, mFrame, mLib); surface->SetYUVColorSpace(GetFrameColorSpace()); if (mLib->av_frame_get_color_range) {@@ -746,45 +1107,8 @@ !!mFrame->key_frame, TimeUnit::FromMicroseconds(-1)); if (!vp) {- return MediaResult(NS_ERROR_OUT_OF_MEMORY,+ return MediaResult(NS_ERROR_DOM_MEDIA_DECODE_ERR, RESULT_DETAIL("VAAPI image allocation error"));- }-- aResults.AppendElement(std::move(vp));- return NS_OK;-}--MediaResult FFmpegVideoDecoder<LIBAV_VER>::CreateImageDMABuf(- int64_t aOffset, int64_t aPts, int64_t aDuration,- MediaDataDecoder::DecodedData& aResults) {- FFMPEG_LOG("DMABuf Got one frame output with pts=%" PRId64 "dts=%" PRId64- " duration=%" PRId64 " opaque=%" PRId64,- aPts, mFrame->pkt_dts, aDuration, mCodecContext->reordered_opaque);-- MOZ_ASSERT(mTaskQueue->IsOnCurrentThread());- auto surface =- mVideoFramePool->GetVideoFrameSurface(mCodecContext->pix_fmt, mFrame);- if (!surface) {- return MediaResult(NS_ERROR_OUT_OF_MEMORY,- RESULT_DETAIL("dmabuf allocation error"));- }- surface->SetYUVColorSpace(GetFrameColorSpace());-- if (mLib->av_frame_get_color_range) {- auto range = mLib->av_frame_get_color_range(mFrame);- surface->SetColorRange(range == AVCOL_RANGE_JPEG- ? gfx::ColorRange::FULL- : gfx::ColorRange::LIMITED);- }-- RefPtr<VideoData> vp = VideoData::CreateFromImage(- mInfo.mDisplay, aOffset, TimeUnit::FromMicroseconds(aPts),- TimeUnit::FromMicroseconds(aDuration), surface->GetAsImage(),- !!mFrame->key_frame, TimeUnit::FromMicroseconds(-1));-- if (!vp) {- return MediaResult(NS_ERROR_OUT_OF_MEMORY,- RESULT_DETAIL("image allocation error")); } aResults.AppendElement(std::move(vp));@@ -822,6 +1146,12 @@ } #endif+#if defined(MOZ_AV1) && defined(FFVPX_VERSION) && defined(MOZ_WAYLAND)+ if (AOMDecoder::IsAV1(aMimeType)) {+ return AV_CODEC_ID_AV1;+ }+#endif+ return AV_CODEC_ID_NONE; }@@ -829,18 +1159,195 @@ MOZ_ASSERT(mTaskQueue->IsOnCurrentThread()); #ifdef MOZ_WAYLAND_USE_VAAPI mVideoFramePool = nullptr;- if (mVAAPIDeviceContext) {+ if (IsHardwareAccelerated()) { mLib->av_buffer_unref(&mVAAPIDeviceContext); } #endif FFmpegDataDecoder<LIBAV_VER>::ProcessShutdown(); }-#ifdef MOZ_WAYLAND_USE_VAAPI bool FFmpegVideoDecoder<LIBAV_VER>::IsHardwareAccelerated( nsACString& aFailureReason) const {+#ifdef MOZ_WAYLAND_USE_VAAPI return !!mVAAPIDeviceContext;-}+#else+ return false;+#endif+}++#ifdef MOZ_WAYLAND_USE_VAAPI+bool FFmpegVideoDecoder<LIBAV_VER>::IsFormatAccelerated(+ AVCodecID aCodecID) const {+ for (const auto& format : mAcceleratedFormats) {+ if (format == aCodecID) {+ return true;+ }+ }+ return false;+}++// See ffmpeg / vaapi_decode.c how CodecID is mapped to VAProfile.+static const struct {+ enum AVCodecID codec_id;+ VAProfile va_profile;+ char name[100];+} vaapi_profile_map[] = {+# define MAP(c, v, n) \+ { AV_CODEC_ID_##c, VAProfile##v, n }+ MAP(H264, H264ConstrainedBaseline, "H264ConstrainedBaseline"),+ MAP(H264, H264Main, "H264Main"),+ MAP(H264, H264High, "H264High"),+ MAP(VP8, VP8Version0_3, "VP8Version0_3"),+ MAP(VP9, VP9Profile0, "VP9Profile0"),+ MAP(VP9, VP9Profile2, "VP9Profile2"),+ MAP(AV1, AV1Profile0, "AV1Profile0"),+ MAP(AV1, AV1Profile1, "AV1Profile1"),+# undef MAP+};++static AVCodecID VAProfileToCodecID(VAProfile aVAProfile) {+ for (const auto& profile : vaapi_profile_map) {+ if (profile.va_profile == aVAProfile) {+ return profile.codec_id;+ }+ }+ return AV_CODEC_ID_NONE;+}++static const char* VAProfileName(VAProfile aVAProfile) {+ for (const auto& profile : vaapi_profile_map) {+ if (profile.va_profile == aVAProfile) {+ return profile.name;+ }+ }+ return nullptr;+}++// This code is adopted from mpv project va-api routine+// determine_working_formats()+void FFmpegVideoDecoder<LIBAV_VER>::AddAcceleratedFormats(+ nsTArray<AVCodecID>& aCodecList, AVCodecID aCodecID,+ AVVAAPIHWConfig* hwconfig) {+ AVHWFramesConstraints* fc =+ mLib->av_hwdevice_get_hwframe_constraints(mVAAPIDeviceContext, hwconfig);+ if (!fc) {+ FFMPEG_LOG(" failed to retrieve libavutil frame constraints");+ return;+ }+ auto autoRelease =+ MakeScopeExit([&] { mLib->av_hwframe_constraints_free(&fc); });++ bool foundSupportedFormat = false;+ for (int n = 0;+ fc->valid_sw_formats && fc->valid_sw_formats[n] != AV_PIX_FMT_NONE;+ n++) {+# ifdef MOZ_LOGGING+ char formatDesc[1000];+ FFMPEG_LOG(" codec %s format %s", mLib->avcodec_get_name(aCodecID),+ mLib->av_get_pix_fmt_string(formatDesc, sizeof(formatDesc),+ fc->valid_sw_formats[n]));+# endif+ if (fc->valid_sw_formats[n] == AV_PIX_FMT_NV12 ||+ fc->valid_sw_formats[n] == AV_PIX_FMT_YUV420P) {+ foundSupportedFormat = true;+# ifndef MOZ_LOGGING+ break;+# endif+ }+ }++ if (!foundSupportedFormat) {+ FFMPEG_LOG(" %s target pixel format is not supported!",+ mLib->avcodec_get_name(aCodecID));+ return;+ }++ if (!aCodecList.Contains(aCodecID)) {+ aCodecList.AppendElement(aCodecID);+ }+}++nsTArray<AVCodecID> FFmpegVideoDecoder<LIBAV_VER>::GetAcceleratedFormats() {+ FFMPEG_LOG("FFmpegVideoDecoder::GetAcceleratedFormats()");++ VAProfile* profiles = nullptr;+ VAEntrypoint* entryPoints = nullptr;++ nsTArray<AVCodecID> supportedHWCodecs(AV_CODEC_ID_NONE);+# ifdef MOZ_LOGGING+ auto printCodecs = MakeScopeExit([&] {+ FFMPEG_LOG(" Supported accelerated formats:");+ for (unsigned i = 0; i < supportedHWCodecs.Length(); i++) {+ FFMPEG_LOG(" %s", mLib->avcodec_get_name(supportedHWCodecs[i]));+ }+ });+# endif++ AVVAAPIHWConfig* hwconfig =+ mLib->av_hwdevice_hwconfig_alloc(mVAAPIDeviceContext);+ if (!hwconfig) {+ FFMPEG_LOG(" failed to get AVVAAPIHWConfig");+ return supportedHWCodecs;+ }+ auto autoRelease = MakeScopeExit([&] {+ delete[] profiles;+ delete[] entryPoints;+ mLib->av_freep(&hwconfig);+ });++ int maxProfiles = vaMaxNumProfiles(mDisplay);+ int maxEntryPoints = vaMaxNumEntrypoints(mDisplay);+ if (MOZ_UNLIKELY(maxProfiles <= 0 || maxEntryPoints <= 0)) {+ return supportedHWCodecs;+ }++ profiles = new VAProfile[maxProfiles];+ int numProfiles = 0;+ VAStatus status = vaQueryConfigProfiles(mDisplay, profiles, &numProfiles);+ if (status != VA_STATUS_SUCCESS) {+ FFMPEG_LOG(" vaQueryConfigProfiles() failed %s", vaErrorStr(status));+ return supportedHWCodecs;+ }+ numProfiles = MIN(numProfiles, maxProfiles);++ entryPoints = new VAEntrypoint[maxEntryPoints];+ for (int p = 0; p < numProfiles; p++) {+ VAProfile profile = profiles[p];++ AVCodecID codecID = VAProfileToCodecID(profile);+ if (codecID == AV_CODEC_ID_NONE) {+ continue;+ }++ int numEntryPoints = 0;+ status = vaQueryConfigEntrypoints(mDisplay, profile, entryPoints,+ &numEntryPoints);+ if (status != VA_STATUS_SUCCESS) {+ FFMPEG_LOG(" vaQueryConfigEntrypoints() failed: '%s' for profile %d",+ vaErrorStr(status), (int)profile);+ continue;+ }+ numEntryPoints = MIN(numEntryPoints, maxEntryPoints);++ FFMPEG_LOG(" Profile %s:", VAProfileName(profile));+ for (int e = 0; e < numEntryPoints; e++) {+ VAConfigID config = VA_INVALID_ID;+ status = vaCreateConfig(mDisplay, profile, entryPoints[e], nullptr, 0,+ &config);+ if (status != VA_STATUS_SUCCESS) {+ FFMPEG_LOG(" vaCreateConfig() failed: '%s' for profile %d",+ vaErrorStr(status), (int)profile);+ continue;+ }+ hwconfig->config_id = config;+ AddAcceleratedFormats(supportedHWCodecs, codecID, hwconfig);+ vaDestroyConfig(mDisplay, config);+ }+ }++ return supportedHWCodecs;+}+ #endif } // namespace mozilla
I'll analyze the code diff for security fixes following the specified format. 1. Vulnerability Existed: not sure [Potential Memory Leak] [dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp] [Lines 264-273] [Old Code] No explicit cleanup of mVAAPIDeviceContext and mCodecContext in error cases [Fixed Code] Added ScopeExit cleanup for VAAPI decoder resources in InitVAAPIDecoder() 2. Vulnerability Existed: not sure [Potential Resource Leak] [dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp] [Lines 1068-1071] [Old Code] No check for VAAPI surface descriptor success before use [Fixed Code] Added error handling for GetVAAPISurfaceDescriptor() failure 3. Vulnerability Existed: not sure [Potential Race Condition] [dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp] [Lines 229-231] [Old Code] No thread synchronization for mAcceleratedFormats access [Fixed Code] Added StaticMutexAutoLock for mAcceleratedFormats access 4. Vulnerability Existed: not sure [Potential Memory Leak] [dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp] [Lines 383-386] [Old Code] No check for allocated images cleanup in destructor [Fixed Code] Added assertion to ensure all shmem buffers are released before destruction 5. Vulnerability Existed: not sure [Potential Security Check Bypass] [dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp] [Lines 199-207] [Old Code] Direct use of DRM display without proper validation [Fixed Code] Simplified display initialization with error checking The analysis shows several potential security improvements in the code, though I can't definitively confirm these were actual vulnerabilities. The changes appear to focus on: 1. Better resource cleanup 2. Improved error handling 3. Thread safety 4. Memory management 5. Input validation The most significant changes relate to VAAPI hardware acceleration handling and memory management for decoded frames.
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/canvas/OffscreenCanvasDisplayHelper.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/canvas/OffscreenCanvasDisplayHelper.h@@ -41,7 +41,7 @@ RefPtr<layers::ImageContainer> GetImageContainer() const;- void UpdateContext(CanvasContextType aType, int32_t aChildId);+ void UpdateContext(CanvasContextType aType, const Maybe<int32_t>& aChildId); bool CommitFrameToCompositor(nsICanvasRenderingContextInternal* aContext, layers::TextureType aTextureType,@@ -57,16 +57,20 @@ void MaybeQueueInvalidateElement(); void InvalidateElement();+ bool TransformSurface(const gfx::DataSourceSurface::ScopedMap& aSrcMap,+ const gfx::DataSourceSurface::ScopedMap& aDstMap,+ gfx::SurfaceFormat aFormat, const gfx::IntSize& aSize,+ bool aNeedsPremult, gl::OriginPos aOriginPos) const;+ mutable Mutex mMutex; HTMLCanvasElement* MOZ_NON_OWNING_REF mCanvasElement; RefPtr<layers::ImageContainer> mImageContainer; RefPtr<gfx::SourceSurface> mFrontBufferSurface;- Maybe<layers::SurfaceDescriptor> mFrontBufferDesc; OffscreenCanvasDisplayData mData; CanvasContextType mType = CanvasContextType::NoContext;- uint32_t mContextManagerId = 0;- int32_t mContextChildId = 0;+ Maybe<uint32_t> mContextManagerId;+ Maybe<int32_t> mContextChildId; mozilla::layers::ImageContainer::ProducerID mImageProducerID; mozilla::layers::ImageContainer::FrameID mLastFrameID = 0; bool mPendingInvalidate = false;
Here's the analysis of the provided code diff following the specified format: 1. Vulnerability Existed: not sure Parameter Type Change [File] [Lines 41] [Old Code] `void UpdateContext(CanvasContextType aType, int32_t aChildId);` [Fixed Code] `void UpdateContext(CanvasContextType aType, const Maybe<int32_t>& aChildId);` [Details] The change from raw int32_t to Maybe<int32_t> suggests better handling of optional/null values, but it's unclear if this was fixing a specific vulnerability or just improving type safety. 2. Vulnerability Existed: not sure Member Variable Type Change [File] [Lines 57, 67-68] [Old Code] `uint32_t mContextManagerId = 0;` `int32_t mContextChildId = 0;` [Fixed Code] `Maybe<uint32_t> mContextManagerId;` `Maybe<int32_t> mContextChildId;` [Details] The change to Maybe types for these member variables suggests better handling of uninitialized/null states, but no specific vulnerability is evident from the diff. 3. Vulnerability Existed: not sure Surface Descriptor Removal [File] [Lines 66] [Old Code] `Maybe<layers::SurfaceDescriptor> mFrontBufferDesc;` [Fixed Code] [Removed] [Details] The removal of mFrontBufferDesc might indicate a security improvement, but without more context about how this descriptor was used, we can't determine if this fixed a specific vulnerability. Note: While these changes appear to improve type safety and potentially null-state handling, the diff doesn't provide enough context to confirm if these were fixing specific known vulnerabilities or were general code improvements. The changes are more defensive in nature, which could prevent certain classes of bugs, but no specific vulnerability patterns (like buffer overflows, use-after-free, etc.) are evident from this diff alone.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/gfx/wr/webrender/src/scene_building.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/gfx/wr/webrender/src/scene_building.rs@@ -42,7 +42,7 @@ use api::{IframeDisplayItem, ImageKey, ImageRendering, ItemRange, ColorDepth, QualitySettings}; use api::{LineOrientation, LineStyle, NinePatchBorderSource, PipelineId, MixBlendMode, StackingContextFlags}; use api::{PropertyBinding, ReferenceFrameKind, ScrollFrameDescriptor, ReferenceFrameMapper};-use api::{Shadow, SpaceAndClipInfo, SpatialId, StickyFrameDescriptor, ImageMask, ItemTag};+use api::{APZScrollGeneration, HasScrollLinkedEffect, Shadow, SpaceAndClipInfo, SpatialId, StickyFrameDescriptor, ImageMask, ItemTag}; use api::{ClipMode, PrimitiveKeyKind, TransformStyle, YuvColorSpace, ColorRange, YuvData, TempFilterData}; use api::{ReferenceTransformBinding, Rotation, FillRule, SpatialTreeItem, ReferenceFrameDescriptor}; use api::units::*;@@ -786,16 +786,16 @@ if cfg!(feature = "display_list_stats") { let stats = traversal.debug_stats(); let total_bytes: usize = stats.iter().map(|(_, stats)| stats.num_bytes).sum();- println!("item, total count, total bytes, % of DL bytes, bytes per item");+ debug!("item, total count, total bytes, % of DL bytes, bytes per item"); for (label, stats) in stats {- println!("{}, {}, {}kb, {}%, {}",+ debug!("{}, {}, {}kb, {}%, {}", label, stats.total_count, stats.num_bytes / 1000, ((stats.num_bytes as f32 / total_bytes.max(1) as f32) * 100.0) as usize, stats.num_bytes / stats.total_count.max(1)); }- println!();+ debug!(""); } }@@ -916,6 +916,8 @@ &content_size, ScrollFrameKind::Explicit, info.external_scroll_offset,+ info.scroll_offset_generation,+ info.has_scroll_linked_effect, SpatialNodeUid::external(info.key, pipeline_id, instance_id), ); }@@ -978,6 +980,7 @@ ReferenceFrameKind::Transform { is_2d_scale_translation: true, should_snap: true,+ paired_with_perspective: false, }, bounds.min.to_vector(), SpatialNodeUid::root_reference_frame(iframe_pipeline_id, instance_id),@@ -997,6 +1000,8 @@ is_root_pipeline, }, LayoutVector2D::zero(),+ APZScrollGeneration::default(),+ HasScrollLinkedEffect::No, SpatialNodeUid::root_scroll_frame(iframe_pipeline_id, instance_id), );@@ -1721,7 +1726,7 @@ ) { // Add primitive to the top-most stacking context on the stack. if prim_instance.is_chased() {- println!("\tadded to stacking context at {}", self.sc_stack.len());+ info!("\tadded to stacking context at {}", self.sc_stack.len()); } // If we have a valid stacking context, the primitive gets added to that.@@ -2233,7 +2238,30 @@ }); let mut prim_list = PrimitiveList::empty();++ // Web content often specifies `preserve-3d` on pages that don't actually need+ // a 3d rendering context (as a hint / hack to convince other browsers to+ // layerize these elements to an off-screen surface). Detect cases where the+ // preserve-3d has no effect on correctness and convert them to pass-through+ // pictures instead. This has two benefits for WR:+ //+ // (1) We get correct subpixel-snapping behavior between preserve-3d elements+ // that don't have complex transforms without additional complexity of+ // handling subpixel-snapping across different surfaces.+ // (2) We can draw this content directly in to the parent surface / tile cache,+ // which is a performance win by avoiding allocating, drawing,+ // plane-splitting and blitting an off-screen surface.+ let mut needs_3d_context = false;+ for ext_prim in prims.drain(..) {+ // If all the preserve-3d elements are in the root coordinate system, we+ // know that there is no need for a true 3d rendering context / plane-split.+ // TODO(gw): We can expand this in future to handle this in more cases+ // (e.g. a non-root coord system that is 2d within the 3d context).+ if !self.spatial_tree.is_root_coord_system(ext_prim.spatial_node_index) {+ needs_3d_context = true;+ }+ prim_list.add_prim( ext_prim.instance, LayoutRect::zero(),@@ -2243,16 +2271,31 @@ ); }+ let context_3d = if needs_3d_context {+ Picture3DContext::In {+ root_data: Some(Vec::new()),+ ancestor_index,+ plane_splitter_index,+ }+ } else {+ // If we didn't need a 3d rendering context, walk the child pictures+ // that make up this context and disable the off-screen surface and+ // 3d render context.+ for child_pic_index in &prim_list.child_pictures {+ let child_pic = &mut self.prim_store.pictures[child_pic_index.0];+ child_pic.composite_mode = None;+ child_pic.context_3d = Picture3DContext::Out;+ }++ Picture3DContext::Out+ };+ // This is the acttual picture representing our 3D hierarchy root. let pic_index = PictureIndex(self.prim_store.pictures .alloc() .init(PicturePrimitive::new_image( None,- Picture3DContext::In {- root_data: Some(Vec::new()),- ancestor_index,- plane_splitter_index,- },+ context_3d, true, stacking_context.prim_flags, prim_list,@@ -2408,7 +2451,7 @@ instance: PipelineInstanceId, ) { if let ChasePrimitive::Id(id) = self.config.chase_primitive {- println!("Chasing {:?} by index", id);+ debug!("Chasing {:?} by index", id); register_prim_chase_id(id); }@@ -2421,6 +2464,7 @@ ReferenceFrameKind::Transform { is_2d_scale_translation: true, should_snap: true,+ paired_with_perspective: false, }, LayoutVector2D::zero(), SpatialNodeUid::root_reference_frame(pipeline_id, instance),@@ -2442,6 +2486,8 @@ is_root_pipeline: true, }, LayoutVector2D::zero(),+ APZScrollGeneration::default(),+ HasScrollLinkedEffect::No, SpatialNodeUid::root_scroll_frame(pipeline_id, instance), ); }@@ -2594,6 +2640,8 @@ content_size: &LayoutSize, frame_kind: ScrollFrameKind, external_scroll_offset: LayoutVector2D,+ scroll_offset_generation: APZScrollGeneration,+ has_scroll_linked_effect: HasScrollLinkedEffect, uid: SpatialNodeUid, ) -> SpatialNodeIndex { let node_index = self.spatial_tree.add_scroll_frame(@@ -2604,6 +2652,8 @@ content_size, frame_kind, external_scroll_offset,+ scroll_offset_generation,+ has_scroll_linked_effect, uid, ); self.id_to_index_mapper_stack.last_mut().unwrap().add_spatial_node(new_node_id, node_index);@@ -2873,7 +2923,7 @@ prim_instance: &PrimitiveInstance, ) { if ChasePrimitive::LocalRect(*rect) == self.config.chase_primitive {- println!("Chasing {:?} by local rect", prim_instance.id);+ debug!("Chasing {:?} by local rect", prim_instance.id); register_prim_chase_id(prim_instance.id); } }
I'll analyze the code diff and provide the security findings following the specified format.
Vulnerability Existed: not sure
Information Leakage [File] [Lines 786-916, 1726, 2451, 2923]
[Old Code]
println!("item, total count, total bytes, % of DL bytes, bytes per item");
println!("\tadded to stacking context at {}", self.sc_stack.len());
println!("Chasing {:?} by index", id);
println!("Chasing {:?} by local rect", prim_instance.id);
[Fixed Code]
debug!("item, total count, total bytes, % of DL bytes, bytes per item");
info!("\tadded to stacking context at {}", self.sc_stack.len());
debug!("Chasing {:?} by index", id);
debug!("Chasing {:?} by local rect", prim_instance.id);
Additional Details:
- The change replaces println! with debug!/info! macros for various logging statements
- This could be related to preventing information leakage in production builds
- The exact security impact is unclear without more context about the logging system
Vulnerability Existed: not sure
Missing Security Parameters [File] [Lines 916-978, 2594-2640]
[Old Code]
info.external_scroll_offset,
[Fixed Code]
info.external_scroll_offset,
info.scroll_offset_generation,
info.has_scroll_linked_effect,
Additional Details:
- Added new security-related parameters to scroll frame creation
- APZScrollGeneration and HasScrollLinkedEffect appear to be security-related flags
- The exact security impact is unclear without more context about these parameters
Vulnerability Existed: not sure
3D Context Validation [File] [Lines 2233-2271]
[Old Code]
Picture3DContext::In {
root_data: Some(Vec::new()),
ancestor_index,
plane_splitter_index,
}
[Fixed Code]
Added validation to check if 3D context is actually needed before creating it
Additional Details:
- Added logic to detect unnecessary preserve-3d contexts
- Prevents potential abuse of 3D rendering contexts
- Could be related to preventing performance-based attacks
Note: While none of these changes clearly fix known vulnerabilities, they appear to be security-related improvements that could prevent potential issues like information leakage or abuse of rendering features. The exact security impact would require deeper knowledge of the WebRender system.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/the-offscreen-canvas/2d.getcontext.extraargs.cache.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.extraargs.cache.html@@ -17,15 +17,15 @@ }); 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');-_assertDifferent(offscreenCanvas.getContext('2d', false, {}, [], 1, "2"), null, "offscreenCanvas.getContext('2d', false, {}, [], 1, \"2\")", "null");-_assertDifferent(offscreenCanvas.getContext('2d', 123), null, "offscreenCanvas.getContext('2d', 123)", "null");-_assertDifferent(offscreenCanvas.getContext('2d', "test"), null, "offscreenCanvas.getContext('2d', \"test\")", "null");-_assertDifferent(offscreenCanvas.getContext('2d', undefined), null, "offscreenCanvas.getContext('2d', undefined)", "null");-_assertDifferent(offscreenCanvas.getContext('2d', null), null, "offscreenCanvas.getContext('2d', null)", "null");-_assertDifferent(offscreenCanvas.getContext('2d', Symbol.hasInstance), null, "offscreenCanvas.getContext('2d', Symbol.hasInstance)", "null");+_assertDifferent(canvas.getContext('2d', false, {}, [], 1, "2"), null, "canvas.getContext('2d', false, {}, [], 1, \"2\")", "null");+_assertDifferent(canvas.getContext('2d', 123), null, "canvas.getContext('2d', 123)", "null");+_assertDifferent(canvas.getContext('2d', "test"), null, "canvas.getContext('2d', \"test\")", "null");+_assertDifferent(canvas.getContext('2d', undefined), null, "canvas.getContext('2d', undefined)", "null");+_assertDifferent(canvas.getContext('2d', null), null, "canvas.getContext('2d', null)", "null");+_assertDifferent(canvas.getContext('2d', Symbol.hasInstance), null, "canvas.getContext('2d', Symbol.hasInstance)", "null"); t.done(); });
After analyzing the provided code diff, here's the security assessment: Vulnerability Existed: no The changes in the diff appear to be purely cosmetic/refactoring changes, renaming the variable `offscreenCanvas` to `canvas` and updating all related assertions accordingly. There are no security-related changes or vulnerability fixes in this diff. The changes are: 1. Variable name change from `offscreenCanvas` to `canvas` 2. Corresponding updates to all assertion messages to use the new variable name 3. No changes to the actual functionality or security aspects of the code No security vulnerabilities were identified in this diff. The modifications are focused on code readability and consistency 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/third_party/rust/darling_core/src/codegen/field.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/darling_core/src/codegen/field.rs@@ -4,8 +4,8 @@ use quote::{ToTokens, TokenStreamExt}; use syn::{Ident, Path, Type};-use codegen::DefaultExpression;-use usage::{self, IdentRefSet, IdentSet, UsesTypeParams};+use crate::codegen::{DefaultExpression, PostfixTransform};+use crate::usage::{self, IdentRefSet, IdentSet, UsesTypeParams}; /// Properties needed to generate code for a field in all the contexts /// where one may appear.@@ -23,7 +23,7 @@ pub ty: &'a Type, pub default_expression: Option<DefaultExpression<'a>>, pub with_path: Cow<'a, Path>,- pub map: Option<&'a Path>,+ pub post_transform: Option<&'a PostfixTransform>, pub skip: bool, pub multiple: bool, }@@ -97,6 +97,7 @@ let name_str = &field.name_in_attr; let ident = field.ident; let with_path = &field.with_path;+ let post_transform = field.post_transform.as_ref(); // Errors include the location of the bad input, so we compute that here. // Fields that take multiple values add the index of the error for convenience,@@ -114,11 +115,7 @@ // The behavior of `with_span` makes this safe to do; if the child applied an // even-more-specific span, our attempt here will not overwrite that and will only cost // us one `if` check.- let mut extractor =- quote!(#with_path(__inner).map_err(|e| e.with_span(&__inner).at(#location)));- if let Some(ref map) = field.map {- extractor = quote!(#extractor.map(#map))- }+ let extractor = quote!(#with_path(__inner)#post_transform.map_err(|e| e.with_span(&__inner).at(#location))); tokens.append_all(if field.multiple { quote!(
Let me analyze the code diff for potential security vulnerabilities:
1. Vulnerability Existed: not sure
[Potential Path Traversal or Injection Vulnerability] [third_party/rust/darling_core/src/codegen/field.rs] [Lines 23,97,115]
Old Code:
```
pub map: Option<&'a Path>,
```
Fixed Code:
```
pub post_transform: Option<&'a PostfixTransform>,
```
Additional Details: The change replaces a raw Path with a PostfixTransform type, which might indicate a move towards more controlled path/transform handling, but without seeing the PostfixTransform implementation, we can't be certain if this fixes a security issue.
2. Vulnerability Existed: not sure
[Potential Code Injection Vulnerability] [third_party/rust/darling_core/src/codegen/field.rs] [Lines 114-115]
Old Code:
```
let mut extractor =
quote!(#with_path(__inner).map_err(|e| e.with_span(&__inner).at(#location)));
if let Some(ref map) = field.map {
extractor = quote!(#extractor.map(#map))
}
```
Fixed Code:
```
let extractor = quote!(#with_path(__inner)#post_transform.map_err(|e| e.with_span(&__inner).at(#location)));
```
Additional Details: The change simplifies the code generation by removing the separate map step and incorporating the transformation directly. This could potentially make the code generation more secure by reducing attack surface, but we'd need more context to be certain.
Note: The changes appear to be more about code structure and type safety improvements rather than explicit security fixes. The switch from raw Path handling to a dedicated PostfixTransform type suggests better type safety, but without more context about the usage scenarios, we can't definitively identify specific vulnerabilities being fixed.
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.union.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.union.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -27,12 +27,12 @@ ctx.lineTo(0, 26); ctx.closePath(); ctx.stroke();-_assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 25,1, 0,255,0,255, "25,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 48,1, 0,255,0,255, "48,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");-_assertPixel(offscreenCanvas, 25,1, 0,255,0,255, "25,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 48,48, 0,255,0,255, "48,48", "0,255,0,255");+_assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");+_assertPixel(canvas, 25,1, 0,255,0,255, "25,1", "0,255,0,255");+_assertPixel(canvas, 48,1, 0,255,0,255, "48,1", "0,255,0,255");+_assertPixel(canvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");+_assertPixel(canvas, 25,1, 0,255,0,255, "25,1", "0,255,0,255");+_assertPixel(canvas, 48,48, 0,255,0,255, "48,48", "0,255,0,255"); t.done(); });
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and updating the corresponding references in the `_assertPixel` calls. Here's the structured response:
Vulnerability Existed: no
No security vulnerability found in the diff. The changes are purely variable renaming for consistency.
Old Code:
```javascript
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");
```
Fixed Code:
```javascript
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");
```
This appears to be a code style/readability improvement rather than a security fix. The functionality remains identical, just with a more concise 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/js/src/vm/RecordType.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/vm/RecordType.cpp@@ -32,7 +32,6 @@ #include "vm/JSAtom-inl.h" #include "vm/JSObject-inl.h" #include "vm/NativeObject-inl.h"-#include "vm/Shape-inl.h" using namespace js;@@ -50,11 +49,14 @@ nullptr, nullptr};+Shape* RecordType::getInitialShape(JSContext* cx) {+ return SharedShape::getInitialShape(cx, &RecordType::class_, cx->realm(),+ TaggedProto(nullptr), SLOT_COUNT);+}+ RecordType* RecordType::createUninitialized(JSContext* cx, uint32_t initialLength) {- RootedShape shape(- cx, SharedShape::getInitialShape(cx, &RecordType::class_, cx->realm(),- TaggedProto(nullptr), SLOT_COUNT));+ RootedShape shape(cx, getInitialShape(cx)); if (!shape) { return nullptr; }@@ -114,7 +116,7 @@ } initSlot(slot, value);- // Add the key to the SORTED_KEYS instenal slot+ // Add the key to the SORTED_KEYS internal slot JSAtom* atomKey = key.isString() ? AtomizeString(cx, key.toString()) : Int32ToAtom(cx, key.toInt());@@ -178,7 +180,7 @@ } // We preallocate 1 element for each object spread. If spreads end up- // introducing zero elements, we can then shrink the sordedKeys array.+ // introducing zero elements, we can then shrink the sortedKeys array. sortedKeys.setDenseInitializedLength(length); sortedKeys.setLength(length); sortedKeys.setNonWritableLength(cx);
Here's the analysis of the provided code diff following the specified format:
1. Vulnerability Existed: not sure
[Potential Uninitialized Memory Access] [File: js/src/vm/RecordType.cpp] [Lines: 50-53]
[Old Code: N/A (new function added)]
[Fixed Code:
Shape* RecordType::getInitialShape(JSContext* cx) {
return SharedShape::getInitialShape(cx, &RecordType::class_, cx->realm(),
TaggedProto(nullptr), SLOT_COUNT);
}]
Note: The addition of getInitialShape() could be related to preventing uninitialized memory access, but without more context about the calling patterns, this is uncertain.
2. Vulnerability Existed: no
[Typo Fix] [File: js/src/vm/RecordType.cpp] [Lines: 117]
[Old Code: "// Add the key to the SORTED_KEYS instenal slot"]
[Fixed Code: "// Add the key to the SORTED_KEYS internal slot"]
Note: This appears to be just a typo correction with no security implications.
3. Vulnerability Existed: no
[Typo Fix] [File: js/src/vm/RecordType.cpp] [Lines: 180]
[Old Code: "// introducing zero elements, we can then shrink the sordedKeys array."]
[Fixed Code: "// introducing zero elements, we can then shrink the sortedKeys array."]
Note: Another typo correction without security implications.
The main changes appear to be:
1. Adding a new helper function getInitialShape()
2. Fixing two typos in comments
3. Removing an unused include (vm/Shape-inl.h)
No clear security vulnerabilities were identified in this diff, though the addition of getInitialShape() might be related to some memory safety improvements (this is uncertain without more context).
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.canvas.transparent.2.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.canvas.transparent.2.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 offscreenCanvas2 = new OffscreenCanvas(100, 50); var ctx2 = offscreenCanvas2.getContext('2d');@@ -29,9 +29,9 @@ ctx.drawImage(offscreenCanvas2, 50, -50); ctx.shadowColor = '#f00'; ctx.drawImage(offscreenCanvas2, -50, -50);-_assertPixel(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");-_assertPixel(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255");+_assertPixel(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");+_assertPixel(canvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255"); t.done(); });
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable name refactoring (renaming `offscreenCanvas` to `canvas`) and corresponding updates to assertions, without any security implications.
Here's the structured response:
Vulnerability Existed: no
No security vulnerability found [File] [Lines 13-29]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255");
The changes are purely cosmetic/refactoring in nature and don't address any security issues. The functionality remains the same, only variable names were changed for consistency or clarity.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/browser/components/enterprisepolicies/tests/xpcshell/test_simple_pref_policies.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/components/enterprisepolicies/tests/xpcshell/test_simple_pref_policies.js@@ -723,12 +723,36 @@ policies: { PDFjs: { Enabled: false,+ },+ },+ lockedPrefs: {+ "pdfjs.disabled": true,+ },+ },++ {+ policies: {+ PDFjs: {+ Enabled: true, EnablePermissions: true, }, }, lockedPrefs: {- "pdfjs.disabled": true,+ "pdfjs.disabled": false, "pdfjs.enablePermissions": true,+ },+ },++ {+ policies: {+ PDFjs: {+ Enabled: true,+ EnablePermissions: false,+ },+ },+ lockedPrefs: {+ "pdfjs.disabled": false,+ "pdfjs.enablePermissions": false, }, },
Based on the provided diff, I'll analyze it for potential security vulnerabilities:
1. Vulnerability Existed: not sure
[Potential Configuration Bypass] [browser/components/enterprisepolicies/tests/xpcshell/test_simple_pref_policies.js] [Lines 723-740]
[Old Code]
```javascript
policies: {
PDFjs: {
Enabled: false,
EnablePermissions: true,
},
},
lockedPrefs: {
"pdfjs.disabled": true,
"pdfjs.enablePermissions": true,
},
```
[Fixed Code]
```javascript
policies: {
PDFjs: {
Enabled: false,
},
},
lockedPrefs: {
"pdfjs.disabled": true,
},
```
2. Vulnerability Existed: not sure
[Potential Inconsistent Policy Enforcement] [browser/components/enterprisepolicies/tests/xpcshell/test_simple_pref_policies.js] [Lines 723-740]
[Old Code]
Only had one test case for PDF.js policy
[Fixed Code]
Added multiple test cases with different combinations of PDF.js settings (Enabled/Disabled with different permission settings)
Note: While this appears to be test file changes that improve policy testing coverage, I can't be certain if these changes were made in response to actual vulnerabilities or just for improved testing. The changes ensure proper testing of different PDF.js policy combinations, which could help prevent security misconfigurations in the actual 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/tools/tryselect/selectors/scriptworker.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/tools/tryselect/selectors/scriptworker.py@@ -6,8 +6,8 @@ import sys import requests+from taskgraph.parameters import Parameters-from gecko_taskgraph.parameters import Parameters from gecko_taskgraph.util.taskcluster import find_task_id, get_artifact, get_session from gecko_taskgraph.util.taskgraph import find_existing_tasks
Let me analyze the code diff for potential security vulnerabilities. Vulnerability Existed: not sure Dependency Confusion Attack Potential [File] tools/tryselect/selectors/scriptworker.py [Lines] 6-8 [Old Code] import requests from gecko_taskgraph.parameters import Parameters [Fixed Code] import requests from taskgraph.parameters import Parameters Additional Details: - The change involves switching the import from `gecko_taskgraph.parameters` to `taskgraph.parameters` - This could potentially be related to preventing dependency confusion attacks if the old import was pointing to a less secure or potentially spoofable package - However, without more context about the package sources and configurations, I can't be certain if this was an actual security fix or just a refactoring - The change aligns with security best practices of using well-maintained, canonical package imports Note: There doesn't appear to be any other obvious security vulnerabilities in this diff. The rest of the changes seem to be import reorganizations without direct 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.