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/layout/reftests/css-grid/grid-fragmentation-007-ref.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/layout/reftests/css-grid/grid-fragmentation-007-ref.html@@ -21,7 +21,7 @@ -ms-column-fill: auto; -webkit-column-fill: auto; column-fill: auto;- border: 2px dashed;+ border: 2px solid salmon; margin-bottom: 5px; }
After analyzing the provided code diff, here's the security assessment: Vulnerability Existed: no No security vulnerability found [File] layout/reftests/css-grid/grid-fragmentation-007-ref.html [Lines] 21 [Old Code] `border: 2px dashed;` [Fixed Code] `border: 2px solid salmon;` Additional Details: The change appears to be purely cosmetic/visual, modifying the border style from dashed to solid and adding a color (salmon). There's no indication of any security vulnerability being fixed in this change. The modification seems related to test rendering rather than security concerns.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/CSS2/css21-errata/s-11-1-1b-002.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/CSS2/css21-errata/s-11-1-1b-002.html@@ -2,7 +2,6 @@ <title>CSS Test: overflow:hidden on table with bottom caption overflowing downwards</title> <link rel="author" title="Simon Pieters" href="mailto:[email protected]"> <link rel="help" href="http://www.w3.org/Style/css2-updates/REC-CSS2-20110607-errata.html#s.11.1.1b">-<meta name="flags" content=""> <meta name="assert" content="Test checks that overflow:hidden on table applies to the table box rather than the table wrapper box."> <link rel="match" href="s-11-1-1b-002-ref.html"> <style>
Based on the provided diff, here's the analysis: Vulnerability Existed: no No Security Vulnerability Found [File] testing/web-platform/tests/css/CSS2/css21-errata/s-11-1-1b-002.html [Lines] 2-7 [Old Code] ```html <meta name="flags" content=""> ``` [Fixed Code] ```html (removed line) ``` Additional Details: The change simply removes an empty meta tag for "flags" which appears to be test-related metadata. This doesn't appear to be a security fix but rather a cleanup or test configuration change. There's no indication of any security vulnerability being addressed in this change.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/dom/canvas/test/test_toDataURL_parameters.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/canvas/test/test_toDataURL_parameters.html@@ -4,13 +4,13 @@ <link rel="stylesheet" href="/tests/SimpleTest/test.css"> <body> <p>-This test covers the JPEG quality parameter. If (when) the HTML5 spec changes the+This test covers the JPEG and webp quality parameter. If (when) the HTML5 spec changes the allowed parameters for ToDataURL, new tests should go here. </p> <canvas id="c" width="100" height="100"><p class="fallback">FAIL (fallback content)</p></canvas> <script>-var canvas = document.getElementById('c');-var ctx = canvas.getContext("2d");+let canvas = document.getElementById('c');+let ctx = canvas.getContext("2d"); ctx.strokeStyle = '#FF0000'; ctx.fillStyle = '#00FF00';@@ -20,35 +20,44 @@ ctx.lineTo(90, 90); ctx.stroke();-var pngData = canvas.toDataURL('image/png');-var pngQuality = canvas.toDataURL('image/png', 0.1);+let pngData = canvas.toDataURL('image/png');+let pngQuality = canvas.toDataURL('image/png', 0.1); is(pngQuality, pngData, "Quality is not supported for PNG images");-var data = canvas.toDataURL('image/jpeg');-if (data.match(/^data:image\/jpeg[;,]/)) {- // Test the JPEG quality parameter- - var fullQuality = canvas.toDataURL('image/jpeg', 1.0);- var lowQuality = canvas.toDataURL('image/jpeg', 0.1);- isnot(lowQuality, fullQuality, "A low quality (0.1) should differ from high quality (1.0)");- - var medQuality = canvas.toDataURL('image/jpeg', 0.5);- isnot(medQuality, fullQuality, "A medium quality (0.5) should differ from high (1.0)");- isnot(medQuality, lowQuality, "A medium quality (0.5) should differ from low (0.5)");- - var tooHigh = canvas.toDataURL('image/jpeg', 2.0);- is(tooHigh, data, "Quality above 1.0 is treated as unspecified");- - var tooLow = canvas.toDataURL('image/jpeg', -1.0);- is(tooLow, data, "Quality below 0.0 is treated as unspecified");- - var lowQualityExtra = canvas.toDataURL('image/jpeg', 0.1, 'foo', 'bar', null);- is(lowQualityExtra, lowQuality, "Quality applies even if extra arguments are present");- - var lowQualityUppercase = canvas.toDataURL('IMAGE/JPEG', 0.1);- is(lowQualityUppercase, lowQuality, "Quality applies to image/jpeg regardless of case");- - var lowQualityString = canvas.toDataURL('image/jpeg', '0.1');- isnot(lowQualityString, lowQuality, "Quality must be a number (should not be a string)");+function checkType(imagetype) {+ let imageTypeString = 'image/' + imagetype;+ let imageTypeUpperString = 'IMAGE/' + imagetype.toUpperCase();+ let data = canvas.toDataURL(imageTypeString);+ if (data.match(new RegExp('^data:image\/' + imagetype + '[;,]'))) {+ // Test the JPEG/wepb quality parameter++ let fullQuality = canvas.toDataURL(imageTypeString, 1.0);+ let lowQuality = canvas.toDataURL(imageTypeString, 0.1);+ isnot(lowQuality, fullQuality, "A low quality (0.1) should differ from high quality (1.0) " + imageTypeString);++ let medQuality = canvas.toDataURL(imageTypeString, 0.5);+ isnot(medQuality, fullQuality, "A medium quality (0.5) should differ from high (1.0) " + imageTypeString);+ isnot(medQuality, lowQuality, "A medium quality (0.5) should differ from low (0.5) " + imageTypeString);++ let tooHigh = canvas.toDataURL(imageTypeString, 2.0);+ is(tooHigh, data, "Quality above 1.0 is treated as unspecified " + imageTypeString);++ let tooLow = canvas.toDataURL(imageTypeString, -1.0);+ is(tooLow, data, "Quality below 0.0 is treated as unspecified " + imageTypeString);++ let lowQualityExtra = canvas.toDataURL(imageTypeString, 0.1, 'foo', 'bar', null);+ is(lowQualityExtra, lowQuality, "Quality applies even if extra arguments are present " + imageTypeString);++ let lowQualityUppercase = canvas.toDataURL(imageTypeUpperString, 0.1);+ is(lowQualityUppercase, lowQuality, "Quality applies to " + imageTypeString + " regardless of case");++ let lowQualityString = canvas.toDataURL(imageTypeString, '0.1');+ isnot(lowQualityString, lowQuality, "Quality must be a number (should not be a string) " + imageTypeString);+ } else {+ ok(false, "should get a data url " + imageTypeString);+ } }++checkType('jpeg');+checkType('webp'); </script>
After analyzing the provided code diff, I don't find any clear security vulnerabilities being fixed. The changes appear to be primarily about: 1. Adding support for WebP image format testing alongside JPEG 2. Refactoring the test code into a reusable function 3. Changing `var` to `let` for variable declarations 4. General test improvements and maintenance Here's the structured response: Vulnerability Existed: no No specific vulnerability found [File] dom/canvas/test/test_toDataURL_parameters.html [Lines] 4-60 [Old Code] The original test code that only tested JPEG quality parameters [Fixed Code] Refactored code that tests both JPEG and WebP quality parameters using a shared function The changes appear to be test improvements rather than security fixes. The modifications: 1. Add WebP format testing 2. Make the code more maintainable by reducing duplication 3. Improve variable scoping (var → let) 4. Keep all the same test cases but make them work for both formats No security vulnerabilities are being addressed in this diff. The changes are focused on test coverage and code quality improvements.
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/cache/test/mochitest/driver.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/cache/test/mochitest/driver.js@@ -17,7 +17,16 @@ // when the returned promise is resolved. function runTests(testFile, order) {- function setupPrefs() {+ async function setupPrefs() {+ // Bug 1746646: Make mochitests work with TCP enabled (cookieBehavior = 5)+ // Acquire storage access permission here so that the Cache API is avaialable+ SpecialPowers.wrap(document).notifyUserGestureActivation();+ await SpecialPowers.addPermission(+ "storageAccessAPI",+ true,+ window.location.href+ );+ await SpecialPowers.wrap(document).requestStorageAccess(); return SpecialPowers.pushPrefEnv({ set: [ ["dom.caches.enabled", true],@@ -31,13 +40,21 @@ // adapted from dom/indexedDB/test/helpers.js function clearStorage() {- return new Promise(function(resolve, reject) {+ var clearUnpartitionedStorage = new Promise(function(resolve, reject) { var qms = SpecialPowers.Services.qms; var principal = SpecialPowers.wrap(document).nodePrincipal; var request = qms.clearStoragesForPrincipal(principal); var cb = SpecialPowers.wrapCallback(resolve); request.callback = cb; });+ var clearPartitionedStorage = new Promise(function(resolve, reject) {+ var qms = SpecialPowers.Services.qms;+ var principal = SpecialPowers.wrap(document).partitionedPrincipal;+ var request = qms.clearStoragesForPrincipal(principal);+ var cb = SpecialPowers.wrapCallback(resolve);+ request.callback = cb;+ });+ return Promise.all([clearUnpartitionedStorage, clearPartitionedStorage]); } function loadScript(script) {
Analyzing the provided code diff, here are the security-related findings:
1. Vulnerability Existed: not sure
[Potential Storage Access Issue] [dom/cache/test/mochitest/driver.js] [Lines 17-31]
[Old Code]
```javascript
function setupPrefs() {
return SpecialPowers.pushPrefEnv({
set: [
["dom.caches.enabled", true],
["dom.serviceWorkers.enabled", true],
["dom.serviceWorkers.testing.enabled", true],
],
});
}
```
[Fixed Code]
```javascript
async function setupPrefs() {
// Bug 1746646: Make mochitests work with TCP enabled (cookieBehavior = 5)
// Acquire storage access permission here so that the Cache API is avaialable
SpecialPowers.wrap(document).notifyUserGestureActivation();
await SpecialPowers.addPermission(
"storageAccessAPI",
true,
window.location.href
);
await SpecialPowers.wrap(document).requestStorageAccess();
return SpecialPowers.pushPrefEnv({
set: [
["dom.caches.enabled", true],
["dom.serviceWorkers.enabled", true],
["dom.serviceWorkers.testing.enabled", true],
],
});
}
```
Additional Details: The fix adds storage access permission handling, which might relate to security but appears to be more of a test environment setup change.
2. Vulnerability Existed: not sure
[Potential Storage Clearing Issue] [dom/cache/test/mochitest/driver.js] [Lines 40-53]
[Old Code]
```javascript
function clearStorage() {
return new Promise(function(resolve, reject) {
var qms = SpecialPowers.Services.qms;
var principal = SpecialPowers.wrap(document).nodePrincipal;
var request = qms.clearStoragesForPrincipal(principal);
var cb = SpecialPowers.wrapCallback(resolve);
request.callback = cb;
});
}
```
[Fixed Code]
```javascript
function clearStorage() {
var clearUnpartitionedStorage = new Promise(function(resolve, reject) {
var qms = SpecialPowers.Services.qms;
var principal = SpecialPowers.wrap(document).nodePrincipal;
var request = qms.clearStoragesForPrincipal(principal);
var cb = SpecialPowers.wrapCallback(resolve);
request.callback = cb;
});
var clearPartitionedStorage = new Promise(function(resolve, reject) {
var qms = SpecialPowers.Services.qms;
var principal = SpecialPowers.wrap(document).partitionedPrincipal;
var request = qms.clearStoragesForPrincipal(principal);
var cb = SpecialPowers.wrapCallback(resolve);
request.callback = cb;
});
return Promise.all([clearUnpartitionedStorage, clearPartitionedStorage]);
}
```
Additional Details: The change adds clearing of partitioned storage, which might relate to security but appears to be more of a test completeness improvement.
Note: Both changes appear to be test-related improvements rather than direct security fixes, but they do touch on security-related concepts (storage access and clearing). The changes were likely made to ensure proper test functionality in more secure browser configurations.
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/textwrap/README.md+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/textwrap/README.md@@ -1,43 +1,31 @@ # Textwrap+[][build-status]+[][codecov] [][crates-io] [][api-docs]-[][travis-ci]-[][appveyor]-[][codecov]-Textwrap is a small Rust crate for word wrapping text. You can use it-to format strings for display in commandline applications. The crate-name and interface is inspired by-the [Python textwrap module][py-textwrap].+Textwrap is a library for wrapping and indenting text. It is most+often used by command-line programs to format dynamic output nicely so+it looks good in a terminal. You can also use Textwrap to wrap text+set in a proportional font—such as text used to generate PDF files, or+drawn on a [HTML5 canvas using WebAssembly][wasm-demo]. ## Usage-Add this to your `Cargo.toml`:+To use the textwrap crate, add this to your `Cargo.toml` file: ```toml [dependencies]-textwrap = "0.11"+textwrap = "0.14" ```-and this to your crate root:-```rust-extern crate textwrap;-```--If you would like to have automatic hyphenation, specify the-dependency as:-```toml-[dependencies]-textwrap = { version = "0.11", features = ["hyphenation"] }-```--To conveniently wrap text at the current terminal width, enable the-`term_size` feature:--```toml-[dependencies]-textwrap = { version = "0.11", features = ["term_size"] }-```+By default, this enables word wrapping with support for Unicode+strings. Extra features can be enabled with Cargo features—and the+Unicode support can be disabled if needed. This allows you slim down+the library and so you will only pay for the features you actually+use. Please see the [_Cargo Features_ in the crate+documentation](https://docs.rs/textwrap/#cargo-features) for a full+list of the available features. ## Documentation@@ -45,263 +33,112 @@ ## Getting Started-Word wrapping single strings is easy using the `fill` function:+Word wrapping is easy using the `fill` function:+ ```rust-extern crate textwrap;-use textwrap::fill;- fn main() {- let text = "textwrap: a small library for wrapping text.";- println!("{}", fill(text, 18));+ let text = "textwrap: an efficient and powerful library for wrapping text.";+ println!("{}", textwrap::fill(text, 28)); } ```-The output is++The output is wrapped within 28 columns:+ ```-textwrap: a small-library for+textwrap: an efficient+and powerful library for wrapping text. ```-With the `hyphenation` feature, you can get automatic hyphenation-for [about 70 languages][patterns]. Your program must load and-configure the hyphenation patterns to use:+Sharp-eyed readers will notice that the first line is 22 columns wide.+So why is the word “and” put in the second line when there is space+for it in the first line?++The explanation is that textwrap does not just wrap text one line at a+time. Instead, it uses an optimal-fit algorithm which looks ahead and+chooses line breaks which minimize the gaps left at ends of lines.++Without look-ahead, the first line would be longer and the text would+look like this:++```+textwrap: an efficient and+powerful library for+wrapping text.+```++The second line is now shorter and the text is more ragged. The kind+of wrapping can be configured via `Options::wrap_algorithm`.++If you enable the `hyphenation` Cargo feature, you get support for+automatic hyphenation for [about 70 languages][patterns] via+high-quality TeX hyphenation patterns.++Your program must load the hyphenation pattern and configure+`Options::word_splitter` to use it:+ ```rust-extern crate hyphenation;-extern crate textwrap;- use hyphenation::{Language, Load, Standard};-use textwrap::Wrapper;+use textwrap::Options; fn main() { let hyphenator = Standard::from_embedded(Language::EnglishUS).unwrap();- let wrapper = Wrapper::with_splitter(18, hyphenator);- let text = "textwrap: a small library for wrapping text.";- println!("{}", wrapper.fill(text))+ let options = Options::new(28).word_splitter(hyphenator);+ let text = "textwrap: an efficient and powerful library for wrapping text.";+ println!("{}", fill(text, &options); } ``` The output now looks like this: ```-textwrap: a small-library for wrap-+textwrap: an efficient and+powerful library for wrap- ping text. ```-The hyphenation uses high-quality TeX hyphenation patterns.+The US-English hyphenation patterns are embedded when you enable the+`hyphenation` feature. They are licensed under a [permissive+license][en-us license] and take up about 88 KB in your binary. If you+need hyphenation for other languages, you need to download a+[precompiled `.bincode` file][bincode] and load it yourself. Please+see the [`hyphenation` documentation] for details.++## Wrapping Strings at Compile Time++If your strings are known at compile time, please take a look at the+procedural macros from the [`textwrap-macros` crate]. ## Examples-The library comes with some small example programs that shows various-features.+The library comes with [a+collection](https://github.com/mgeisler/textwrap/tree/master/examples)+of small example programs that shows various features.-### Layout Example+If you want to see Textwrap in action right away, then take a look at+[`examples/wasm/`], which shows how to wrap sans-serif, serif, and+monospace text. It uses WebAssembly and is automatically deployed to+https://mgeisler.github.io/textwrap/.-The `layout` example shows how a fixed example string is wrapped at-different widths. Run the example with:+For the command-line examples, you’re invited to clone the repository+and try them out for yourself! Of special note is+[`examples/interactive.rs`]. This is a demo program which demonstrates+most of the available features: you can enter text and adjust the+width at which it is wrapped interactively. You can also adjust the+`Options` used to see the effect of different `WordSplitter`s and wrap+algorithms.-```shell-$ cargo run --features hyphenation --example layout+Run the demo with++```sh+$ cargo run --example interactive ```-The program will use the following string:--> Memory safety without garbage collection. Concurrency without data-> races. Zero-cost abstractions.--The string is wrapped at all widths between 15 and 60 columns. With-narrow columns the output looks like this:--```-.--- Width: 15 ---.-| Memory safety |-| without garbage |-| collection. |-| Concurrency |-| without data |-| races. Zero- |-| cost abstrac- |-| tions. |-.--- Width: 16 ----.-| Memory safety |-| without garbage |-| collection. Con- |-| currency without |-| data races. Ze- |-| ro-cost abstrac- |-| tions. |-```--Later, longer lines are used and the output now looks like this:--```-.-------------------- Width: 49 --------------------.-| Memory safety without garbage collection. Concur- |-| rency without data races. Zero-cost abstractions. |-.---------------------- Width: 53 ----------------------.-| Memory safety without garbage collection. Concurrency |-| without data races. Zero-cost abstractions. |-.------------------------- Width: 59 -------------------------.-| Memory safety without garbage collection. Concurrency with- |-| out data races. Zero-cost abstractions. |-```--Notice how words are split at hyphens (such as "zero-cost") but also-how words are hyphenated using automatic/machine hyphenation.--### Terminal Width Example--The `termwidth` example simply shows how the width can be set-automatically to the current terminal width. Run it with this command:--```-$ cargo run --example termwidth-```--If you run it in a narrow terminal, you'll see output like this:-```-Formatted in within 60 columns:------Memory safety without garbage collection. Concurrency-without data races. Zero-cost abstractions.------```--If `stdout` is not connected to the terminal, the program will use a-default of 80 columns for the width:--```-$ cargo run --example termwidth | cat-Formatted in within 80 columns:------Memory safety without garbage collection. Concurrency without data races. Zero--cost abstractions.------```+The demo needs a Linux terminal to function. ## Release History-This section lists the largest changes per release.--### Version 0.11.0 — December 9th, 2018--Due to our dependencies bumping their minimum supported version of-Rust, the minimum version of Rust we test against is now 1.22.0.--* Merged [#141][issue-141]: Fix `dedent` handling of empty lines and- trailing newlines. Thanks @bbqsrc!-* Fixed [#151][issue-151]: Release of version with hyphenation 0.7.--### Version 0.10.0 — April 28th, 2018--Due to our dependencies bumping their minimum supported version of-Rust, the minimum version of Rust we test against is now 1.17.0.--* Fixed [#99][issue-99]: Word broken even though it would fit on line.-* Fixed [#107][issue-107]: Automatic hyphenation is off by one.-* Fixed [#122][issue-122]: Take newlines into account when wrapping.-* Fixed [#129][issue-129]: Panic on string with em-dash.--### Version 0.9.0 — October 5th, 2017--The dependency on `term_size` is now optional, and by default this-feature is not enabled. This is a *breaking change* for users of-`Wrapper::with_termwidth`. Enable the `term_size` feature to restore-the old functionality.--Added a regression test for the case where `width` is set to-`usize::MAX`, thanks @Fraser999! All public structs now implement-`Debug`, thanks @hcpl!--* Fixed [#101][issue-101]: Make `term_size` an optional dependency.--### Version 0.8.0 — September 4th, 2017--The `Wrapper` stuct is now generic over the type of word splitter-being used. This means less boxing and a nicer API. The-`Wrapper::word_splitter` method has been removed. This is a *breaking-API change* if you used the method to change the word splitter.--The `Wrapper` struct has two new methods that will wrap the input text-lazily: `Wrapper::wrap_iter` and `Wrapper::into_wrap_iter`. Use those-if you will be iterating over the wrapped lines one by one.--* Fixed [#59][issue-59]: `wrap` could return an iterator. Thanks- @hcpl!-* Fixed [#81][issue-81]: Set `html_root_url`.--### Version 0.7.0 — July 20th, 2017--Version 0.7.0 changes the return type of `Wrapper::wrap` from-`Vec<String>` to `Vec<Cow<'a, str>>`. This means that the output lines-borrow data from the input string. This is a *breaking API change* if-you relied on the exact return type of `Wrapper::wrap`. Callers of the-`textwrap::fill` convenience function will see no breakage.--The above change and other optimizations makes version 0.7.0 roughly-15-30% faster than version 0.6.0.--The `squeeze_whitespace` option has been removed since it was-complicating the above optimization. Let us know if this option is-important for you so we can provide a work around.--* Fixed [#58][issue-58]: Add a "fast_wrap" function.-* Fixed [#61][issue-61]: Documentation errors.--### Version 0.6.0 — May 22nd, 2017--Version 0.6.0 adds builder methods to `Wrapper` for easy one-line-initialization and configuration:--```rust-let wrapper = Wrapper::new(60).break_words(false);-```--It also add a new `NoHyphenation` word splitter that will never split-words, not even at existing hyphens.--* Fixed [#28][issue-28]: Support not squeezing whitespace.--### Version 0.5.0 — May 15th, 2017--Version 0.5.0 has *breaking API changes*. However, this only affects-code using the hyphenation feature. The feature is now optional, so-you will first need to enable the `hyphenation` feature as described-above. Afterwards, please change your code from-```rust-wrapper.corpus = Some(&corpus);-```-to-```rust-wrapper.splitter = Box::new(corpus);-```--Other changes include optimizations, so version 0.5.0 is roughly-10-15% faster than version 0.4.0.--* Fixed [#19][issue-19]: Add support for finding terminal size.-* Fixed [#25][issue-25]: Handle words longer than `self.width`.-* Fixed [#26][issue-26]: Support custom indentation.-* Fixed [#36][issue-36]: Support building without `hyphenation`.-* Fixed [#39][issue-39]: Respect non-breaking spaces.--### Version 0.4.0 — January 24th, 2017--Documented complexities and tested these via `cargo bench`.--* Fixed [#13][issue-13]: Immediatedly add word if it fits.-* Fixed [#14][issue-14]: Avoid splitting on initial hyphens.--### Version 0.3.0 — January 7th, 2017--Added support for automatic hyphenation.--### Version 0.2.0 — December 28th, 2016--Introduced `Wrapper` struct. Added support for wrapping on hyphens.--### Version 0.1.0 — December 17th, 2016--First public release with support for wrapping strings on whitespace.+Please see the [CHANGELOG file] for details on the changes made in+each release. ## License@@ -309,29 +146,18 @@ Contributions will be accepted under the same license. [crates-io]: https://crates.io/crates/textwrap-[travis-ci]: https://travis-ci.org/mgeisler/textwrap-[appveyor]: https://ci.appveyor.com/project/mgeisler/textwrap+[build-status]: https://github.com/mgeisler/textwrap/actions?query=workflow%3Abuild+branch%3Amaster [codecov]: https://codecov.io/gh/mgeisler/textwrap-[py-textwrap]: https://docs.python.org/library/textwrap+[wasm-demo]: https://mgeisler.github.io/textwrap/+[`textwrap-macros` crate]: https://crates.io/crates/textwrap-macros+[`hyphenation` example]: https://github.com/mgeisler/textwrap/blob/master/examples/hyphenation.rs+[`termwidth` example]: https://github.com/mgeisler/textwrap/blob/master/examples/termwidth.rs [patterns]: https://github.com/tapeinosyne/hyphenation/tree/master/patterns-tex+[en-us license]: https://github.com/hyphenation/tex-hyphen/blob/master/hyph-utf8/tex/generic/hyph-utf8/patterns/tex/hyph-en-us.tex+[bincode]: https://github.com/tapeinosyne/hyphenation/tree/master/dictionaries+[`hyphenation` documentation]: http://docs.rs/hyphenation+[`examples/wasm/`]: https://github.com/mgeisler/textwrap/tree/master/examples/wasm+[`examples/interactive.rs`]: https://github.com/mgeisler/textwrap/tree/master/examples/interactive.rs [api-docs]: https://docs.rs/textwrap/-[issue-13]: https://github.com/mgeisler/textwrap/issues/13-[issue-14]: https://github.com/mgeisler/textwrap/issues/14-[issue-19]: https://github.com/mgeisler/textwrap/issues/19-[issue-25]: https://github.com/mgeisler/textwrap/issues/25-[issue-26]: https://github.com/mgeisler/textwrap/issues/26-[issue-28]: https://github.com/mgeisler/textwrap/issues/28-[issue-36]: https://github.com/mgeisler/textwrap/issues/36-[issue-39]: https://github.com/mgeisler/textwrap/issues/39-[issue-58]: https://github.com/mgeisler/textwrap/issues/58-[issue-59]: https://github.com/mgeisler/textwrap/issues/59-[issue-61]: https://github.com/mgeisler/textwrap/issues/61-[issue-81]: https://github.com/mgeisler/textwrap/issues/81-[issue-99]: https://github.com/mgeisler/textwrap/issues/99-[issue-101]: https://github.com/mgeisler/textwrap/issues/101-[issue-107]: https://github.com/mgeisler/textwrap/issues/107-[issue-122]: https://github.com/mgeisler/textwrap/issues/122-[issue-129]: https://github.com/mgeisler/textwrap/issues/129-[issue-141]: https://github.com/mgeisler/textwrap/issues/141-[issue-151]: https://github.com/mgeisler/textwrap/issues/151+[CHANGELOG file]: https://github.com/mgeisler/textwrap/blob/master/CHANGELOG.md [mit]: LICENSE
After analyzing the provided code diff, I don't find any security vulnerabilities being fixed. The changes appear to be documentation updates, version updates, and feature description changes for the textwrap Rust crate.
Here's the structured response:
Vulnerability Existed: no
No security vulnerabilities found in documentation update [third_party/rust/textwrap/README.md] [All lines]
[Old documentation content]
[Updated documentation content]
The diff shows:
1. Updated badges/CI information at the top
2. Rewritten feature descriptions and usage examples
3. Version number updates (from 0.11 to 0.14)
4. Improved documentation structure and explanations
5. Removal of old release history in favor of CHANGELOG reference
These are all documentation improvements rather than security fixes. No code changes or vulnerability fixes are present in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/dom/base/Document.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/base/Document.cpp@@ -11924,7 +11924,6 @@ } clone->mIsSrcdocDocument = mIsSrcdocDocument;- clone->SetContainer(mDocumentContainer); // Setup the navigation time. This will be needed by any animations in the@@ -11949,7 +11948,11 @@ clone->SetChromeXHRDocURI(mChromeXHRDocURI); clone->SetPrincipals(NodePrincipal(), mPartitionedPrincipal); clone->mActiveStoragePrincipal = mActiveStoragePrincipal;- clone->mDocumentBaseURI = mDocumentBaseURI;+ // NOTE(emilio): Intentionally setting this to the GetDocBaseURI rather than+ // just mDocumentBaseURI, so that srcdoc iframes get the right base URI even+ // when printed standalone via window.print() (where there won't be a parent+ // document to grab the URI from).+ clone->mDocumentBaseURI = GetDocBaseURI(); clone->SetChromeXHRDocBaseURI(mChromeXHRDocBaseURI); clone->mReferrerInfo = static_cast<dom::ReferrerInfo*>(mReferrerInfo.get())->Clone();@@ -13564,13 +13567,15 @@ } }- void ResolvedCallback(JSContext* aCx, JS::Handle<JS::Value> aValue) override {+ void ResolvedCallback(JSContext* aCx, JS::Handle<JS::Value> aValue,+ ErrorResult& aRv) override { MaybeUnblockParser(); mPromise->MaybeResolve(aValue); }- void RejectedCallback(JSContext* aCx, JS::Handle<JS::Value> aValue) override {+ void RejectedCallback(JSContext* aCx, JS::Handle<JS::Value> aValue,+ ErrorResult& aRv) override { MaybeUnblockParser(); mPromise->MaybeReject(aValue);@@ -14564,9 +14569,14 @@ void Document::GetWireframe(bool aIncludeNodes, Nullable<Wireframe>& aWireframe) {+ FlushPendingNotifications(FlushType::Layout);+ GetWireframeWithoutFlushing(aIncludeNodes, aWireframe);+}++void Document::GetWireframeWithoutFlushing(bool aIncludeNodes,+ Nullable<Wireframe>& aWireframe) { using FrameForPointOptions = nsLayoutUtils::FrameForPointOptions; using FrameForPointOption = nsLayoutUtils::FrameForPointOption;- FlushPendingNotifications(FlushType::Layout); PresShell* shell = GetPresShell(); if (!shell) {@@ -14600,7 +14610,7 @@ if (!rects.SetCapacity(frames.Length(), fallible)) { return; }- for (nsIFrame* frame : frames) {+ for (nsIFrame* frame : Reversed(frames)) { // Can't really fail because SetCapacity succeeded. auto& taggedRect = *rects.AppendElement(fallible); const auto r =@@ -14611,8 +14621,10 @@ taggedRect.mNode.Construct(c); } }- taggedRect.mRect.Construct(MakeRefPtr<DOMRectReadOnly>(- ToSupports(this), r.x, r.y, r.width, r.height));+ taggedRect.mX = r.x;+ taggedRect.mY = r.y;+ taggedRect.mWidth = r.width;+ taggedRect.mHeight = r.height; taggedRect.mType.Construct() = [&] { if (frame->IsTextFrame()) { nsStyleUtil::GetSerializedColorValue(
Here's the security analysis following the specified format: 1. Vulnerability Existed: yes Cross-origin Information Disclosure [File] dom/base/Document.cpp [Lines 11949] [Old Code] clone->mDocumentBaseURI = mDocumentBaseURI; [Fixed Code] clone->mDocumentBaseURI = GetDocBaseURI(); Additional Details: The fix ensures srcdoc iframes get the correct base URI when printed standalone via window.print(), preventing potential cross-origin information disclosure by not inheriting the parent document's base URI. 2. Vulnerability Existed: not sure Potential Promise Handling Issue [File] dom/base/Document.cpp [Lines 13564-13579] [Old Code] void ResolvedCallback(JSContext* aCx, JS::Handle<JS::Value> aValue) override void RejectedCallback(JSContext* aCx, JS::Handle<JS::Value> aValue) override [Fixed Code] void ResolvedCallback(JSContext* aCx, JS::Handle<JS::Value> aValue, ErrorResult& aRv) override void RejectedCallback(JSContext* aCx, JS::Handle<JS::Value> aValue, ErrorResult& aRv) override Additional Details: The change adds ErrorResult parameter to promise callbacks, which might be related to better error handling, but it's unclear if this fixes a specific security vulnerability. 3. Vulnerability Existed: not sure Layout Flush Timing Issue [File] dom/base/Document.cpp [Lines 14564-14621] [Old Code] Single GetWireframe method with flush inside [Fixed Code] Split into GetWireframe (with flush) and GetWireframeWithoutFlushing Additional Details: The change separates layout flushing from wireframe generation, which could potentially prevent timing attacks or layout-based side channels, but the security impact isn't explicitly stated. 4. Vulnerability Existed: not sure Potential Information Disclosure [File] dom/base/Document.cpp [Lines 14600-14621] [Old Code] taggedRect.mRect.Construct(MakeRefPtr<DOMRectReadOnly>(...)) [Fixed Code] Direct assignment of coordinates (mX, mY, mWidth, mHeight) Additional Details: The change in how rectangle coordinates are stored might be related to preventing information leaks through object references, but the security implications aren't clear 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/testing/web-platform/tests/html/canvas/offscreen/text/2d.text.drawing.style.measure.textAlign.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/text/2d.text.drawing.style.measure.textAlign.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.textAlign = "right"; metrics = ctx.measureText('hello');
Based on the provided diff, I'll analyze it for security vulnerabilities:
1. Vulnerability Existed: no
No security vulnerability found [File] [Lines 13-14]
Old Code:
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
Fixed Code:
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
Additional Details:
- The change appears to be purely a variable name refactoring from `offscreenCanvas` to `canvas`
- No security-related changes are evident in this diff
- The functionality remains exactly the same, only the variable name was changed
- This is likely a code style/readability improvement rather than a security fix
No actual security vulnerabilities were addressed in this diff. The change is cosmetic in nature and doesn't affect the security properties of the code.
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-break/widows-orphans-017.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-break/widows-orphans-017.html@@ -13,7 +13,6 @@ Last modified: December 6th 2020 -->- <meta name="flags" content=""> <meta name="assert" content="If a multi-column container fills column boxes sequentially and its 'height' is 'auto', then soft breaks are inoperative since content can not overflow the fragmentainer. Therefore, in this test, the 'orphans' and 'widows' requirements can not be honored."> <style>
Based on the provided diff, I'll analyze it for security fixes: Vulnerability Existed: no [No specific vulnerability] [testing/web-platform/tests/css/css-break/widows-orphans-017.html] [Lines 13] [Old Code: <meta name="flags" content="">] [Fixed Code: (removed)] Additional details: 1. This appears to be a test file modification rather than a security fix 2. The change simply removes an empty meta tag for "flags" which doesn't appear to have security implications 3. No known vulnerability is being addressed here 4. The modification seems related to test configuration rather than security The change is more likely related to test cleanup or maintenance rather than addressing any security issue. The empty "flags" meta tag was removed, but this doesn't correspond to any known security vulnerability pattern.
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-contain/contain-strict-003.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-contain/contain-strict-003.html@@ -8,7 +8,6 @@ <link rel="help" href="https://www.w3.org/TR/css-contain-1/#contain-property"> <link rel="match" href="reference/contain-layout-size-003-ref.html">- <meta name="flags" content=""> <style> div
Analysis: 1. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/css/css-contain/contain-strict-003.html [Lines] 8 [Old Code] `<meta name="flags" content="">` [Fixed Code] (Line removed) Additional Details: The diff shows the removal of an empty meta tag with a "flags" attribute. This doesn't appear to be a security fix but rather a cleanup of unnecessary markup. No known vulnerability is associated with this change.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/layout/reftests/css-grid/grid-fragmentation-024-ref.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/layout/reftests/css-grid/grid-fragmentation-024-ref.html@@ -21,7 +21,7 @@ -ms-column-fill: auto; -webkit-column-fill: auto; column-fill: auto;- border: 2px dashed;+ border: 2px solid salmon; margin-bottom: 5px; }
After analyzing the provided code diff, I don't see any security-related fixes. The change appears to be purely cosmetic/visual, modifying the border style from dashed to solid salmon color.
Answer Format for Each Vulnerability:
Vulnerability Existed: no
No security vulnerability found [File] [Lines]
[Old Code] border: 2px dashed;
[Fixed Code] border: 2px solid salmon;
Additional Details:
- The change is purely presentational (border style/color change)
- No security implications were identified
- No known vulnerabilities are associated with this type of change
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/compositing/mix-blend-mode/mix-blend-mode-blended-element-overflow-scroll.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/compositing/mix-blend-mode/mix-blend-mode-blended-element-overflow-scroll.html@@ -7,7 +7,6 @@ <link rel="author" title="Ion Roșca" href="mailto:[email protected]"> <link rel="reviewer" title="Mihai Țică" href="mailto:[email protected]"> <link rel="help" href="https://drafts.fxtf.org/compositing-1/#mix-blend-mode">- <meta name="flags" content=""> <meta name="assert" content="Test checks that an element with mix-blend-mode and overflow:scroll blends with its parent element"> <link rel="match" href="reference/mix-blend-mode-blended-element-overflow-scroll-ref.html"> <style type="text/css">
Based on the provided code diff, I'll analyze it for potential security vulnerabilities: 1. Vulnerability Existed: no No specific vulnerability [testing/web-platform/tests/css/compositing/mix-blend-mode/mix-blend-mode-blended-element-overflow-scroll.html] [Lines 7] Old Code: `<meta name="flags" content="">` Fixed Code: (removed line) Additional Details: - The diff shows removal of an empty meta tag for "flags" which appears to be test-related metadata - This change doesn't appear to address any security vulnerability - The modification seems to be cleanup of test configuration rather than a security fix - No CVE or known vulnerability patterns are involved in this change The change is minor and doesn't indicate any security implications. It's likely just removing unused test configuration.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/toolkit/crashreporter/CrashAnnotations.yaml+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/toolkit/crashreporter/CrashAnnotations.yaml@@ -622,6 +622,12 @@ Expected to be a percentage integer value. type: integer+LinuxUnderMemoryPressure:+ description: >+ Set to true if the memory pressure watcher was under memory pressure when+ the crash occurred.+ type: boolean+ LauncherProcessState: description: > Launcher process enabled state. The integer value of this annotation must@@ -965,6 +971,11 @@ User-agent locale. type: string+UtilityProcessStatus:+ description: >+ Status of the Utility process, can be set to "Running" or "Destroyed"+ type: string+ Vendor: description: > Application vendor (e.g. Mozilla).
Analyzing the provided code diff for security fixes:
1. Vulnerability Existed: no
No specific vulnerability found [File] toolkit/crashreporter/CrashAnnotations.yaml [Lines] 622-628
[Old Code]
(No existing code for LinuxUnderMemoryPressure)
[Fixed Code]
LinuxUnderMemoryPressure:
description: >
Set to true if the memory pressure watcher was under memory pressure when
the crash occurred.
type: boolean
2. Vulnerability Existed: no
No specific vulnerability found [File] toolkit/crashreporter/CrashAnnotations.yaml [Lines] 965-970
[Old Code]
(No existing code for UtilityProcessStatus)
[Fixed Code]
UtilityProcessStatus:
description: >
Status of the Utility process, can be set to "Running" or "Destroyed"
type: string
The diff shows additions of new crash annotation fields (LinuxUnderMemoryPressure and UtilityProcessStatus) but doesn't indicate any security vulnerabilities being fixed. These appear to be enhancements to the crash reporting system by adding more diagnostic information.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/compositing/mix-blend-mode/mix-blend-mode-parent-with-border-radius.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/compositing/mix-blend-mode/mix-blend-mode-parent-with-border-radius.html@@ -10,7 +10,6 @@ <link rel="help" href="https://drafts.fxtf.org/compositing-1/#mix-blend-mode"> <meta name="assert" content="Test checks that an element with mix-blend-mode blends with the parent element having border-radius.">- <meta name="flags" content=""/> <link rel="match" href="reference/mix-blend-mode-parent-with-border-radius-ref.html"> <style type="text/css"> body {
Based on the provided diff, I'll analyze it for potential security vulnerabilities:
1. Vulnerability Existed: no
No specific vulnerability [File] [Lines 10]
[Old Code]
<meta name="flags" content=""/>
[Fixed Code]
(line removed)
Additional Details:
- The diff shows removal of an empty meta tag with "flags" attribute. This doesn't appear to be a security-related change.
- The removed line was likely just cleanup of unnecessary markup in a test file.
- No known vulnerability patterns (XSS, injection, etc.) are present in this change.
- The modification doesn't affect any security-relevant functionality.
Since this is just a test file modification removing an unused meta tag, there doesn't appear to be any security implication to this change. The "flags" meta tag is typically used for test configuration rather than security controls.
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/wgpu-core/src/present.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/wgpu-core/src/present.rs@@ -8,6 +8,8 @@ When this texture is presented, we remove it from the device tracker as well as extract it from the hub. !*/++use std::borrow::Borrow; #[cfg(feature = "trace")] use crate::device::trace::Action;@@ -125,6 +127,25 @@ let suf = A::get_surface_mut(surface); let (texture_id, status) = match unsafe { suf.raw.acquire_texture(FRAME_TIMEOUT_MS) } { Ok(Some(ast)) => {+ let clear_view_desc = hal::TextureViewDescriptor {+ label: Some("clear surface texture view"),+ format: config.format,+ dimension: wgt::TextureViewDimension::D2,+ usage: hal::TextureUses::COLOR_TARGET,+ range: wgt::ImageSubresourceRange::default(),+ };+ let mut clear_views = smallvec::SmallVec::new();+ clear_views.push(+ unsafe {+ hal::Device::create_texture_view(+ &device.raw,+ &ast.texture.borrow(),+ &clear_view_desc,+ )+ }+ .map_err(DeviceError::from)?,+ );+ let present = surface.presentation.as_mut().unwrap(); let texture = resource::Texture { inner: resource::TextureInner::Surface {@@ -149,8 +170,8 @@ hal_usage: conv::map_texture_usage(config.usage, config.format.into()), format_features: wgt::TextureFormatFeatures { allowed_usages: wgt::TextureUsages::RENDER_ATTACHMENT,- flags: wgt::TextureFormatFeatureFlags::empty(),- filterable: false,+ flags: wgt::TextureFormatFeatureFlags::MULTISAMPLE+ | wgt::TextureFormatFeatureFlags::MULTISAMPLE_RESOLVE, }, initialization_status: TextureInitTracker::new(1, 1), full_range: TextureSelector {@@ -158,6 +179,10 @@ levels: 0..1, }, life_guard: LifeGuard::new("<Surface>"),+ clear_mode: resource::TextureClearMode::RenderPass {+ clear_views,+ is_color: true,+ }, }; let ref_count = texture.life_guard.add_ref();@@ -239,6 +264,16 @@ let (texture, _) = hub.textures.unregister(texture_id.value.0, &mut token); if let Some(texture) = texture {+ if let resource::TextureClearMode::RenderPass { clear_views, .. } =+ texture.clear_mode+ {+ for clear_view in clear_views {+ unsafe {+ hal::Device::destroy_texture_view(&device.raw, clear_view);+ }+ }+ }+ let suf = A::get_surface_mut(surface); match texture.inner { resource::TextureInner::Surface {
Let me analyze the code diff for security vulnerabilities: 1. Vulnerability Existed: not sure [Potential Resource Leak] [third_party/rust/wgpu-core/src/present.rs] [Lines 125-264] [Old Code] The original code didn't properly clean up texture views when presenting surfaces. [Fixed Code] Added cleanup code for texture views in the `resource::TextureClearMode::RenderPass` case, explicitly destroying texture views when the texture is unregistered. 2. Vulnerability Existed: not sure [Potential Uninitialized Memory Access] [third_party/rust/wgpu-core/src/present.rs] [Lines 125-264] [Old Code] The original code didn't properly initialize texture view descriptors and clear modes. [Fixed Code] Added explicit texture view descriptor initialization and clear mode handling, including proper format features flags (MULTISAMPLE and MULTISAMPLE_RESOLVE). 3. Vulnerability Existed: not sure [Potential Improper Error Handling] [third_party/rust/wgpu-core/src/present.rs] [Lines 125-264] [Old Code] The original code didn't properly handle texture view creation errors. [Fixed Code] Added proper error handling with `map_err(DeviceError::from)?` when creating texture views. Note: While these changes appear to improve memory safety and error handling, without more context about the specific threat model and usage patterns, it's difficult to definitively classify these as security vulnerabilities versus general robustness improvements. The changes do address potential resource leaks and improve initialization safety, which could prevent security issues in certain scenarios.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.hsla-clamp-1.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.hsla-clamp-1.html@@ -17,14 +17,14 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillStyle = 'hsla(120, 200%, 50%, 1)'; 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 code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely cosmetic/refactoring changes (variable renaming) rather than security-related fixes.
Here's the analysis following your format:
Vulnerability Existed: no
[No security vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.hsla-clamp-1.html] [Lines 17-25]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");
The changes simply rename the variable `offscreenCanvas` to `canvas` and update its references. There are no security implications to these changes.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/devtools/server/actors/network-monitor/network-event-actor.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/server/actors/network-monitor/network-event-actor.js@@ -19,8 +19,8 @@ * @param DevToolsServerConnection conn * The connection into which this Actor will be added. * @param object sessionContext- * WatcherActor's session context. This helps know what is the overall debugged scope.- * See watcher actor constructor for more info.+ * The Session Context to help know what is debugged.+ * See devtools/server/actors/watcher/session-context.js * @param object options * Dictionary object with the following attributes: * - onNetworkEventUpdate: optional function
Based on the provided diff content, I don't see any actual security fixes or vulnerabilities being addressed. The changes appear to be documentation/comments updates only. Here's the analysis following your requested format: Vulnerability Existed: no [No security vulnerability found] [devtools/server/actors/network-monitor/network-event-actor.js] [Lines 19-22] [Old Code] * WatcherActor's session context. This helps know what is the overall debugged scope. * See watcher actor constructor for more info. [Fixed Code] * The Session Context to help know what is debugged. * See devtools/server/actors/watcher/session-context.js The changes only modify comments/documentation to be more precise about the session context and provide a more specific reference to the session-context.js file. There are no code changes that would indicate a security fix.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/xpcshell/head.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/xpcshell/head.js@@ -1565,6 +1565,7 @@ * Supported properties: * skip_if : An arrow function which has an expression to be * evaluated whether the test is skipped or not.+ * pref_set: An array of preferences to set for the test, reset at end of test. * @param func * An async function to be run only if the funcOrProperies is not a function. *@@ -1603,6 +1604,7 @@ * * add_task({ * skip_if: () => !("@mozilla.org/telephony/volume-service;1" in Components.classes),+ * pref_set: [["some.pref", "value"], ["another.pref", true]], * }, async function test_volume_service() { * let volumeService = Cc["@mozilla.org/telephony/volume-service;1"] * .getService(Ci.nsIVolumeService);@@ -1612,6 +1614,52 @@ function add_task(properties, func = properties) { return add_test(properties, func, true); }++const _setTaskPrefs = prefs => {+ for (let [pref, value] of prefs) {+ if (value === undefined) {+ // Clear any pref that didn't have a user value.+ info(`Clearing pref "${pref}"`);+ _Services.prefs.clearUserPref(pref);+ continue;+ }++ info(`Setting pref "${pref}": ${value}`);+ switch (typeof value) {+ case "boolean":+ _Services.prefs.setBoolPref(pref, value);+ break;+ case "number":+ _Services.prefs.setIntPref(pref, value);+ break;+ case "string":+ _Services.prefs.setStringPref(pref, value);+ break;+ default:+ throw new Error("runWithPrefs doesn't support this pref type yet");+ }+ }+};++const _getTaskPrefs = prefs => {+ return prefs.map(([pref, value]) => {+ info(`Getting initial pref value for "${pref}"`);+ if (!_Services.prefs.prefHasUserValue(pref)) {+ // Check if the pref doesn't have a user value.+ return [pref, undefined];+ }+ switch (typeof value) {+ case "boolean":+ return [pref, _Services.prefs.getBoolPref(pref)];+ case "number":+ return [pref, _Services.prefs.getIntPref(pref)];+ case "string":+ return [pref, _Services.prefs.getStringPref(pref)];+ default:+ throw new Error("runWithPrefs doesn't support this pref type yet");+ }+ });+}; /** * Runs the next test function from the list of async tests.@@ -1667,6 +1715,12 @@ return; }+ let initialPrefsValues = [];+ if (_properties.pref_set) {+ initialPrefsValues = _getTaskPrefs(_properties.pref_set);+ _setTaskPrefs(_properties.pref_set);+ }+ if (_properties.isTask) { _gTaskRunning = true; let startTime = Cu.now();@@ -1681,6 +1735,7 @@ if (_isGenerator(result)) { Assert.ok(false, "Task returned a generator"); }+ _setTaskPrefs(initialPrefsValues); run_next_test(); }, ex => {@@ -1690,6 +1745,7 @@ { category: "Test", startTime }, _gRunningTest.name || undefined );+ _setTaskPrefs(initialPrefsValues); try { do_report_unexpected_exception(ex); } catch (error) {@@ -1711,6 +1767,7 @@ { category: "Test", startTime }, _gRunningTest.name || undefined );+ _setTaskPrefs(initialPrefsValues); } } }
I'll analyze the code diff for security fixes following the specified format. Vulnerability Existed: yes Insecure Preference Handling [testing/xpcshell/head.js] [Lines 1565-1767] [Old Code] The old code didn't have any mechanism to handle preferences for tests, which could lead to tests running with incorrect or insecure preference settings if they weren't properly cleaned up. [Fixed Code] The new code adds pref_set property support and implements proper preference handling with: 1. _setTaskPrefs function to safely set preferences 2. _getTaskPrefs function to store initial values 3. Proper cleanup by restoring original values after test completion Vulnerability Existed: not sure Potential Information Leak [testing/xpcshell/head.js] [Lines 1603-1767] [Old Code] The old code didn't have any preference handling, so it couldn't leak preference values [Fixed Code] The new code now stores and restores preference values, which could potentially expose sensitive preference values if not properly handled, though the implementation appears secure with proper info-level logging The main security improvement is the addition of proper preference handling which prevents tests from leaving modified preferences that could affect subsequent tests or the browser state. The implementation includes proper type checking and cleanup mechanisms.
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/filter-effects/filters-drop-shadow-001.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/filter-effects/filters-drop-shadow-001.html@@ -7,7 +7,6 @@ <link rel="help" href="https://www.w3.org/TR/filter-effects-1/#funcdef-filter-drop-shadow"> <link rel="help" href="http://www.w3.org/TR/filter-effects-1/#dropshadowEquivalent"> <link rel="match" href="reference/filters-drop-shadow-001-ref.html">- <meta name="flags" content=""> <meta name="assert" content="This test verifies that the drop-shadow shorthand works. Green box with green shadow. The shadows appear 10px down and 20px right under the Green box. The red box must not appear under the Green box."> <style type="text/css">
Based on the provided code diff, I don't see any security vulnerabilities being fixed. The change is simply removing an empty meta tag for "flags". Here's the analysis:
Vulnerability Existed: no
No security vulnerability found [testing/web-platform/tests/css/filter-effects/filters-drop-shadow-001.html] [Lines 7]
<meta name="flags" content="">
[Removed line]
This appears to be a minor cleanup change rather than a security fix. The removed meta tag was empty and didn't serve any apparent purpose in the test file. There are no visible security implications to this change.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/css-break/widows-orphans-012.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-break/widows-orphans-012.html@@ -20,7 +20,6 @@ -->- <meta name="flags" content=""> <meta name="assert" content="When column boxes are filled sequentially, their content should be distributed and fragmented in accordance with the 'orphans' and the 'widows' declarations. In the test, since the 3rd column box was going to get only 3 line boxes, then a class B break point should occur between the '12' and the '13' so that there is a minimum of 7 line boxes at the top of the 3rd column box."> <style>
Analysis of the provided code diff: 1. Vulnerability Existed: no No specific vulnerability found [File] testing/web-platform/tests/css/css-break/widows-orphans-012.html [Lines] 20 [Old Code] `<meta name="flags" content="">` [Fixed Code] (line removed) Additional Details: - The change simply removes an empty meta tag for "flags" which doesn't appear to have any security implications - This appears to be a test file cleanup rather than a security fix - No known vulnerability is associated with this change - The modification doesn't introduce or fix any security-related functionality Note: The diff shows a test file modification that doesn't appear to be security-related. The removed line was an empty meta tag that served no apparent purpose in the test case.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.roundrect.4.radii.4.dompointinit.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.roundrect.4.radii.4.dompointinit.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -27,15 +27,15 @@ ctx.fill(); // bottom-left corner-_assertPixel(offscreenCanvas, 20,48, 255,0,0,255, "20,48", "255,0,0,255");-_assertPixel(offscreenCanvas, 41,48, 0,255,0,255, "41,48", "0,255,0,255");-_assertPixel(offscreenCanvas, 1,39, 255,0,0,255, "1,39", "255,0,0,255");-_assertPixel(offscreenCanvas, 1,28, 0,255,0,255, "1,28", "0,255,0,255");+_assertPixel(canvas, 20,48, 255,0,0,255, "20,48", "255,0,0,255");+_assertPixel(canvas, 41,48, 0,255,0,255, "41,48", "0,255,0,255");+_assertPixel(canvas, 1,39, 255,0,0,255, "1,39", "255,0,0,255");+_assertPixel(canvas, 1,28, 0,255,0,255, "1,28", "0,255,0,255"); // other corners-_assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255");+_assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");+_assertPixel(canvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");+_assertPixel(canvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255"); t.done(); });
Based on the provided code diff, I don't see any security-related changes. The changes appear to be purely variable renaming from `offscreenCanvas` to `canvas` and corresponding updates to the assertions. Here's the analysis:
1. Vulnerability Existed: no
No security vulnerability found [File] [Lines 17-27]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
_assertPixel(offscreenCanvas, 20,48, 255,0,0,255, "20,48", "255,0,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
_assertPixel(canvas, 20,48, 255,0,0,255, "20,48", "255,0,0,255");
The changes are purely cosmetic/refactoring in nature, improving variable naming consistency without any security implications. No security vulnerabilities were addressed in this diff.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.