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/js/src/jsnum.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/jsnum.cpp@@ -1973,11 +1973,17 @@ *out = 0.0; return true; }- if (v.isUndefined()) { *out = GenericNaN(); return true; }+#ifdef ENABLE_RECORD_TUPLE+ if (v.isExtendedPrimitive()) {+ JS_ReportErrorNumberASCII(cx, GetErrorMessage, nullptr,+ JSMSG_RECORD_TUPLE_TO_NUMBER);+ return false;+ }+#endif MOZ_ASSERT(v.isSymbol() || v.isBigInt()); if (!cx->isHelperThreadContext()) {
Let me analyze the code diff for security fixes:
Vulnerability Existed: not sure
[Potential Type Confusion or Invalid Conversion] [js/src/jsnum.cpp] [Lines 1973-1983]
[Old Code]
if (v.isUndefined()) {
*out = GenericNaN();
return true;
}
MOZ_ASSERT(v.isSymbol() || v.isBigInt());
[Fixed Code]
if (v.isUndefined()) {
*out = GenericNaN();
return true;
}
#ifdef ENABLE_RECORD_TUPLE
if (v.isExtendedPrimitive()) {
JS_ReportErrorNumberASCII(cx, GetErrorMessage, nullptr,
JSMSG_RECORD_TUPLE_TO_NUMBER);
return false;
}
#endif
MOZ_ASSERT(v.isSymbol() || v.isBigInt());
Additional Details:
- The fix adds a check for extended primitives (likely related to Record and Tuple types) before the symbol/bigint assertion
- Without this check, there might have been potential for invalid type conversions when dealing with extended primitives
- The error message suggests this is preventing conversion of Record/Tuple to number
- While not clearly a security vulnerability, improper type handling could potentially lead to type confusion issues
- The fix prevents the operation rather than attempting to convert, which is safer
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/css-shapes/shape-outside/supported-shapes/ellipse/shape-outside-ellipse-050.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-shapes/shape-outside/supported-shapes/ellipse/shape-outside-ellipse-050.html@@ -9,7 +9,6 @@ <link rel="author" title="Mozilla" href="http://www.mozilla.org/"> <link rel="help" href="https://drafts.csswg.org/css-shapes-1/#supported-basic-shapes"> <link rel="match" href="reference/shape-outside-ellipse-050-ref.html">- <meta name="flags" content=""> <meta name="assert" content="Test the boxes are wrapping around the left float shape defined by the basic shape ellipse(closest-side farthest-side at left 40px top 60px) border-box"> <style> .container {
Based on the provided diff, I'll analyze it for potential security vulnerabilities: Vulnerability Existed: no No security vulnerability found [File] [Lines 9] Old Code: <meta name="flags" content=""> Fixed Code: (removed line) Additional Details: - The change simply removes a meta tag with empty flags attribute - This appears to be a test file cleanup rather than a security fix - No actual security vulnerability was addressed in this change - The modification doesn't affect any security-sensitive functionality Note: While I've marked this as "no" vulnerability, it's worth noting that removing unused code can sometimes be considered a security best practice (defense in depth), but there's no specific vulnerability being fixed here.
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/src/lib.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/textwrap/src/lib.rs@@ -1,20 +1,20 @@-//! `textwrap` provides functions for word wrapping and filling text.-//!-//! Wrapping text can be very useful in commandline programs where you-//! want to format dynamic output nicely so it looks good in a+//! The textwrap library provides functions for word wrapping and+//! indenting text.+//!+//! # Wrapping Text+//!+//! Wrapping text can be very useful in command-line programs where+//! you want to format dynamic output nicely so it looks good in a //! terminal. A quick example: //! //! ```no_run-//! extern crate textwrap;-//! use textwrap::fill;-//! //! fn main() { //! let text = "textwrap: a small library for wrapping text.";-//! println!("{}", fill(text, 18));+//! println!("{}", textwrap::fill(text, 18)); //! } //! ``` //!-//! This will display the following output:+//! When you run this program, it will display the following output: //! //! ```text //! textwrap: a small@@ -22,11 +22,48 @@ //! wrapping text. //! ``` //!-//! # Displayed Width vs Byte Size+//! If you enable the `hyphenation` Cargo feature, you can get+//! automatic hyphenation for a number of languages:+//!+//! ```no_run+//! # #[cfg(feature = "hyphenation")]+//! use hyphenation::{Language, Load, Standard};+//! use textwrap::{fill, Options};+//!+//! # #[cfg(feature = "hyphenation")]+//! fn main() {+//! let text = "textwrap: a small library for wrapping text.";+//! let dictionary = Standard::from_embedded(Language::EnglishUS).unwrap();+//! let options = Options::new(18).word_splitter(dictionary);+//! println!("{}", fill(text, &options));+//! }+//!+//! # #[cfg(not(feature = "hyphenation"))]+//! # fn main() { }+//! ```+//!+//! The program will now output:+//!+//! ```text+//! textwrap: a small+//! library for wrap-+//! ping text.+//! ```+//!+//! See also the [`unfill`] and [`refill`] functions which allow you to+//! manipulate already wrapped text.+//!+//! ## 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.+//!+//! ## Displayed Width vs Byte Size //! //! To word wrap text, one must know the width of each word so one can-//! know when to break lines. This library measures the width of text-//! using the [displayed width][unicode-width], not the size in bytes.+//! know when to break lines. This library will by default measure the+//! width of text using the _displayed width_, not the size in bytes.+//! The `unicode-width` Cargo feature controls this. //! //! This is important for non-ASCII text. ASCII characters such as `a` //! and `!` are simple and take up one column each. This means that@@ -37,115 +74,430 @@ //! //! This is why we take care to use the displayed width instead of the //! byte count when computing line lengths. All functions in this-//! library handle Unicode characters like this.-//!+//! library handle Unicode characters like this when the+//! `unicode-width` Cargo feature is enabled (it is enabled by+//! default).+//!+//! # Indentation and Dedentation+//!+//! The textwrap library also offers functions for adding a prefix to+//! every line of a string and to remove leading whitespace. As an+//! example, the [`indent`] function allows you to turn lines of text+//! into a bullet list:+//!+//! ```+//! let before = "\+//! foo+//! bar+//! baz+//! ";+//! let after = "\+//! * foo+//! * bar+//! * baz+//! ";+//! assert_eq!(textwrap::indent(before, "* "), after);+//! ```+//!+//! Removing leading whitespace is done with [`dedent`]:+//!+//! ```+//! let before = "+//! Some+//! indented+//! text+//! ";+//! let after = "+//! Some+//! indented+//! text+//! ";+//! assert_eq!(textwrap::dedent(before), after);+//! ```+//!+//! # Cargo Features+//!+//! The textwrap library can be slimmed down as needed via a number of+//! Cargo features. This means you only pay for the features you+//! actually use.+//!+//! The full dependency graph, where dashed lines indicate optional+//! dependencies, is shown below:+//!+//! <img src="https://raw.githubusercontent.com/mgeisler/textwrap/master/images/textwrap-0.14.2.svg">+//!+//! ## Default Features+//!+//! These features are enabled by default:+//!+//! * `unicode-linebreak`: enables finding words using the+//! [unicode-linebreak] crate, which implements the line breaking+//! algorithm described in [Unicode Standard Annex+//! #14](https://www.unicode.org/reports/tr14/).+//!+//! This feature can be disabled if you are happy to find words+//! separated by ASCII space characters only. People wrapping text+//! with emojis or East-Asian characters will want most likely want+//! to enable this feature. See the+//! [`word_separators::WordSeparator`] trait for details.+//!+//! * `unicode-width`: enables correct width computation of non-ASCII+//! characters via the [unicode-width] crate. Without this feature,+//! every [`char`] is 1 column wide, except for emojis which are 2+//! columns wide. See the [`core::display_width`] function for+//! details.+//!+//! This feature can be disabled if you only need to wrap ASCII+//! text, or if the functions in [`core`] are used directly with+//! [`core::Fragment`]s for which the widths have been computed in+//! other ways.+//!+//! * `smawk`: enables linear-time wrapping of the whole paragraph via+//! the [smawk] crate. See the [`wrap_algorithms::wrap_optimal_fit`]+//! function for details on the optimal-fit algorithm.+//!+//! This feature can be disabled if you only ever intend to use+//! [`wrap_algorithms::wrap_first_fit`].+//!+//! ## Optional Features+//!+//! These Cargo features enable new functionality:+//!+//! * `terminal_size`: enables automatic detection of the terminal+//! width via the [terminal_size] crate. See the+//! [`Options::with_termwidth`] constructor for details.+//!+//! * `hyphenation`: enables language-sensitive hyphenation via the+//! [hyphenation] crate. See the [`word_splitters::WordSplitter`] trait for details.+//!+//! [unicode-linebreak]: https://docs.rs/unicode-linebreak/ //! [unicode-width]: https://docs.rs/unicode-width/--#![doc(html_root_url = "https://docs.rs/textwrap/0.11.0")]+//! [smawk]: https://docs.rs/smawk/+//! [textwrap-macros]: https://docs.rs/textwrap-macros/+//! [terminal_size]: https://docs.rs/terminal_size/+//! [hyphenation]: https://docs.rs/hyphenation/++#![doc(html_root_url = "https://docs.rs/textwrap/0.14.2")]+#![forbid(unsafe_code)] // See https://github.com/mgeisler/textwrap/issues/210 #![deny(missing_docs)] #![deny(missing_debug_implementations)]--#[cfg(feature = "hyphenation")]-extern crate hyphenation;-#[cfg(feature = "term_size")]-extern crate term_size;-extern crate unicode_width;+#![allow(clippy::redundant_field_names)] use std::borrow::Cow;-use std::str::CharIndices;--use unicode_width::UnicodeWidthChar;-use unicode_width::UnicodeWidthStr;--/// A non-breaking space.-const NBSP: char = '\u{a0}'; mod indentation;-pub use indentation::dedent;-pub use indentation::indent;--mod splitting;-pub use splitting::{HyphenSplitter, NoHyphenation, WordSplitter};--/// A Wrapper holds settings for wrapping and filling text. Use it-/// when the convenience [`wrap_iter`], [`wrap`] and [`fill`] functions-/// are not flexible enough.-///-/// [`wrap_iter`]: fn.wrap_iter.html-/// [`wrap`]: fn.wrap.html-/// [`fill`]: fn.fill.html-///-/// The algorithm used by the `WrapIter` iterator (returned from the-/// `wrap_iter` method) works by doing successive partial scans over-/// words in the input string (where each single scan yields a single-/// line) so that the overall time and memory complexity is O(*n*) where-/// *n* is the length of the input string.-#[derive(Clone, Debug)]-pub struct Wrapper<'a, S: WordSplitter> {+pub use crate::indentation::dedent;+pub use crate::indentation::indent;++pub mod word_separators;+pub mod word_splitters;+pub mod wrap_algorithms;++pub mod core;++// These private macros lets us hide the actual WrapAlgorithm and+// WordSeperator used in the function signatures below.+#[cfg(feature = "smawk")]+macro_rules! DefaultWrapAlgorithm {+ () => {+ wrap_algorithms::OptimalFit+ };+}++#[cfg(not(feature = "smawk"))]+macro_rules! DefaultWrapAlgorithm {+ () => {+ wrap_algorithms::FirstFit+ };+}++#[cfg(feature = "unicode-linebreak")]+macro_rules! DefaultWordSeparator {+ () => {+ word_separators::UnicodeBreakProperties+ };+}++#[cfg(not(feature = "unicode-linebreak"))]+macro_rules! DefaultWordSeparator {+ () => {+ word_separators::AsciiSpace+ };+}++/// Holds settings for wrapping and filling text.+#[derive(Debug, Clone)]+pub struct Options<+ 'a,+ WrapAlgo = Box<dyn wrap_algorithms::WrapAlgorithm>,+ WordSep = Box<dyn word_separators::WordSeparator>,+ WordSplit = Box<dyn word_splitters::WordSplitter>,+> { /// The width in columns at which the text will be wrapped. pub width: usize,- /// Indentation used for the first line of output.+ /// Indentation used for the first line of output. See the+ /// [`Options::initial_indent`] method. pub initial_indent: &'a str,- /// Indentation used for subsequent lines of output.+ /// Indentation used for subsequent lines of output. See the+ /// [`Options::subsequent_indent`] method. pub subsequent_indent: &'a str, /// Allow long words to be broken if they cannot fit on a line. /// When set to `false`, some lines may be longer than- /// `self.width`.+ /// `self.width`. See the [`Options::break_words`] method. pub break_words: bool,- /// The method for splitting words. If the `hyphenation` feature- /// is enabled, you can use a `hyphenation::Standard` dictionary- /// here to get language-aware hyphenation.- pub splitter: S,+ /// Wrapping algorithm to use, see the implementations of the+ /// [`wrap_algorithms::WrapAlgorithm`] trait for details.+ pub wrap_algorithm: WrapAlgo,+ /// The line breaking algorithm to use, see+ /// [`word_separators::WordSeparator`] trait for an overview and+ /// possible implementations.+ pub word_separator: WordSep,+ /// The method for splitting words. This can be used to prohibit+ /// splitting words on hyphens, or it can be used to implement+ /// language-aware machine hyphenation. Please see the+ /// [`word_splitters::WordSplitter`] trait for details.+ pub word_splitter: WordSplit, }-impl<'a> Wrapper<'a, HyphenSplitter> {- /// Create a new Wrapper for wrapping at the specified width. By- /// default, we allow words longer than `width` to be broken. A- /// [`HyphenSplitter`] will be used by default for splitting- /// words. See the [`WordSplitter`] trait for other options.- ///- /// [`HyphenSplitter`]: struct.HyphenSplitter.html- /// [`WordSplitter`]: trait.WordSplitter.html- pub fn new(width: usize) -> Wrapper<'a, HyphenSplitter> {- Wrapper::with_splitter(width, HyphenSplitter)- }-- /// Create a new Wrapper for wrapping text at the current terminal- /// width. If the terminal width cannot be determined (typically- /// because the standard input and output is not connected to a- /// terminal), a width of 80 characters will be used. Other- /// settings use the same defaults as `Wrapper::new`.+impl<'a, WrapAlgo, WordSep, WordSplit> From<&'a Options<'a, WrapAlgo, WordSep, WordSplit>>+ for Options<'a, WrapAlgo, WordSep, WordSplit>+where+ WrapAlgo: Clone,+ WordSep: Clone,+ WordSplit: Clone,+{+ fn from(options: &'a Options<'a, WrapAlgo, WordSep, WordSplit>) -> Self {+ Self {+ width: options.width,+ initial_indent: options.initial_indent,+ subsequent_indent: options.subsequent_indent,+ break_words: options.break_words,+ word_separator: options.word_separator.clone(),+ wrap_algorithm: options.wrap_algorithm.clone(),+ word_splitter: options.word_splitter.clone(),+ }+ }+}++impl<'a> From<usize>+ for Options<+ 'a,+ DefaultWrapAlgorithm!(),+ DefaultWordSeparator!(),+ word_splitters::HyphenSplitter,+ >+{+ fn from(width: usize) -> Self {+ Options::new(width)+ }+}++/// Constructors for boxed Options, specifically.+impl<'a>+ Options<'a, DefaultWrapAlgorithm!(), DefaultWordSeparator!(), word_splitters::HyphenSplitter>+{+ /// Creates a new [`Options`] with the specified width and static+ /// dispatch using the [`word_splitters::HyphenSplitter`].+ /// Equivalent to+ ///+ /// ```+ /// # use textwrap::word_splitters::{HyphenSplitter, WordSplitter};+ /// # use textwrap::Options;+ /// # let width = 80;+ /// # let actual = Options::new(width);+ /// # let expected =+ /// Options {+ /// width: width,+ /// initial_indent: "",+ /// subsequent_indent: "",+ /// break_words: true,+ /// #[cfg(feature = "unicode-linebreak")]+ /// word_separator: textwrap::word_separators::UnicodeBreakProperties,+ /// #[cfg(not(feature = "unicode-linebreak"))]+ /// word_separator: textwrap::word_separators::AsciiSpace,+ /// #[cfg(feature = "smawk")]+ /// wrap_algorithm: textwrap::wrap_algorithms::OptimalFit,+ /// #[cfg(not(feature = "smawk"))]+ /// wrap_algorithm: textwrap::wrap_algorithms::FirstFit,+ /// word_splitter: textwrap::word_splitters::HyphenSplitter,+ /// }+ /// # ;+ /// # assert_eq!(actual.width, expected.width);+ /// # assert_eq!(actual.initial_indent, expected.initial_indent);+ /// # assert_eq!(actual.subsequent_indent, expected.subsequent_indent);+ /// # assert_eq!(actual.break_words, expected.break_words);+ /// ```+ ///+ /// Note that the default word separator and wrap algorithms+ /// changes based on the available Cargo features. The best+ /// available algorithm is used by default.+ ///+ /// Static dispatch means here, that the word splitter is stored as-is+ /// and the type is known at compile-time. Thus the returned value+ /// is actually a `Options<AsciiSpace, HyphenSplitter>`.+ ///+ /// Dynamic dispatch on the other hand, means that the word+ /// separator and/or word splitter is stored as a trait object+ /// such as a `Box<dyn word_splitters::WordSplitter>`. This way+ /// the word splitter's inner type can be changed without changing+ /// the type of this struct, which then would be just `Options` as+ /// a short cut for `Options<Box<dyn+ /// word_separators::WordSeparator>, Box<dyn+ /// word_splitters::WordSplitter>>`.+ ///+ /// The value and type of the word splitter can be choose from the+ /// start using the [`Options::with_word_splitter`] constructor or+ /// changed afterwards using the [`Options::word_splitter`]+ /// method. Whether static or dynamic dispatch is used, depends on+ /// whether these functions are given a boxed+ /// [`word_splitters::WordSplitter`] or not. Take for example:+ ///+ /// ```+ /// use textwrap::Options;+ /// use textwrap::word_splitters::{HyphenSplitter, NoHyphenation};+ /// # use textwrap::word_splitters::WordSplitter;+ /// # use textwrap::word_separators::AsciiSpace;+ /// # let width = 80;+ ///+ /// // uses HyphenSplitter with static dispatch+ /// // the actual type: Options<AsciiSpace, HyphenSplitter>+ /// let opt = Options::new(width);+ ///+ /// // uses NoHyphenation with static dispatch+ /// // the actual type: Options<AsciiSpace, NoHyphenation>+ /// let opt = Options::new(width).word_splitter(NoHyphenation);+ ///+ /// // uses HyphenSplitter with dynamic dispatch+ /// // the actual type: Options<AsciiSpace, Box<dyn word_splitters::WordSplitter>>+ /// let opt: Options<_, _, _> = Options::new(width).word_splitter(Box::new(HyphenSplitter));+ ///+ /// // uses NoHyphenation with dynamic dispatch+ /// // the actual type: Options<AsciiSpace, Box<dyn word_splitters::WordSplitter>>+ /// let opt: Options<_, _, _> = Options::new(width).word_splitter(Box::new(NoHyphenation));+ /// ```+ ///+ /// Notice that the last two variables have the same type, despite+ /// the different `WordSplitter` in use. Thus dynamic dispatch+ /// allows to change the word splitter at run-time without+ /// changing the variables type.+ pub const fn new(width: usize) -> Self {+ Options::with_word_splitter(width, word_splitters::HyphenSplitter)+ }++ /// Creates a new [`Options`] with `width` set to the current+ /// terminal width. If the terminal width cannot be determined+ /// (typically because the standard input and output is not+ /// connected to a terminal), a width of 80 characters will be+ /// used. Other settings use the same defaults as+ /// [`Options::new`]. /// /// Equivalent to: /// /// ```no_run- /// # #![allow(unused_variables)]- /// use textwrap::{Wrapper, termwidth};- ///- /// let wrapper = Wrapper::new(termwidth());+ /// use textwrap::{termwidth, Options};+ ///+ /// let options = Options::new(termwidth()); /// ```- #[cfg(feature = "term_size")]- pub fn with_termwidth() -> Wrapper<'a, HyphenSplitter> {- Wrapper::new(termwidth())+ ///+ /// **Note:** Only available when the `terminal_size` feature is+ /// enabled.+ #[cfg(feature = "terminal_size")]+ pub fn with_termwidth() -> Self {+ Self::new(termwidth()) } }-impl<'a, S: WordSplitter> Wrapper<'a, S> {- /// Use the given [`WordSplitter`] to create a new Wrapper for- /// wrapping at the specified width. By default, we allow words- /// longer than `width` to be broken.- ///- /// [`WordSplitter`]: trait.WordSplitter.html- pub fn with_splitter(width: usize, splitter: S) -> Wrapper<'a, S> {- Wrapper {- width: width,+impl<'a, WordSplit> Options<'a, DefaultWrapAlgorithm!(), DefaultWordSeparator!(), WordSplit> {+ /// Creates a new [`Options`] with the specified width and+ /// word splitter. Equivalent to+ ///+ /// ```+ /// # use textwrap::Options;+ /// # use textwrap::word_splitters::{NoHyphenation, HyphenSplitter};+ /// # const word_splitter: NoHyphenation = NoHyphenation;+ /// # const width: usize = 80;+ /// # let actual = Options::with_word_splitter(width, word_splitter);+ /// # let expected =+ /// Options {+ /// width: width,+ /// initial_indent: "",+ /// subsequent_indent: "",+ /// break_words: true,+ /// #[cfg(feature = "unicode-linebreak")]+ /// word_separator: textwrap::word_separators::UnicodeBreakProperties,+ /// #[cfg(not(feature = "unicode-linebreak"))]+ /// word_separator: textwrap::word_separators::AsciiSpace,+ /// #[cfg(feature = "smawk")]+ /// wrap_algorithm: textwrap::wrap_algorithms::OptimalFit,+ /// #[cfg(not(feature = "smawk"))]+ /// wrap_algorithm: textwrap::wrap_algorithms::FirstFit,+ /// word_splitter: word_splitter,+ /// }+ /// # ;+ /// # assert_eq!(actual.width, expected.width);+ /// # assert_eq!(actual.initial_indent, expected.initial_indent);+ /// # assert_eq!(actual.subsequent_indent, expected.subsequent_indent);+ /// # assert_eq!(actual.break_words, expected.break_words);+ /// ```+ ///+ /// This constructor allows to specify the word splitter to be+ /// used. It is like a short-cut for+ /// `Options::new(w).word_splitter(s)`, but this function is a+ /// `const fn`. The given word splitter may be in a [`Box`], which+ /// then can be coerced into a trait object for dynamic dispatch:+ ///+ /// ```+ /// use textwrap::Options;+ /// use textwrap::word_splitters::{HyphenSplitter, NoHyphenation, WordSplitter};+ /// # const width: usize = 80;+ ///+ /// // This opt contains a boxed trait object as splitter.+ /// // The type annotation is important, otherwise it will be not a trait object+ /// let mut opt: Options<_, _, Box<dyn WordSplitter>>+ /// = Options::with_word_splitter(width, Box::new(NoHyphenation));+ /// // Its type is actually: `Options<AsciiSpace, Box<dyn word_splitters::WordSplitter>>`:+ /// let opt_coerced: Options<_, _, Box<dyn WordSplitter>> = opt;+ ///+ /// // Thus, it can be overridden with a different word splitter.+ /// opt = Options::with_word_splitter(width, Box::new(HyphenSplitter));+ /// // Now, containing a `HyphenSplitter` instead.+ /// ```+ ///+ /// Since the word splitter is given by value, which determines+ /// the generic type parameter, it can be used to produce both an+ /// [`Options`] with static and dynamic dispatch, respectively.+ /// While dynamic dispatch allows to change the type of the inner+ /// word splitter at run time as seen above, static dispatch+ /// especially can store the word splitter directly, without the+ /// need for a box. This in turn allows it to be used in constant+ /// and static context:+ ///+ /// ```+ /// use textwrap::word_splitters::HyphenSplitter; use textwrap::{ Options};+ /// use textwrap::word_separators::AsciiSpace;+ /// use textwrap::wrap_algorithms::FirstFit;+ /// # const width: usize = 80;+ ///+ /// # #[cfg(all(not(feature = "smawk"), not(feature = "unicode-linebreak")))] {+ /// const FOO: Options<FirstFit, AsciiSpace, HyphenSplitter> =+ /// Options::with_word_splitter(width, HyphenSplitter);+ /// static BAR: Options<FirstFit, AsciiSpace, HyphenSplitter> = FOO;+ /// # }+ /// ```+ pub const fn with_word_splitter(width: usize, word_splitter: WordSplit) -> Self {+ Options {+ width, initial_indent: "", subsequent_indent: "", break_words: true,- splitter: splitter,+ word_separator: DefaultWordSeparator!(),+ wrap_algorithm: DefaultWrapAlgorithm!(),+ word_splitter: word_splitter, } }-+}++impl<'a, WrapAlgo, WordSep, WordSplit> Options<'a, WrapAlgo, WordSep, WordSplit> { /// Change [`self.initial_indent`]. The initial indentation is /// used on the very first line of output. ///@@ -154,16 +506,18 @@ /// Classic paragraph indentation can be achieved by specifying an /// initial indentation and wrapping each paragraph by itself: ///- /// ```no_run- /// # #![allow(unused_variables)]- /// use textwrap::Wrapper;- ///- /// let wrapper = Wrapper::new(15).initial_indent(" "); /// ```+ /// use textwrap::{Options, wrap};+ ///+ /// let options = Options::new(16).initial_indent(" ");+ /// assert_eq!(wrap("This is a little example.", options),+ /// vec![" This is a",+ /// "little example."]);+ /// ``` /// /// [`self.initial_indent`]: #structfield.initial_indent- pub fn initial_indent(self, indent: &'a str) -> Wrapper<'a, S> {- Wrapper {+ pub fn initial_indent(self, indent: &'a str) -> Self {+ Options { initial_indent: indent, ..self }@@ -177,18 +531,29 @@ /// Combining initial and subsequent indentation lets you format a /// single paragraph as a bullet list: ///- /// ```no_run- /// # #![allow(unused_variables)]- /// use textwrap::Wrapper;- ///- /// let wrapper = Wrapper::new(15)+ /// ```+ /// use textwrap::{Options, wrap};+ ///+ /// let options = Options::new(12) /// .initial_indent("* ") /// .subsequent_indent(" ");+ /// #[cfg(feature = "smawk")]+ /// assert_eq!(wrap("This is a little example.", options),+ /// vec!["* This is",+ /// " a little",+ /// " example."]);+ ///+ /// // Without the `smawk` feature, the wrapping is a little different:+ /// #[cfg(not(feature = "smawk"))]+ /// assert_eq!(wrap("This is a little example.", options),+ /// vec!["* This is a",+ /// " little",+ /// " example."]); /// ``` /// /// [`self.subsequent_indent`]: #structfield.subsequent_indent- pub fn subsequent_indent(self, indent: &'a str) -> Wrapper<'a, S> {- Wrapper {+ pub fn subsequent_indent(self, indent: &'a str) -> Self {+ Options { subsequent_indent: indent, ..self }@@ -198,528 +563,863 @@ /// than `self.width` can be broken, or if they will be left /// sticking out into the right margin. ///+ /// # Examples+ ///+ /// ```+ /// use textwrap::{wrap, Options};+ ///+ /// let options = Options::new(4).break_words(true);+ /// assert_eq!(wrap("This is a little example.", options),+ /// vec!["This",+ /// "is a",+ /// "litt",+ /// "le",+ /// "exam",+ /// "ple."]);+ /// ```+ /// /// [`self.break_words`]: #structfield.break_words- pub fn break_words(self, setting: bool) -> Wrapper<'a, S> {- Wrapper {+ pub fn break_words(self, setting: bool) -> Self {+ Options { break_words: setting, ..self } }- /// Fill a line of text at `self.width` characters. Strings are- /// wrapped based on their displayed width, not their size in- /// bytes.- ///- /// The result is a string with newlines between each line. Use- /// the `wrap` method if you need access to the individual lines.- ///- /// # Complexities- ///- /// This method simply joins the lines produced by `wrap_iter`. As- /// such, it inherits the O(*n*) time and memory complexity where- /// *n* is the input string length.- ///- /// # Examples+ /// Change [`self.word_separator`].+ ///+ /// See [`word_separators::WordSeparator`] for details on the choices.+ ///+ /// [`self.word_separator`]: #structfield.word_separator+ pub fn word_separator<NewWordSep>(+ self,+ word_separator: NewWordSep,+ ) -> Options<'a, WrapAlgo, NewWordSep, WordSplit> {+ Options {+ width: self.width,+ initial_indent: self.initial_indent,+ subsequent_indent: self.subsequent_indent,+ break_words: self.break_words,+ word_separator: word_separator,+ wrap_algorithm: self.wrap_algorithm,+ word_splitter: self.word_splitter,+ }+ }++ /// Change [`self.wrap_algorithm`].+ ///+ /// See the [`wrap_algorithms::WrapAlgorithm`] trait for details on+ /// the choices.+ ///+ /// [`self.wrap_algorithm`]: #structfield.wrap_algorithm+ pub fn wrap_algorithm<NewWrapAlgo>(+ self,+ wrap_algorithm: NewWrapAlgo,+ ) -> Options<'a, NewWrapAlgo, WordSep, WordSplit> {+ Options {+ width: self.width,+ initial_indent: self.initial_indent,+ subsequent_indent: self.subsequent_indent,+ break_words: self.break_words,+ word_separator: self.word_separator,+ wrap_algorithm: wrap_algorithm,+ word_splitter: self.word_splitter,+ }+ }++ /// Change [`self.word_splitter`]. The+ /// [`word_splitters::WordSplitter`] is used to fit part of a word+ /// into the current line when wrapping text.+ ///+ /// This function may return a different type than `Self`. That is+ /// the case when the given `splitter` is of a different type the+ /// the currently stored one in the `splitter` field. Take for+ /// example: /// /// ```- /// use textwrap::Wrapper;- ///- /// let wrapper = Wrapper::new(15);- /// assert_eq!(wrapper.fill("Memory safety without garbage collection."),- /// "Memory safety\nwithout garbage\ncollection.");+ /// use textwrap::word_splitters::{HyphenSplitter, NoHyphenation};+ /// use textwrap::Options;+ /// // The default type returned by `new`:+ /// let opt: Options<_, _, HyphenSplitter> = Options::new(80);+ /// // Setting a different word splitter changes the type+ /// let opt: Options<_, _, NoHyphenation> = opt.word_splitter(NoHyphenation); /// ```- pub fn fill(&self, s: &str) -> String {- // This will avoid reallocation in simple cases (no- // indentation, no hyphenation).- let mut result = String::with_capacity(s.len());-- for (i, line) in self.wrap_iter(s).enumerate() {- if i > 0 {- result.push('\n');- }- result.push_str(&line);+ ///+ /// [`self.word_splitter`]: #structfield.word_splitter+ pub fn word_splitter<NewWordSplit>(+ self,+ word_splitter: NewWordSplit,+ ) -> Options<'a, WrapAlgo, WordSep, NewWordSplit> {+ Options {+ width: self.width,+ initial_indent: self.initial_indent,+ subsequent_indent: self.subsequent_indent,+ break_words: self.break_words,+ word_separator: self.word_separator,+ wrap_algorithm: self.wrap_algorithm,+ word_splitter, }-- result- }-- /// Wrap a line of text at `self.width` characters. Strings are- /// wrapped based on their displayed width, not their size in- /// bytes.- ///- /// # Complexities- ///- /// This method simply collects the lines produced by `wrap_iter`.- /// As such, it inherits the O(*n*) overall time and memory- /// complexity where *n* is the input string length.- ///- /// # Examples- ///- /// ```- /// use textwrap::Wrapper;- ///- /// let wrap15 = Wrapper::new(15);- /// assert_eq!(wrap15.wrap("Concurrency without data races."),- /// vec!["Concurrency",- /// "without data",- /// "races."]);- ///- /// let wrap20 = Wrapper::new(20);- /// assert_eq!(wrap20.wrap("Concurrency without data races."),- /// vec!["Concurrency without",- /// "data races."]);- /// ```- ///- /// Notice that newlines in the input are preserved. This means- /// that they force a line break, regardless of how long the- /// current line is:- ///- /// ```- /// use textwrap::Wrapper;- ///- /// let wrapper = Wrapper::new(40);- /// assert_eq!(wrapper.wrap("First line.\nSecond line."),- /// vec!["First line.", "Second line."]);- /// ```- ///- pub fn wrap(&self, s: &'a str) -> Vec<Cow<'a, str>> {- self.wrap_iter(s).collect::<Vec<_>>()- }-- /// Lazily wrap a line of text at `self.width` characters. Strings- /// are wrapped based on their displayed width, not their size in- /// bytes.- ///- /// The [`WordSplitter`] stored in [`self.splitter`] is used- /// whenever when a word is too large to fit on the current line.- /// By changing the field, different hyphenation strategies can be- /// implemented.- ///- /// # Complexities- ///- /// This method returns a [`WrapIter`] iterator which borrows this- /// `Wrapper`. The algorithm used has a linear complexity, so- /// getting the next line from the iterator will take O(*w*) time,- /// where *w* is the wrapping width. Fully processing the iterator- /// will take O(*n*) time for an input string of length *n*.- ///- /// When no indentation is used, each line returned is a slice of- /// the input string and the memory overhead is thus constant.- /// Otherwise new memory is allocated for each line returned.- ///- /// # Examples- ///- /// ```- /// use std::borrow::Cow;- /// use textwrap::Wrapper;- ///- /// let wrap20 = Wrapper::new(20);- /// let mut wrap20_iter = wrap20.wrap_iter("Zero-cost abstractions.");- /// assert_eq!(wrap20_iter.next(), Some(Cow::from("Zero-cost")));- /// assert_eq!(wrap20_iter.next(), Some(Cow::from("abstractions.")));- /// assert_eq!(wrap20_iter.next(), None);- ///- /// let wrap25 = Wrapper::new(25);- /// let mut wrap25_iter = wrap25.wrap_iter("Zero-cost abstractions.");- /// assert_eq!(wrap25_iter.next(), Some(Cow::from("Zero-cost abstractions.")));- /// assert_eq!(wrap25_iter.next(), None);- /// ```- ///- /// [`self.splitter`]: #structfield.splitter- /// [`WordSplitter`]: trait.WordSplitter.html- /// [`WrapIter`]: struct.WrapIter.html- pub fn wrap_iter<'w>(&'w self, s: &'a str) -> WrapIter<'w, 'a, S> {- WrapIter {- wrapper: self,- inner: WrapIterImpl::new(self, s),- }- }-- /// Lazily wrap a line of text at `self.width` characters. Strings- /// are wrapped based on their displayed width, not their size in- /// bytes.- ///- /// The [`WordSplitter`] stored in [`self.splitter`] is used- /// whenever when a word is too large to fit on the current line.- /// By changing the field, different hyphenation strategies can be- /// implemented.- ///- /// # Complexities- ///- /// This method consumes the `Wrapper` and returns a- /// [`IntoWrapIter`] iterator. Fully processing the iterator has- /// the same O(*n*) time complexity as [`wrap_iter`], where *n* is- /// the length of the input string.- ///- /// # Examples- ///- /// ```- /// use std::borrow::Cow;- /// use textwrap::Wrapper;- ///- /// let wrap20 = Wrapper::new(20);- /// let mut wrap20_iter = wrap20.into_wrap_iter("Zero-cost abstractions.");- /// assert_eq!(wrap20_iter.next(), Some(Cow::from("Zero-cost")));- /// assert_eq!(wrap20_iter.next(), Some(Cow::from("abstractions.")));- /// assert_eq!(wrap20_iter.next(), None);- /// ```- ///- /// [`self.splitter`]: #structfield.splitter- /// [`WordSplitter`]: trait.WordSplitter.html- /// [`IntoWrapIter`]: struct.IntoWrapIter.html- /// [`wrap_iter`]: #method.wrap_iter- pub fn into_wrap_iter(self, s: &'a str) -> IntoWrapIter<'a, S> {- let inner = WrapIterImpl::new(&self, s);-- IntoWrapIter {- wrapper: self,- inner: inner,- } } }-/// An iterator over the lines of the input string which owns a-/// `Wrapper`. An instance of `IntoWrapIter` is typically obtained-/// through either [`wrap_iter`] or [`Wrapper::into_wrap_iter`].-///-/// Each call of `.next()` method yields a line wrapped in `Some` if the-/// input hasn't been fully processed yet. Otherwise it returns `None`.-///-/// [`wrap_iter`]: fn.wrap_iter.html-/// [`Wrapper::into_wrap_iter`]: struct.Wrapper.html#method.into_wrap_iter-#[derive(Debug)]-pub struct IntoWrapIter<'a, S: WordSplitter> {- wrapper: Wrapper<'a, S>,- inner: WrapIterImpl<'a>,-}--impl<'a, S: WordSplitter> Iterator for IntoWrapIter<'a, S> {- type Item = Cow<'a, str>;-- fn next(&mut self) -> Option<Cow<'a, str>> {- self.inner.next(&self.wrapper)- }-}--/// An iterator over the lines of the input string which borrows a-/// `Wrapper`. An instance of `WrapIter` is typically obtained-/// through the [`Wrapper::wrap_iter`] method.-///-/// Each call of `.next()` method yields a line wrapped in `Some` if the-/// input hasn't been fully processed yet. Otherwise it returns `None`.-///-/// [`Wrapper::wrap_iter`]: struct.Wrapper.html#method.wrap_iter-#[derive(Debug)]-pub struct WrapIter<'w, 'a: 'w, S: WordSplitter + 'w> {- wrapper: &'w Wrapper<'a, S>,- inner: WrapIterImpl<'a>,-}--impl<'w, 'a: 'w, S: WordSplitter> Iterator for WrapIter<'w, 'a, S> {- type Item = Cow<'a, str>;-- fn next(&mut self) -> Option<Cow<'a, str>> {- self.inner.next(self.wrapper)- }-}--/// Like `char::is_whitespace`, but non-breaking spaces don't count.-#[inline]-fn is_whitespace(ch: char) -> bool {- ch.is_whitespace() && ch != NBSP-}--/// Common implementation details for `WrapIter` and `IntoWrapIter`.-#[derive(Debug)]-struct WrapIterImpl<'a> {- // String to wrap.- source: &'a str,- // CharIndices iterator over self.source.- char_indices: CharIndices<'a>,- // Byte index where the current line starts.- start: usize,- // Byte index of the last place where the string can be split.- split: usize,- // Size in bytes of the character at self.source[self.split].- split_len: usize,- // Width of self.source[self.start..idx].- line_width: usize,- // Width of self.source[self.start..self.split].- line_width_at_split: usize,- // Tracking runs of whitespace characters.- in_whitespace: bool,- // Has iterator finished producing elements?- finished: bool,-}--impl<'a> WrapIterImpl<'a> {- fn new<S: WordSplitter>(wrapper: &Wrapper<'a, S>, s: &'a str) -> WrapIterImpl<'a> {- WrapIterImpl {- source: s,
After analyzing the provided code diff, I can identify the following security-related changes: 1. Vulnerability Existed: yes Memory Safety Vulnerability [third_party/rust/textwrap/src/lib.rs] [Lines around #![forbid(unsafe_code)]] Old Code: (No explicit unsafe code prohibition) Fixed Code: #![forbid(unsafe_code)] // See https://github.com/mgeisler/textwrap/issues/210 This change explicitly forbids unsafe code in the library, which helps prevent memory safety issues. The comment references issue #210 which likely discussed potential security implications of unsafe code. 2. Vulnerability Existed: not sure Potential Integer Overflow/Underflow [third_party/rust/textwrap/src/lib.rs] [Various width calculations] Old Code: (No explicit checks for width calculations) Fixed Code: Added saturating_sub() in width calculations (e.g., line 1372-1375) While not explicitly a security fix, the addition of saturating arithmetic operations helps prevent potential integer overflow/underflow issues in width calculations. 3. Vulnerability Existed: not sure Input Validation [third_party/rust/textwrap/src/lib.rs] [wrap_columns function] Old Code: (No explicit input validation) Fixed Code: Added assert!(columns > 0) in wrap_columns function This change adds basic input validation to prevent potential issues with zero columns, though it's unclear if this was specifically addressing a security vulnerability. The most clear security-related change is the addition of #![forbid(unsafe_code)], which is a proactive measure to prevent memory safety issues. The other changes appear to be more about robustness and correctness rather than addressing specific security vulnerabilities.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.pattern.repeat.empty.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.pattern.repeat.empty.worker.js@@ -13,8 +13,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#f00'; ctx.fillRect(0, 0, 100, 50);@@ -32,10 +32,10 @@ var pattern = ctx.createPattern(bitmap, ""); ctx.fillStyle = pattern; ctx.fillRect(0, 0, 200, 50);- _assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");- _assertPixel(offscreenCanvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");- _assertPixel(offscreenCanvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");- _assertPixel(offscreenCanvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255");+ _assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");+ _assertPixel(canvas, 98,1, 0,255,0,255, "98,1", "0,255,0,255");+ _assertPixel(canvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");+ _assertPixel(canvas, 98,48, 0,255,0,255, "98,48", "0,255,0,255"); }, t_fail); }).then(t_pass, t_fail);
After analyzing the provided code diff, I don't find any security vulnerabilities. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and corresponding updates to the variable references in the assertions. Here's the analysis:
1. Vulnerability Existed: no
No Vulnerability Found [testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.pattern.repeat.empty.worker.js] [Lines 13-32]
[Old Code: var offscreenCanvas = new OffscreenCanvas(100, 50); ... _assertPixel(offscreenCanvas, ...)]
[Fixed Code: var canvas = new OffscreenCanvas(100, 50); ... _assertPixel(canvas, ...)]
The changes are purely cosmetic/refactoring in nature and don't affect security. The functionality remains identical, just with a renamed variable for better clarity or consistency. There are no security-related patterns being modified (no changes to input validation, no changes to security-sensitive operations, etc.).
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/css/css-shapes/shape-outside/shape-box/shape-outside-content-box-001.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-shapes/shape-outside/shape-box/shape-outside-content-box-001.html@@ -9,7 +9,6 @@ <link rel="author" title="Mozilla" href="http://www.mozilla.org/"> <link rel="help" href="https://drafts.csswg.org/css-shapes-1/#shapes-from-box-values"> <link rel="match" href="reference/shape-outside-content-box-001-ref.html">- <meta name="flags" content=""> <meta name="assert" content="Test the boxes are wrapping around the left float shape defined by the content-box value."> <style> .container {
Analysis of the provided code diff:
1. Vulnerability Existed: no
No security vulnerability found [File] [Lines 9]
Old Code: <meta name="flags" content="">
Fixed Code: (line removed)
Additional Notes:
- The diff shows removal of an empty meta "flags" tag, which appears to be a test configuration cleanup rather than a security fix
- No security-related changes or vulnerabilities are apparent in this diff
- The modification is related to test metadata rather than functional code that could introduce 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/gfx/wr/webrender/src/glyph_rasterizer/mod.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/gfx/wr/webrender/src/glyph_rasterizer/mod.rs@@ -604,8 +604,8 @@ } #[allow(dead_code)]- pub fn get_extra_strikes(&self, x_scale: f64) -> usize {- if self.flags.contains(FontInstanceFlags::SYNTHETIC_BOLD) {+ pub fn get_extra_strikes(&self, flags: FontInstanceFlags, x_scale: f64) -> usize {+ if self.flags.intersects(flags) { let mut bold_offset = self.size.to_f64_px() / 48.0; if bold_offset < 1.0 { bold_offset = 0.25 + 0.75 * bold_offset;@@ -770,6 +770,119 @@ GlyphFormat::ColorBitmap => ImageFormat::BGRA8, } }+}++#[allow(dead_code)]+#[inline]+fn blend_strike_pixel(dest: u8, src: u32, src_alpha: u32) -> u8 {+ // Assume premultiplied alpha such that src and dest are already multiplied+ // by their respective alpha values and in range 0..=255. The rounded over+ // blend is then (src * 255 + dest * (255 - src_alpha) + 128) / 255.+ // We approximate (x + 128) / 255 as (x + 128 + ((x + 128) >> 8)) >> 8.+ let x = src * 255 + dest as u32 * (255 - src_alpha) + 128;+ ((x + (x >> 8)) >> 8) as u8+}++// Blends a single strike at a given offset into a destination buffer, assuming+// the destination has been allocated with enough extra space to accommodate the+// offset.+#[allow(dead_code)]+fn blend_strike(+ dest_bitmap: &mut [u8],+ src_bitmap: &[u8],+ width: usize,+ height: usize,+ subpixel_mask: bool,+ offset: f64,+) {+ let dest_stride = dest_bitmap.len() / height;+ let src_stride = width * 4;+ let offset_integer = offset.floor() as usize * 4;+ let offset_fract = (offset.fract() * 256.0) as u32;+ for (src_row, dest_row) in src_bitmap.chunks(src_stride).zip(dest_bitmap.chunks_mut(dest_stride)) {+ let mut prev_px = [0u32; 4];+ let dest_row_offset = &mut dest_row[offset_integer .. offset_integer + src_stride];+ for (src, dest) in src_row.chunks(4).zip(dest_row_offset.chunks_mut(4)) {+ let px = [src[0] as u32, src[1] as u32, src[2] as u32, src[3] as u32];+ // Blend current pixel with previous pixel based on fractional offset.+ let next_px = [px[0] * offset_fract,+ px[1] * offset_fract,+ px[2] * offset_fract,+ px[3] * offset_fract];+ let offset_px = [(((px[0] << 8) - next_px[0]) + prev_px[0] + 128) >> 8,+ (((px[1] << 8) - next_px[1]) + prev_px[1] + 128) >> 8,+ (((px[2] << 8) - next_px[2]) + prev_px[2] + 128) >> 8,+ (((px[3] << 8) - next_px[3]) + prev_px[3] + 128) >> 8];+ if subpixel_mask {+ // Subpixel masks assume each component is an independent weight.+ dest[0] = blend_strike_pixel(dest[0], offset_px[0], offset_px[0]);+ dest[1] = blend_strike_pixel(dest[1], offset_px[1], offset_px[1]);+ dest[2] = blend_strike_pixel(dest[2], offset_px[2], offset_px[2]);+ dest[3] = blend_strike_pixel(dest[3], offset_px[3], offset_px[3]);+ } else {+ // Otherwise assume we have a premultiplied alpha BGRA value.+ dest[0] = blend_strike_pixel(dest[0], offset_px[0], offset_px[3]);+ dest[1] = blend_strike_pixel(dest[1], offset_px[1], offset_px[3]);+ dest[2] = blend_strike_pixel(dest[2], offset_px[2], offset_px[3]);+ dest[3] = blend_strike_pixel(dest[3], offset_px[3], offset_px[3]);+ }+ // Save the remainder for blending onto the next pixel.+ prev_px = next_px;+ }+ if offset_fract > 0 {+ // When there is fractional offset, there will be a remaining value+ // from the previous pixel but no next pixel, so just use that.+ let dest = &mut dest_row[offset_integer + src_stride .. ];+ let offset_px = [(prev_px[0] + 128) >> 8,+ (prev_px[1] + 128) >> 8,+ (prev_px[2] + 128) >> 8,+ (prev_px[3] + 128) >> 8];+ if subpixel_mask {+ dest[0] = blend_strike_pixel(dest[0], offset_px[0], offset_px[0]);+ dest[1] = blend_strike_pixel(dest[1], offset_px[1], offset_px[1]);+ dest[2] = blend_strike_pixel(dest[2], offset_px[2], offset_px[2]);+ dest[3] = blend_strike_pixel(dest[3], offset_px[3], offset_px[3]);+ } else {+ dest[0] = blend_strike_pixel(dest[0], offset_px[0], offset_px[3]);+ dest[1] = blend_strike_pixel(dest[1], offset_px[1], offset_px[3]);+ dest[2] = blend_strike_pixel(dest[2], offset_px[2], offset_px[3]);+ dest[3] = blend_strike_pixel(dest[3], offset_px[3], offset_px[3]);+ }+ }+ }+}++// Applies multistrike bold to a source bitmap. This assumes the source bitmap+// is a tighly packed slice of BGRA pixel values of exactly the specified width+// and height. The specified extra strikes and pixel step control where to put+// each strike. The pixel step is allowed to have a fractional offset and does+// not strictly need to be integer.+#[allow(dead_code)]+pub fn apply_multistrike_bold(+ src_bitmap: &[u8],+ width: usize,+ height: usize,+ subpixel_mask: bool,+ extra_strikes: usize,+ pixel_step: f64,+) -> (Vec<u8>, usize) {+ let src_stride = width * 4;+ // The amount of extra width added to the bitmap from the extra strikes.+ let extra_width = (extra_strikes as f64 * pixel_step).ceil() as usize;+ let dest_width = width + extra_width;+ let dest_stride = dest_width * 4;+ // Zero out the initial bitmap so any extra width is cleared.+ let mut dest_bitmap = vec![0u8; dest_stride * height];+ for (src_row, dest_row) in src_bitmap.chunks(src_stride).zip(dest_bitmap.chunks_mut(dest_stride)) {+ // Copy the initial bitmap strike rows directly from the source.+ dest_row[0 .. src_stride].copy_from_slice(src_row);+ }+ // Finally blend each extra strike in turn.+ for i in 1 ..= extra_strikes {+ let offset = i as f64 * pixel_step;+ blend_strike(&mut dest_bitmap, src_bitmap, width, height, subpixel_mask, offset);+ }+ (dest_bitmap, dest_width) } pub struct RasterizedGlyph {
Analyzing the provided code diff, here are the potential security vulnerabilities:
1. Vulnerability Existed: not sure
Integer Overflow or Underflow [File] [Lines 604-608]
Old Code:
```rust
pub fn get_extra_strikes(&self, x_scale: f64) -> usize {
if self.flags.contains(FontInstanceFlags::SYNTHETIC_BOLD) {
```
Fixed Code:
```rust
pub fn get_extra_strikes(&self, flags: FontInstanceFlags, x_scale: f64) -> usize {
if self.flags.intersects(flags) {
```
Additional Details: The change modifies the flag checking logic but it's unclear if this was fixing a security issue or just a functional improvement.
2. Vulnerability Existed: not sure
Buffer Overflow [File] [Lines 770-119]
Old Code: (No equivalent code existed before)
Fixed Code: (New blend_strike and apply_multistrike_bold functions added)
Additional Details: The new functions handle pixel blending and bitmap manipulation. While they appear to have proper bounds checking (using chunks and explicit width/height parameters), the complexity of the operations warrants careful review for potential buffer overflow issues in edge cases.
3. Vulnerability Existed: not sure
Arithmetic Precision Issues [File] [Lines 770-119]
Old Code: (No equivalent code existed before)
Fixed Code: (New floating-point arithmetic in blend_strike function)
Additional Details: The new code performs extensive floating-point arithmetic for pixel blending. While not obviously vulnerable, precision issues in graphics operations could potentially lead to security-relevant rendering artifacts.
Note: The diff shows significant new functionality being added (bold strike blending operations) rather than clear security fixes. The changes appear to be feature additions with potential security implications rather than direct vulnerability fixes. Without more context about the specific security issue being addressed, it's difficult to identify definitive 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/accessible/base/Pivot.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/accessible/base/Pivot.cpp@@ -547,8 +547,9 @@ // Match if no node below this is a match if ((filtered & nsIAccessibleTraversalRule::FILTER_MATCH) && !match) {- nsIntRect childRect = child->IsLocal() ? child->AsLocal()->Bounds()- : child->AsRemote()->Bounds();+ LayoutDeviceIntRect childRect = child->IsLocal()+ ? child->AsLocal()->Bounds()+ : child->AsRemote()->Bounds(); // Double-check child's bounds since the deepest child may have been out // of bounds. This assures we don't return a false positive. if (childRect.Contains(aX, aY)) {
Let me analyze this code diff for potential security fixes:
Vulnerability Existed: not sure
[Potential Integer Overflow/Type Safety Issue] [accessible/base/Pivot.cpp] [Lines 547-549]
[Old Code]
nsIntRect childRect = child->IsLocal() ? child->AsLocal()->Bounds()
: child->AsRemote()->Bounds();
[Fixed Code]
LayoutDeviceIntRect childRect = child->IsLocal()
? child->AsLocal()->Bounds()
: child->AsRemote()->Bounds();
Additional Details:
- The change involves replacing `nsIntRect` with `LayoutDeviceIntRect` for storing bounds information
- This appears to be a type safety improvement, but it's unclear if this was fixing an actual security vulnerability
- The change might be related to preventing potential integer overflow issues or ensuring consistent coordinate handling
- Without more context about the specific bounds calculations, I can't definitively say this was fixing a security issue
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/taskcluster/gecko_taskgraph/generator.py+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/taskcluster/gecko_taskgraph/generator.py@@ -7,22 +7,23 @@ import copy import attr+from taskgraph.config import GraphConfig+from taskgraph.parameters import parameters_loader from taskgraph.util.yaml import load_yaml from . import filter_tasks from .graph import Graph+from .morph import morph+from .optimize import optimize_task_graph+from .task import Task from .taskgraph import TaskGraph-from .task import Task-from .optimize import optimize_task_graph-from .morph import morph-from .parameters import Parameters+from .transforms.base import TransformSequence, TransformConfig from .util.python_path import find_object-from .transforms.base import TransformSequence, TransformConfig from .util.verify import ( verify_docs, verifications, )-from .config import load_graph_config, GraphConfig+from .config import load_graph_config logger = logging.getLogger(__name__)@@ -482,7 +483,7 @@ # make parameters read-write parameters = dict(parameters) parameters["target-kind"] = kind- parameters = Parameters(strict=False, **parameters)+ parameters = parameters_loader(spec=None, strict=False, overrides=parameters) tgg = TaskGraphGenerator(root_dir=root_dir, parameters=parameters) return { task.task["metadata"]["name"]: task
Based on the provided diff, I'll analyze it for security vulnerabilities:
1. Vulnerability Existed: not sure
[Potential Parameter Handling Vulnerability] [taskcluster/gecko_taskgraph/generator.py] [Lines 482-485]
[Old Code]
parameters = dict(parameters)
parameters["target-kind"] = kind
parameters = Parameters(strict=False, **parameters)
[Fixed Code]
parameters = dict(parameters)
parameters["target-kind"] = kind
parameters = parameters_loader(spec=None, strict=False, overrides=parameters)
Note: The change involves switching from direct Parameters class instantiation to using a parameters_loader function. While this might indicate a security improvement in parameter handling (potentially better validation or sanitization), without seeing the implementation of parameters_loader, I can't be certain if this fixes a specific vulnerability. The change could be related to better parameter validation or security hardening.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/neqo-http3/src/recv_message.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/neqo-http3/src/recv_message.rs@@ -4,17 +4,18 @@ // option. This file may not be copied, modified, or distributed // except according to those terms.-use crate::hframe::{HFrame, HFrameReader, H3_FRAME_TYPE_HEADERS};+use crate::frames::{FrameReader, HFrame, StreamReaderConnectionWrapper, H3_FRAME_TYPE_HEADERS}; use crate::push_controller::PushController; use crate::{ headers_checks::{headers_valid, is_interim}, priority::PriorityHandler, qlog, CloseType, Error, Http3StreamInfo, Http3StreamType, HttpRecvStream, HttpRecvStreamEvents,- MessageType, ReceiveOutput, RecvStream, Res, Stream,+ MessageType, Priority, ReceiveOutput, RecvStream, Res, Stream, }; use neqo_common::{qdebug, qinfo, qtrace, Header}; use neqo_qpack::decoder::QPackDecoder; use neqo_transport::{Connection, StreamId};+use std::any::Any; use std::cell::RefCell; use std::cmp::min; use std::collections::VecDeque;@@ -52,11 +53,11 @@ */ #[derive(Debug)] enum RecvMessageState {- WaitingForResponseHeaders { frame_reader: HFrameReader },+ WaitingForResponseHeaders { frame_reader: FrameReader }, DecodingHeaders { header_block: Vec<u8>, fin: bool },- WaitingForData { frame_reader: HFrameReader },+ WaitingForData { frame_reader: FrameReader }, ReadingData { remaining_data_len: usize },- WaitingForFinAfterTrailers { frame_reader: HFrameReader },+ WaitingForFinAfterTrailers { frame_reader: FrameReader }, ClosePending, // Close must first be read by application Closed, ExtendedConnect,@@ -98,9 +99,9 @@ Self { state: RecvMessageState::WaitingForResponseHeaders { frame_reader: if message_info.header_frame_type_read {- HFrameReader::new_with_type(H3_FRAME_TYPE_HEADERS)+ FrameReader::new_with_type(H3_FRAME_TYPE_HEADERS) } else {- HFrameReader::new()+ FrameReader::new() }, }, message_type: message_info.message_type,@@ -124,7 +125,7 @@ } RecvMessageState::WaitingForData { ..} => { // TODO implement trailers, for now just ignore them.- self.state = RecvMessageState::WaitingForFinAfterTrailers{frame_reader: HFrameReader::new()};+ self.state = RecvMessageState::WaitingForFinAfterTrailers{frame_reader: FrameReader::new()}; } RecvMessageState::WaitingForFinAfterTrailers {..} => { return Err(Error::HttpFrameUnexpected);@@ -188,14 +189,15 @@ self.set_closed(); } else { self.state = if is_web_transport {+ self.stream_type = Http3StreamType::ExtendedConnect; RecvMessageState::ExtendedConnect } else if interim { RecvMessageState::WaitingForResponseHeaders {- frame_reader: HFrameReader::new(),+ frame_reader: FrameReader::new(), } } else { RecvMessageState::WaitingForData {- frame_reader: HFrameReader::new(),+ frame_reader: FrameReader::new(), } }; }@@ -264,7 +266,10 @@ RecvMessageState::WaitingForResponseHeaders { frame_reader } | RecvMessageState::WaitingForData { frame_reader } | RecvMessageState::WaitingForFinAfterTrailers { frame_reader } => {- match frame_reader.receive(conn, self.stream_id)? {+ match frame_reader.receive(&mut StreamReaderConnectionWrapper::new(+ conn,+ self.stream_id,+ ))? { (None, true) => { break self.set_state_to_close_pending(post_readable_event); }@@ -410,7 +415,7 @@ let to_read = min(*remaining_data_len, buf.len() - written); let (amount, fin) = conn .stream_recv(self.stream_id, &mut buf[written..written + to_read])- .map_err(|e| Error::map_stream_recv_errors(&e))?;+ .map_err(|e| Error::map_stream_recv_errors(&Error::from(e)))?; qlog::h3_data_moved_up(conn.qlog_mut(), self.stream_id, amount); debug_assert!(amount <= to_read);@@ -425,7 +430,7 @@ break Ok((written, fin)); } else if *remaining_data_len == 0 { self.state = RecvMessageState::WaitingForData {- frame_reader: HFrameReader::new(),+ frame_reader: FrameReader::new(), }; self.receive_internal(conn, false)?; } else {@@ -468,15 +473,30 @@ self.receive(conn) }- fn priority_handler_mut(&mut self) -> &mut PriorityHandler {- &mut self.priority_handler+ fn maybe_update_priority(&mut self, priority: Priority) -> bool {+ self.priority_handler.maybe_update_priority(priority)+ }++ fn priority_update_frame(&mut self) -> Option<HFrame> {+ self.priority_handler.maybe_encode_frame(self.stream_id)+ }++ fn priority_update_sent(&mut self) {+ self.priority_handler.priority_update_sent(); } fn set_new_listener(&mut self, conn_events: Box<dyn HttpRecvStreamEvents>) {+ self.state = RecvMessageState::WaitingForData {+ frame_reader: FrameReader::new(),+ }; self.conn_events = conn_events; } fn extended_connect_wait_for_response(&self) -> bool { matches!(self.state, RecvMessageState::ExtendedConnect) }-}++ fn any(&self) -> &dyn Any {+ self+ }+}
I'll analyze the code diff for security fixes following the specified format. The changes appear to be primarily structural refactoring rather than direct security fixes, but I'll examine them carefully.
1. Vulnerability Existed: not sure
[Potential Error Handling Improvement] [third_party/rust/neqo-http3/src/recv_message.rs] [Lines 415]
Old Code:
.map_err(|e| Error::map_stream_recv_errors(&e))?;
Fixed Code:
.map_err(|e| Error::map_stream_recv_errors(&Error::from(e)))?;
2. Vulnerability Existed: not sure
[State Management Improvement] [third_party/rust/neqo-http3/src/recv_message.rs] [Multiple lines]
Old Code:
Used HFrameReader directly
Fixed Code:
Replaced with FrameReader and StreamReaderConnectionWrapper
3. Vulnerability Existed: not sure
[Priority Handling Improvement] [third_party/rust/neqo-http3/src/recv_message.rs] [Lines 473-483]
Old Code:
fn priority_handler_mut(&mut self) -> &mut PriorityHandler {
&mut self.priority_handler
}
Fixed Code:
Multiple new methods for priority handling (maybe_update_priority, priority_update_frame, priority_update_sent)
4. Vulnerability Existed: not sure
[State Reset on Listener Change] [third_party/rust/neqo-http3/src/recv_message.rs] [Lines 485-487]
Old Code:
No state reset when setting new listener
Fixed Code:
Resets state to WaitingForData when setting new listener
Note: While these changes appear to be improvements in code structure and error handling, I couldn't identify any specific, named vulnerabilities being fixed. The changes seem more focused on refactoring and improving robustness rather than patching known security issues. The error handling change might address potential error propagation issues, but without more context about the specific vulnerabilities being targeted, I can't be certain.
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-transforms/scaley.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-transforms/scaley.html@@ -4,7 +4,6 @@ <link rel="author" title="Ebay Inc." href="mailto:[email protected]"/> <link rel="help" href="https://www.w3.org/TR/css-transforms-1/#funcdef-transform-scaley"/> <link rel="match" href="scaley-ref.html"/>- <meta name="flags" content="" /> <meta name="assert" content="scale y 2"/> <style type="text/css"> .container {
Analysis of the provided code diff: 1. Vulnerability Existed: no No security vulnerability found [File] testing/web-platform/tests/css/css-transforms/scaley.html [Lines] 4-7 [Old Code] <meta name="flags" content="" /> [Fixed Code] (removed line) Additional Details: - The change simply removes an empty meta tag with a "flags" attribute, which appears to be test-related metadata - This modification doesn't appear to address any security vulnerability - The change is likely related to test cleanup or removing unused metadata - No CVE or known vulnerability pattern matches 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/html/canvas/offscreen/fill-and-stroke-styles/2d.fillStyle.parse.invalid.css-color-4-hsla-1.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-hsla-1.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 = 'hsla(0, 100%, 50% / 1)'; } 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 don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming and don't involve any security-related modifications.
Here's the analysis following your requested format:
Vulnerability Existed: no
No security 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 simply rename the variable from `offscreenCanvas` to `canvas` for consistency or readability, without any security implications. The functionality remains exactly the same.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/the-canvas-state/2d.state.saverestore.globalCompositeOperation.worker.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/the-canvas-state/2d.state.saverestore.globalCompositeOperation.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'); // Test that restore() undoes any modifications var old = ctx.globalCompositeOperation;
Analysis of the provided code diff:
1. Vulnerability Existed: no
Variable Renaming [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: This appears to be a simple variable renaming from 'offscreenCanvas' to 'canvas' for consistency or readability. No security implications were identified in this change.
2. Vulnerability Existed: no
No functional changes detected [File] [No specific lines]
Old Code: N/A
Fixed Code: N/A
Additional Details: The diff shows only variable name changes with no modifications to the actual logic or security-relevant aspects of the code. The test functionality remains identical before and after the 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/browser/modules/test/browser/browser_UsageTelemetry.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/modules/test/browser/browser_UsageTelemetry.js@@ -25,9 +25,6 @@ const { SessionStore } = ChromeUtils.import( "resource:///modules/sessionstore/SessionStore.jsm" );--// Glean's here on `window`, but eslint doesn't know that. bug 1715542.-/* global Glean:false */ // Reset internal URI counter in case URIs were opened by other tests. Services.obs.notifyObservers(null, TELEMETRY_SUBSESSION_TOPIC);
Based on the provided diff, I'll analyze it for potential security vulnerabilities: 1. Vulnerability Existed: no Vulnerability Name: N/A (Code comment removal) File: browser/modules/test/browser/browser_UsageTelemetry.js Old Code: // Glean's here on `window`, but eslint doesn't know that. bug 1715542 /* global Glean:false */ Fixed Code: [removed] Additional Details: - The change simply removes a comment and a global variable declaration that was likely no longer needed. - This appears to be a cleanup change rather than a security fix. - No actual code logic was changed, just comments/declarations removed. - The bug reference (1715542) suggests this was related to ESLint configuration rather than a security issue. No security vulnerabilities were identified in this diff. The change appears to be a minor cleanup of comments and declarations.
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/crossbeam-channel/src/flavors/array.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/crossbeam-channel/src/flavors/array.rs@@ -10,7 +10,7 @@ use std::cell::UnsafeCell; use std::marker::PhantomData;-use std::mem::{self, MaybeUninit};+use std::mem::MaybeUninit; use std::ptr; use std::sync::atomic::{self, AtomicUsize, Ordering}; use std::time::Instant;@@ -110,7 +110,7 @@ // Allocate a buffer of `cap` slots initialized // with stamps. let buffer = {- let mut boxed: Box<[Slot<T>]> = (0..cap)+ let boxed: Box<[Slot<T>]> = (0..cap) .map(|i| { // Set the stamp to `{ lap: 0, mark: 0, index: i }`. Slot {@@ -119,9 +119,7 @@ } }) .collect();- let ptr = boxed.as_mut_ptr();- mem::forget(boxed);- ptr+ Box::into_raw(boxed) as *mut Slot<T> }; Channel {
Here's the analysis of the provided code diff for security fixes:
1. Vulnerability Existed: not sure
[Potential Memory Leak or Unsafe Pointer Handling] [third_party/rust/crossbeam-channel/src/flavors/array.rs] [Lines 110-119]
[Old Code]
let mut boxed: Box<[Slot<T>]> = (0..cap)
.map(|i| {
// Set the stamp to `{ lap: 0, mark: 0, index: i }`.
Slot {
stamp: AtomicUsize::new(i),
msg: UnsafeCell::new(MaybeUninit::uninit()),
}
})
.collect();
let ptr = boxed.as_mut_ptr();
mem::forget(boxed);
ptr
[Fixed Code]
let boxed: Box<[Slot<T>]> = (0..cap)
.map(|i| {
// Set the stamp to `{ lap: 0, mark: 0, index: i }`.
Slot {
stamp: AtomicUsize::new(i),
msg: UnsafeCell::new(MaybeUninit::uninit()),
}
})
.collect();
Box::into_raw(boxed) as *mut Slot<T>
Additional Details:
- The change replaces manual pointer handling with `Box::into_raw()`, which is a safer and more idiomatic way to convert a Box into a raw pointer
- The old code used `mem::forget()` which could potentially lead to memory leaks if not handled correctly
- While not clearly a security vulnerability, the change improves memory safety by using standard library functions designed for this purpose
- The removal of `use std::mem::{self, MaybeUninit}` suggests a cleanup of unused imports, which doesn't appear to be security-related
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.isPointInPath.subpath.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.isPointInPath.subpath.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.rect(0, 0, 20, 20); ctx.beginPath();
Based on the provided code diff, here's the analysis:
Vulnerability Existed: no
[No specific vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.isPointInPath.subpath.html] [Lines 17-18]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
Additional Details:
The change appears to be a simple variable renaming from `offscreenCanvas` to `canvas`. This doesn't appear to address any security vulnerability but rather improves code consistency or readability. There are no security-related changes in this diff, such as input validation, access control, or security-sensitive function modifications.
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/filesystem/compat/FileSystem.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/filesystem/compat/FileSystem.cpp@@ -7,7 +7,6 @@ #include "FileSystem.h" #include "FileSystemRootDirectoryEntry.h" #include "mozilla/dom/FileSystemBinding.h"-#include "nsContentUtils.h" #include "nsIDUtils.h" namespace mozilla::dom {@@ -29,7 +28,7 @@ MOZ_ASSERT(aGlobalObject); nsID id;- nsresult rv = nsContentUtils::GenerateUUIDInPlace(id);+ nsresult rv = nsID::GenerateUUIDInPlace(id); if (NS_WARN_IF(NS_FAILED(rv))) { return nullptr; }
Here's the analysis of the provided code diff:
1. Vulnerability Existed: not sure
[Potential UUID Generation Vulnerability] [dom/filesystem/compat/FileSystem.cpp] [Lines 29-32]
[Old Code]
nsID id;
nsresult rv = nsContentUtils::GenerateUUIDInPlace(id);
if (NS_WARN_IF(NS_FAILED(rv))) {
return nullptr;
}
[Fixed Code]
nsID id;
nsresult rv = nsID::GenerateUUIDInPlace(id);
if (NS_WARN_IF(NS_FAILED(rv))) {
return nullptr;
}
Additional Details:
- The change involves switching from `nsContentUtils::GenerateUUIDInPlace` to `nsID::GenerateUUIDInPlace`
- While this appears to be a security-related change (UUID generation is often security-sensitive), I can't determine if the old version had a specific vulnerability
- The change might be related to:
* Moving to a more direct/secure UUID generation method
* Removing a dependency on nsContentUtils
* Following better encapsulation practices
- Without more context about the implementations of both methods, I can't definitively say if this fixed a vulnerability
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/layout/svg/SVGTextFrame.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/layout/svg/SVGTextFrame.cpp@@ -855,6 +855,10 @@ if (aFlags & eNoHorizontalOverflow) { x = 0.0; width = textRun->GetAdvanceWidth(range, &provider);+ if (width < 0.0) {+ x = width;+ width = -width;+ } } else { x = metrics.mBoundingBox.x; width = metrics.mBoundingBox.width;@@ -5362,6 +5366,24 @@ return result - framePosition; }+Rect SVGTextFrame::TransformFrameRectFromTextChild(+ const Rect& aRect, const nsIFrame* aChildFrame) {+ nscoord appUnitsPerDevPixel = PresContext()->AppUnitsPerDevPixel();+ nsRect r = LayoutDevicePixel::ToAppUnits(+ LayoutDeviceRect::FromUnknownRect(aRect), appUnitsPerDevPixel);+ gfxRect resultCssUnits = TransformFrameRectFromTextChild(r, aChildFrame);+ float devPixelPerCSSPixel =+ float(AppUnitsPerCSSPixel()) / appUnitsPerDevPixel;+ resultCssUnits.Scale(devPixelPerCSSPixel);+ return ToRect(resultCssUnits);+}++Point SVGTextFrame::TransformFramePointFromTextChild(+ const Point& aPoint, const nsIFrame* aChildFrame) {+ return TransformFrameRectFromTextChild(Rect(aPoint, Size(1, 1)), aChildFrame)+ .TopLeft();+}+ void SVGTextFrame::AppendDirectlyOwnedAnonBoxes( nsTArray<OwnedAnonBox>& aResult) { MOZ_ASSERT(PrincipalChildList().FirstChild(), "Must have our anon box");
Analyzing the provided code diff, here are the potential security vulnerabilities:
1. Vulnerability Existed: yes
Integer Overflow/Underflow Vulnerability [File] layout/svg/SVGTextFrame.cpp [Lines 855-858]
[Old Code]
x = 0.0;
width = textRun->GetAdvanceWidth(range, &provider);
[Fixed Code]
x = 0.0;
width = textRun->GetAdvanceWidth(range, &provider);
if (width < 0.0) {
x = width;
width = -width;
}
2. Vulnerability Existed: not sure
Potential Arithmetic Overflow Vulnerability [File] layout/svg/SVGTextFrame.cpp [Lines 5366-5376]
[Old Code]
(None - new function added)
[Fixed Code]
float devPixelPerCSSPixel =
float(AppUnitsPerCSSPixel()) / appUnitsPerDevPixel;
resultCssUnits.Scale(devPixelPerCSSPixel);
3. Vulnerability Existed: not sure
Potential Coordinate Transformation Vulnerability [File] layout/svg/SVGTextFrame.cpp [Lines 5378-5381]
[Old Code]
(None - new function added)
[Fixed Code]
return TransformFrameRectFromTextChild(Rect(aPoint, Size(1, 1)), aChildFrame)
.TopLeft();
The first vulnerability is clearly addressed by adding bounds checking for negative width values, which could prevent potential integer underflow issues. The other two changes introduce new functionality where potential arithmetic overflows or coordinate transformation issues might exist, but without more context about how these functions are used, it's difficult to determine if they represent actual 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/third_party/rust/serde_yaml/src/ser.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/serde_yaml/src/ser.rs@@ -518,11 +518,7 @@ num::FpCategory::Infinite if v.is_sign_positive() => ".inf".into(), num::FpCategory::Infinite => "-.inf".into(), num::FpCategory::Nan => ".nan".into(),- _ => {- let mut buf = vec![];- dtoa::write(&mut buf, v).unwrap();- str::from_utf8(&buf).unwrap().into()- }+ _ => ryu::Buffer::new().format_finite(v).into(), })) }@@ -531,11 +527,7 @@ num::FpCategory::Infinite if v.is_sign_positive() => ".inf".into(), num::FpCategory::Infinite => "-.inf".into(), num::FpCategory::Nan => ".nan".into(),- _ => {- let mut buf = vec![];- dtoa::write(&mut buf, v).unwrap();- str::from_utf8(&buf).unwrap().into()- }+ _ => ryu::Buffer::new().format_finite(v).into(), })) }
Here's the analysis of the provided code diff:
1. Vulnerability Existed: yes
Potential Integer/FP Conversion Vulnerability [third_party/rust/serde_yaml/src/ser.rs] [Lines 518-527]
Old Code:
```rust
_ => {
let mut buf = vec![];
dtoa::write(&mut buf, v).unwrap();
str::from_utf8(&buf).unwrap().into()
}
```
Fixed Code:
```rust
_ => ryu::Buffer::new().format_finite(v).into(),
```
Additional Details: The change replaces dtoa with ryu for floating-point serialization. While not a direct security vulnerability, dtoa has had historical issues with floating-point conversion accuracy and potential buffer overflows. The switch to ryu provides more reliable and safer floating-point serialization.
2. Vulnerability Existed: not sure
Potential Panic Vulnerability [third_party/rust/serde_yaml/src/ser.rs] [Lines 518-527]
Old Code:
```rust
_ => {
let mut buf = vec![];
dtoa::write(&mut buf, v).unwrap();
str::from_utf8(&buf).unwrap().into()
}
```
Fixed Code:
```rust
_ => ryu::Buffer::new().format_finite(v).into(),
```
Additional Details: The old code used unwrap() which could panic if the conversion failed. The new code might be more robust, but without knowing ryu's implementation details, we can't be certain if it completely eliminates panic possibilities. The change appears to be moving toward safer floating-point serialization.
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/mozglue/static/rust/moz_asserts/lib.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/mozglue/static/rust/moz_asserts/lib.rs@@ -1,7 +1,6 @@ /* This Source Code Form is subject to the terms of the Mozilla Public * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at https://mozilla.org/MPL/2.0/. */- // Implementation note: It seems tempting to use if cfg!(feature = ...) directly // in the macro, but that doesn't work, as the feature would be evaluated@@ -19,10 +18,10 @@ // is also how rust's `debug_assert!` is implemented) /// Whether Nightly-only assertions are enabled.-pub const NIGHTLY_BUILD: bool = cfg!(feature = "nightly");+pub use mozbuild::config::NIGHTLY_BUILD; /// Whether diagnostic assertions are enabled.-pub const MOZ_DIAGNOSTIC_ASSERT_ENABLED: bool = cfg!(feature = "diagnostic");+pub use mozbuild::config::MOZ_DIAGNOSTIC_ASSERT_ENABLED; /// assert! on Nightly, gets compiled out otherwise. #[macro_export]
Based on the provided diff, I'll analyze it for security vulnerabilities: 1. Vulnerability Existed: not sure Build Configuration Exposure [File] mozglue/static/rust/moz_asserts/lib.rs [Lines 19,22] Old Code: ```rust pub const NIGHTLY_BUILD: bool = cfg!(feature = "nightly"); pub const MOZ_DIAGNOSTIC_ASSERT_ENABLED: bool = cfg!(feature = "diagnostic"); ``` Fixed Code: ```rust pub use mozbuild::config::NIGHTLY_BUILD; pub use mozbuild::config::MOZ_DIAGNOSTIC_ASSERT_ENABLED; ``` Additional Details: The change appears to be moving feature flag definitions from direct compile-time configuration to using centralized build configuration values. While this doesn't directly indicate a security vulnerability, it could be related to: 1. Preventing potential information leakage about build features 2. Centralizing configuration management 3. Making feature flags more consistent across the codebase However, without more context about how these flags are used or what security implications they might have, I can't definitively say this was a security fix. The change could also be purely architectural.
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/urlbar/tests/browser/browser_enter.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/components/urlbar/tests/browser/browser_enter.js@@ -139,17 +139,13 @@ ); const onLoad = BrowserTestUtils.browserLoaded(gBrowser.selectedBrowser);- const onBeforeUnload = SpecialPowers.spawn(- gBrowser.selectedBrowser,- [],- () => {- return new Promise(resolve => {- content.window.addEventListener("beforeunload", () => {- resolve();- });+ const onPageHide = SpecialPowers.spawn(gBrowser.selectedBrowser, [], () => {+ return new Promise(resolve => {+ content.window.addEventListener("pagehide", () => {+ resolve(); });- }- );+ });+ }); const onResult = SpecialPowers.spawn(gBrowser.selectedBrowser, [], () => { return new Promise(resolve => { content.window.addEventListener("keyup", () => {@@ -174,8 +170,8 @@ EventUtils.synthesizeKey("x", { type: "keydown" }); EventUtils.synthesizeKey("KEY_Enter", { type: "keydown" });- // Wait for beforeUnload event in the content.- await onBeforeUnload;+ // Wait for pagehide event in the content.+ await onPageHide; is( ownerDocument.activeElement, gURLBar.inputField,@@ -194,7 +190,7 @@ "The selectionEnd indicates at ending of the value" );- // Keyup both key as soon as beforeUnload event happens.+ // Keyup both key as soon as pagehide event happens. EventUtils.synthesizeKey("x", { type: "keyup" }); EventUtils.synthesizeKey("KEY_Enter", { type: "keyup" });@@ -266,3 +262,66 @@ // Cleanup. BrowserTestUtils.removeTab(tab); });++add_task(async function typeCharWhileProcessingEnter() {+ info("Typing a char while processing enter key");+ const tab = await BrowserTestUtils.openNewForegroundTab(+ gBrowser,+ START_VALUE+ );++ const onLoad = BrowserTestUtils.browserLoaded(+ gBrowser.selectedBrowser,+ false,+ `http://${START_VALUE}`+ );+ gURLBar.focus();++ info("Keydown Enter");+ EventUtils.synthesizeKey("KEY_Enter", { type: "keydown" });+ await TestUtils.waitForCondition(+ () => gURLBar._keyDownEnterDeferred,+ "Wait for starting process for the enter key"+ );++ info("Keydown a char");+ EventUtils.synthesizeKey("x", { type: "keydown" });++ info("Keyup both");+ EventUtils.synthesizeKey("x", { type: "keyup" });+ EventUtils.synthesizeKey("KEY_Enter", { type: "keyup" });++ Assert.equal(+ gURLBar.inputField.value,+ TEST_VALUE,+ "The value of urlbar is correct"+ );++ await onLoad;+ Assert.ok("Browser loaded the correct url");++ // Cleanup.+ BrowserTestUtils.removeTab(tab);+});++add_task(async function keyupEnterWhilePressingMeta() {+ const tab = await BrowserTestUtils.openNewForegroundTab(gBrowser);++ info("Keydown Meta+Enter");+ gURLBar.focus();+ gURLBar.value = "";+ EventUtils.synthesizeKey("KEY_Enter", { type: "keydown", metaKey: true });++ // Pressing Enter key while pressing Meta key, and next, even when releasing+ // Enter key before releasing Meta key, the keyup event is not fired.+ // Therefor, we fire Meta keyup event only.+ info("Keyup Meta");+ EventUtils.synthesizeKey("KEY_Meta", { type: "keyup" });++ // Check whether we can input on URL bar.+ EventUtils.synthesizeKey("a");+ is(gURLBar.value, "a", "Can input a char");++ // Cleanup.+ BrowserTestUtils.removeTab(tab);+});
Analyzing the provided code diff, I don't see any clear security vulnerabilities being fixed. The changes appear to be primarily about event handling improvements and test case additions. Here's the analysis:
1. First change (beforeunload → pagehide):
Vulnerability Existed: no
No security vulnerability - This is an event listener change from beforeunload to pagehide for better reliability in test cases.
2. New test case additions:
Vulnerability Existed: no
The added test cases (typeCharWhileProcessingEnter and keyupEnterWhilePressingMeta) are new test scenarios and don't represent security fixes.
The changes are focused on:
1. Improving test reliability by switching from beforeunload to pagehide event
2. Adding new test cases for edge scenarios in URL bar handling
3. No security-related patterns (like XSS, injection, etc.) are being modified
4. No sensitive data handling or permission-related changes are present
These appear to be standard test improvements rather than security fixes.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.