Shared security patch analysis results
AI Used: DEEPSEEK deepseek-chat--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/third_party/rust/neqo-http3/src/server_connection_events.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/neqo-http3/src/server_connection_events.rs@@ -6,7 +6,7 @@ use crate::connection::Http3State; use crate::{- features::extended_connect::{ExtendedConnectEvents, ExtendedConnectType},+ features::extended_connect::{ExtendedConnectEvents, ExtendedConnectType, SessionCloseReason}, CloseType, Http3StreamInfo, HttpRecvStreamEvents, Priority, RecvStreamEvents, SendStreamEvents, }; use neqo_common::Header;@@ -52,7 +52,7 @@ ExtendedConnectClosed { connect_type: ExtendedConnectType, stream_id: StreamId,- error: Option<AppError>,+ reason: SessionCloseReason, }, ExtendedConnectNewStream(Http3StreamInfo), }@@ -116,18 +116,24 @@ } impl ExtendedConnectEvents for Http3ServerConnEvents {- fn session_start(&self, _connect_type: ExtendedConnectType, _stream_id: StreamId) {}+ fn session_start(+ &self,+ _connect_type: ExtendedConnectType,+ _stream_id: StreamId,+ _status: u16,+ ) {+ } fn session_end( &self, connect_type: ExtendedConnectType, stream_id: StreamId,- error: Option<AppError>,+ reason: SessionCloseReason, ) { self.insert(Http3ServerConnEvent::ExtendedConnectClosed { connect_type, stream_id,- error,+ reason, }); }
Here's the analysis of the provided code diff following the specified format:
1. Vulnerability Existed: not sure
[Potentially Improved Error Handling] [third_party/rust/neqo-http3/src/server_connection_events.rs] [Lines 52, 116-124]
[Old Code]
```rust
ExtendedConnectClosed {
connect_type: ExtendedConnectType,
stream_id: StreamId,
error: Option<AppError>,
}
...
fn session_end(
&self,
connect_type: ExtendedConnectType,
stream_id: StreamId,
error: Option<AppError>,
)
```
[Fixed Code]
```rust
ExtendedConnectClosed {
connect_type: ExtendedConnectType,
stream_id: StreamId,
reason: SessionCloseReason,
}
...
fn session_end(
&self,
connect_type: ExtendedConnectType,
stream_id: StreamId,
reason: SessionCloseReason,
)
```
2. Vulnerability Existed: not sure
[Extended Session Start Parameters] [third_party/rust/neqo-http3/src/server_connection_events.rs] [Lines 116-119]
[Old Code]
```rust
fn session_start(&self, _connect_type: ExtendedConnectType, _stream_id: StreamId) {}
```
[Fixed Code]
```rust
fn session_start(
&self,
_connect_type: ExtendedConnectType,
_stream_id: StreamId,
_status: u16,
) {
}
```
Analysis Notes:
1. The change from `error: Option<AppError>` to `reason: SessionCloseReason` suggests a more structured way of handling session closure reasons, which might improve security by providing more detailed information about why sessions are closed. However, without seeing the `SessionCloseReason` implementation, I can't determine if this fixes a specific vulnerability.
2. The addition of a `status` parameter to `session_start` suggests better tracking of session initialization, but again, without more context, I can't determine if this fixes a specific vulnerability.
Neither change clearly indicates a fixed vulnerability, but both appear to be improvements in error/session handling that could potentially address 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/css-backgrounds/background-clip-008.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/css/css-backgrounds/background-clip-008.html@@ -7,7 +7,6 @@ <link rel="author" title="Gérard Talbot" href="http://www.gtalbot.org/BrowserBugsSection/css21testsuite/"> <link rel="reviewer" title="Gérard Talbot" href="http://www.gtalbot.org/BrowserBugsSection/css21testsuite/" /> <!-- 2013-04-09 --> <link rel="help" href="http://www.w3.org/TR/css3-background/#the-background-clip" title="3.7. Painting Area: the 'background-clip' property">- <meta name="flags" content=""> <meta name="assert" content="When 'background-clip' is set to 'padding-box', then the background painting area is clipped at the edges of the padding of the element. In this test, the padding box is 0px tall and as wide as the body element; therefore, red should not be visible."> <link rel="match" href="reference/ref-if-there-is-no-red.xht"> <style>
Based on the provided code diff, here's the analysis: Vulnerability Existed: no No security vulnerability found [File] testing/web-platform/tests/css/css-backgrounds/background-clip-008.html [Lines 7] Old Code: <meta name="flags" content=""> Fixed Code: (line removed) Additional Details: - The change simply removes an empty meta tag for "flags" which appears to be test-related metadata - No actual security vulnerability is being fixed here - This appears to be a minor cleanup change rather than a security patch - The modification doesn't affect any security-sensitive functionality Note: The diff shows typical test file maintenance rather than security fixes. The removed line was an empty metadata field that served no functional purpose in the test.
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/jpeg-xl/lib/include/jxl/decode.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/jpeg-xl/lib/include/jxl/decode.h@@ -16,6 +16,7 @@ #include <stddef.h> #include <stdint.h>+#include "jxl/cms_interface.h" #include "jxl/codestream_header.h" #include "jxl/color_encoding.h" #include "jxl/jxl_export.h"@@ -113,9 +114,9 @@ /** * Return value for JxlDecoderProcessInput.- * The values above 0x40 are optional informal events that can be subscribed to,- * they are never returned if they have not been registered with- * JxlDecoderSubscribeEvents.+ * The values from JXL_DEC_BASIC_INFO onwards are optional informative+ * events that can be subscribed to, they are never returned if they+ * have not been registered with JxlDecoderSubscribeEvents. */ typedef enum { /** Function call finished successfully, or decoding is finished and there is@@ -152,8 +153,8 @@ * requested and it is possible to decode a DC image from the codestream and * the DC out buffer was not yet set. This event re-occurs for new frames * if there are multiple animation frames.- * DEPRECATED: the DC feature in this form will be removed. You can use- * JxlDecoderFlushImage for progressive rendering.+ * DEPRECATED: the DC feature in this form will be removed. For progressive+ * rendering, JxlDecoderFlushImage should be used. */ JXL_DEC_NEED_DC_OUT_BUFFER = 4,@@ -228,8 +229,8 @@ * status only indicates we're past this point in the codestream. This event * occurs max once per frame and always later than JXL_DEC_FRAME_HEADER * and other header events and earlier than full resolution pixel data.- * DEPRECATED: the DC feature in this form will be removed. You can use- * JxlDecoderFlushImage for progressive rendering.+ * DEPRECATED: the DC feature in this form will be removed. For progressive+ * rendering, JxlDecoderFlushImage should be used. */ JXL_DEC_DC_IMAGE = 0x800,@@ -263,17 +264,18 @@ * @see JxlDecoderSetDecompressBoxes to configure whether to get the box * data decompressed, or possibly compressed. *- * Boxes can be compressed. This is so when their box type is "brob". In that- * case, they have an underlying decompressed box type and decompressed data.- * Use JxlDecoderSetDecompressBoxes to configure which data to get,- * decompressing them requires Brotli. JxlDecoderGetBoxType has a flag to- * get the compressed box type, which can be "brob", or the decompressed box- * type. If a box is not compressed (its compressed type is not "brob"), then- * you get the same decompressed box type and data no matter what setting is- * configured.+ * Boxes can be compressed. This is so when their box type is+ * "brob". In that case, they have an underlying decompressed box+ * type and decompressed data. JxlDecoderSetDecompressBoxes allows+ * configuring which data to get. Decompressing requires+ * Brotli. JxlDecoderGetBoxType has a flag to get the compressed box+ * type, which can be "brob", or the decompressed box type. If a box+ * is not compressed (its compressed type is not "brob"), then+ * the output decompressed box type and data is independent of what+ * setting is configured. * * The buffer set with JxlDecoderSetBoxBuffer must be set again for each next- * box that you want to get, or can be left unset to skip outputting this box.+ * box to be obtained, or can be left unset to skip outputting this box. * The output buffer contains the full box data when the next JXL_DEC_BOX * event or JXL_DEC_SUCCESS occurs. JXL_DEC_BOX occurs for all boxes, * including non-metadata boxes such as the signature box or codestream boxes.@@ -282,6 +284,19 @@ * "jumb" respectively. */ JXL_DEC_BOX = 0x4000,++ /** Informative event by JxlDecoderProcessInput: a progressive step in+ * decoding the frame is reached. When calling @ref JxlDecoderFlushImage at+ * this point, the flushed image will correspond exactly to this point in+ * decoding, and not yet contain partial results (such as partially more fine+ * detail) of a next step. By default, this event will trigger maximum once+ * per frame, when a 8x8th resolution (DC) image is ready (the image data is+ * still returned at full resolution, giving upscaled DC). Use @ref+ * JxlDecoderSetProgressiveDetail to configure more fine-grainedness. The+ * event is not guaranteed to trigger, not all images have progressive steps+ * or DC encoded.+ */+ JXL_DEC_FRAME_PROGRESSION = 0x8000, } JxlDecoderStatus; /** Rewinds decoder to the beginning. The same input must be given again from@@ -377,27 +392,28 @@ JXL_EXPORT JxlDecoderStatus JxlDecoderSubscribeEvents(JxlDecoder* dec, int events_wanted);-/** Enables or disables preserving of original orientation. Some images are- * encoded with an orientation tag indicating the image is rotated and/or- * mirrored (here called the original orientation).- *- * *) If keep_orientation is JXL_FALSE (the default): the decoder will perform- * work to undo the transformation. This ensures the decoded pixels will not- * be rotated or mirrored. The decoder will always set the orientation field- * of the JxlBasicInfo to JXL_ORIENT_IDENTITY to match the returned pixel data.- * The decoder may also swap xsize and ysize in the JxlBasicInfo compared to the- * values inside of the codestream, to correctly match the decoded pixel data,- * e.g. when a 90 degree rotation was performed.- *- * *) If this option is JXL_TRUE: then the image is returned as-is, which may be- * rotated or mirrored, and the user must check the orientation field in- * JxlBasicInfo after decoding to correctly interpret the decoded pixel data.+/** Enables or disables preserving of as-in-bitstream pixeldata+ * orientation. Some images are encoded with an Orientation tag+ * indicating that the decoder must perform a rotation and/or+ * mirroring to the encoded image data.+ *+ * *) If skip_reorientation is JXL_FALSE (the default): the decoder+ * will apply the transformation from the orientation setting, hence+ * rendering the image according to its specified intent. When+ * producing a JxlBasicInfo, the decoder will always set the+ * orientation field to JXL_ORIENT_IDENTITY (matching the returned+ * pixel data) and also align xsize and ysize so that they correspond+ * to the width and the height of the returned pixel data.+ *+ * *) If skip_reorientation is JXL_TRUE: the decoder will skip+ * applying the transformation from the orientation setting, returning+ * the image in the as-in-bitstream pixeldata orientation. * This may be faster to decode since the decoder doesn't have to apply the * transformation, but can cause wrong display of the image if the orientation * tag is not correctly taken into account by the user. *- * By default, this option is disabled, and the decoder automatically corrects- * the orientation.+ * By default, this option is disabled, and the returned pixel data is+ * re-oriented according to the image's Orientation setting. * * This function must be called at the beginning, before decoding is performed. *@@ -405,11 +421,11 @@ * possible values. * * @param dec decoder object- * @param keep_orientation JXL_TRUE to enable, JXL_FALSE to disable.+ * @param skip_reorientation JXL_TRUE to enable, JXL_FALSE to disable. * @return JXL_DEC_SUCCESS if no error, JXL_DEC_ERROR otherwise. */ JXL_EXPORT JxlDecoderStatus-JxlDecoderSetKeepOrientation(JxlDecoder* dec, JXL_BOOL keep_orientation);+JxlDecoderSetKeepOrientation(JxlDecoder* dec, JXL_BOOL skip_reorientation); /** Enables or disables rendering spot colors. By default, spot colors * are rendered, which is OK for viewing the decoded image. If render_spotcolors@@ -469,7 +485,7 @@ * have not been seen yet. * @return JXL_DEC_ERROR when decoding failed, e.g. invalid codestream. * TODO(lode) document the input data mechanism- * @return JXL_DEC_NEED_MORE_INPUT more input data is necessary.+ * @return JXL_DEC_NEED_MORE_INPUT when more input data is necessary. * @return JXL_DEC_BASIC_INFO when basic info such as image dimensions is * available and this informative event is subscribed to. * @return JXL_DEC_EXTENSIONS when JPEG XL codestream user extensions are@@ -479,7 +495,7 @@ * @return JXL_DEC_PREVIEW_IMAGE when preview pixel information is available and * output in the preview buffer. * @return JXL_DEC_DC_IMAGE when DC pixel information (8x8 downscaled version- * of the image) is available and output in the DC buffer.+ * of the image) is available and output is in the DC buffer. * @return JXL_DEC_FULL_IMAGE when all pixel information at highest detail is * available and has been output in the pixel buffer. */@@ -608,8 +624,8 @@ * It is often possible to use JxlDecoderGetColorAsICCProfile as an * alternative anyway. The following scenarios are possible: * - The JPEG XL image has an attached ICC Profile, in that case, the encoded- * structured data is not available, this function will return an error status- * and you must use JxlDecoderGetColorAsICCProfile instead.+ * structured data is not available, this function will return an error+ * status. JxlDecoderGetColorAsICCProfile should be called instead. * - The JPEG XL image has an encoded structured color profile, and it * represents an RGB or grayscale color space. This function will return it. * You can still use JxlDecoderGetColorAsICCProfile as well as an@@ -621,10 +637,10 @@ * an unknown or xyb color space. In that case, * JxlDecoderGetColorAsICCProfile is not available. *- * If you wish to render the image using a system that supports ICC profiles,- * use JxlDecoderGetColorAsICCProfile first. If you're looking for a specific- * color space possibly indicated in the JPEG XL image, use- * JxlDecoderGetColorAsEncodedProfile first.+ * When rendering an image on a system that supports ICC profiles,+ * JxlDecoderGetColorAsICCProfile should be used first. When rendering+ * for a specific color space, possibly indicated in the JPEG XL+ * image, JxlDecoderGetColorAsEncodedProfile should be used first. * * @param dec decoder object * @param format pixel format to output the data to. Only used for@@ -818,7 +834,7 @@ * @return JXL_DEC_SUCCESS on success, JXL_DEC_ERROR on error, such as * information not available yet. *- * DEPRECATED: the DC feature in this form will be removed. You can use+ * DEPRECATED: the DC feature in this form will be removed. Use * JxlDecoderFlushImage for progressive rendering. */ JXL_EXPORT JXL_DEPRECATED JxlDecoderStatus JxlDecoderDCOutBufferSize(@@ -839,7 +855,7 @@ * @return JXL_DEC_SUCCESS on success, JXL_DEC_ERROR on error, such as * size too small. *- * DEPRECATED: the DC feature in this form will be removed. You can use+ * DEPRECATED: the DC feature in this form will be removed. Use * JxlDecoderFlushImage for progressive rendering. */ JXL_EXPORT JXL_DEPRECATED JxlDecoderStatus JxlDecoderSetDCOutBuffer(@@ -883,8 +899,8 @@ JxlDecoder* dec, const JxlPixelFormat* format, void* buffer, size_t size); /**- * Callback function type for JxlDecoderSetImageOutCallback. @see- * JxlDecoderSetImageOutCallback for usage.+ * Function type for JxlDecoderSetImageOutCallback.+ * @see JxlDecoderSetImageOutCallback for usage. * * The callback may be called simultaneously by different threads when using a * threaded parallel runner, on different pixels.@@ -1138,6 +1154,20 @@ uint64_t* size); /**+ * Configures at which progressive steps in frame decoding the @ref+ * JXL_DEC_FRAME_PROGRESSION event occurs. By default, this is 0. The detail+ * values mean: 0 = only trigger for the DC image, the 8x8th lower resolution+ * image. 1 = also trigger when a full pass of groups is ready. Higher values+ * indicate more steps but are not yet implemented. Higher values always include+ * the events of lower values as well.+ *+ * @param dec decoder object+ * @param detail at which level of detail to trigger JXL_DEC_FRAME_PROGRESSION+ */+JXL_EXPORT void JxlDecoderSetProgressiveDetail(JxlDecoder* dec,+ uint32_t detail);++/** * Outputs progressive step towards the decoded image so far when only partial * input was received. If the flush was successful, the buffer set with * JxlDecoderSetImageOutBuffer will contain partial image data.
After analyzing the provided code diff, I don't identify any clear security vulnerabilities being fixed. The changes appear to be primarily documentation improvements, clarification of APIs, and addition of new features (like progressive decoding). Here's my analysis: 1. Vulnerability Existed: no No security vulnerability found [third_party/jpeg-xl/lib/include/jxl/decode.h] [Various lines] [Old code - various documentation and API changes] [Fixed code - improved documentation and new features] The changes include: - Added include for "jxl/cms_interface.h" - Documentation improvements and clarifications - Added new JXL_DEC_FRAME_PROGRESSION enum value - Renamed keep_orientation parameter to skip_reorientation for clarity - Added JxlDecoderSetProgressiveDetail function - Various wording improvements in comments These appear to be normal development improvements rather than security fixes. The changes focus on: 1. Better API documentation 2. New features for progressive decoding 3. Parameter naming improvements 4. Header file organization No actual code vulnerabilities were identified in the diff. The changes are either additive (new features) or documentation improvements without security implications.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/dom/ipc/BrowserChild.h+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/dom/ipc/BrowserChild.h@@ -471,8 +471,6 @@ const EffectsInfo& GetEffectsInfo() const { return mEffectsInfo; }- hal::ScreenOrientation GetOrientation() const { return mOrientation; }- void SetBackgroundColor(const nscolor& aColor); MOZ_CAN_RUN_SCRIPT_BOUNDARY virtual mozilla::ipc::IPCResult RecvUpdateEffects(@@ -806,7 +804,6 @@ CSSRect mUnscaledOuterRect; Maybe<bool> mLayersConnected; EffectsInfo mEffectsInfo;- hal::ScreenOrientation mOrientation; RefPtr<VsyncMainChild> mVsyncChild;
Let me analyze the code diff for potential security issues.
1. Vulnerability Existed: not sure
[Removed Screen Orientation API] [dom/ipc/BrowserChild.h] [Lines 471, 806]
[Old Code]
- hal::ScreenOrientation GetOrientation() const { return mOrientation; }
...
- hal::ScreenOrientation mOrientation;
[Fixed Code]
[These lines were completely removed]
Additional Details:
The diff shows removal of screen orientation related code (both the getter method and member variable). While this could be related to security (as screen orientation APIs can potentially be abused for fingerprinting), without more context about why these were removed, I can't be certain if this was specifically a security fix or just a refactoring. The removal does reduce the attack surface by eliminating a potential fingerprinting vector, but we'd need more information to confirm if this was addressing a specific 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/testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.strokeStyle.default.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.strokeStyle.default.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'); _assertSame(ctx.strokeStyle, '#000000', "ctx.strokeStyle", "'#000000'"); t.done();
Based on the provided diff, here's the analysis:
Vulnerability Existed: no
[No vulnerability found] [testing/web-platform/tests/html/canvas/offscreen/fill-and-stroke-styles/2d.strokeStyle.default.html] [Lines 17-18]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
Additional Details:
- The change appears to be purely a variable name change from `offscreenCanvas` to `canvas`
- No security implications are evident in this change
- The modification doesn't affect any security-sensitive operations or introduce/remove any security controls
- This seems to be a code style/consistency improvement rather than a security fix
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/accessible/android/RemoteAccessibleWrap.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/accessible/android/RemoteAccessibleWrap.cpp@@ -74,7 +74,9 @@ uint64_t RemoteAccessibleWrap::State() { return Proxy()->State(); }-nsIntRect RemoteAccessibleWrap::Bounds() const { return Proxy()->Bounds(); }+mozilla::LayoutDeviceIntRect RemoteAccessibleWrap::Bounds() const {+ return Proxy()->Bounds();+} void RemoteAccessibleWrap::ScrollTo(uint32_t aHow) const { Proxy()->ScrollTo(aHow);
Let me analyze the code diff for security fixes:
1. Vulnerability Existed: not sure
[Potential Integer Overflow/Type Safety] [accessible/android/RemoteAccessibleWrap.cpp] [Lines 74-76]
[Old Code]
nsIntRect RemoteAccessibleWrap::Bounds() const { return Proxy()->Bounds(); }
[Fixed Code]
mozilla::LayoutDeviceIntRect RemoteAccessibleWrap::Bounds() const {
return Proxy()->Bounds();
}
Additional Details:
- The change involves replacing `nsIntRect` with `mozilla::LayoutDeviceIntRect` for the Bounds() return type
- This appears to be a type safety improvement rather than a direct security fix
- The change might be related to preventing potential integer overflows or ensuring proper coordinate handling, but without more context about the types involved, I can't be certain
- The change could also be part of a larger refactoring for consistency rather than a security fix specifically
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/ash/src/extensions/khr/synchronization2.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/ash/src/extensions/khr/synchronization2.rs@@ -6,31 +6,15 @@ #[derive(Clone)] pub struct Synchronization2 {- handle: vk::Device,- synchronization2_fn: vk::KhrSynchronization2Fn,+ fp: vk::KhrSynchronization2Fn, } impl Synchronization2 { pub fn new(instance: &Instance, device: &Device) -> Self {- let synchronization2_fn = vk::KhrSynchronization2Fn::load(|name| unsafe {+ let fp = vk::KhrSynchronization2Fn::load(|name| unsafe { mem::transmute(instance.get_device_proc_addr(device.handle(), name.as_ptr())) });- Self {- handle: device.handle(),- synchronization2_fn,- }- }-- pub fn name() -> &'static CStr {- vk::KhrSynchronization2Fn::name()- }-- pub fn fp(&self) -> &vk::KhrSynchronization2Fn {- &self.synchronization2_fn- }-- pub fn device(&self) -> vk::Device {- self.handle+ Self { fp } } #[doc = "<https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCmdPipelineBarrier2KHR.html>"]@@ -39,7 +23,7 @@ command_buffer: vk::CommandBuffer, dependency_info: &vk::DependencyInfoKHR, ) {- self.synchronization2_fn+ self.fp .cmd_pipeline_barrier2_khr(command_buffer, dependency_info) }@@ -50,7 +34,7 @@ event: vk::Event, stage_mask: vk::PipelineStageFlags2KHR, ) {- self.synchronization2_fn+ self.fp .cmd_reset_event2_khr(command_buffer, event, stage_mask) }@@ -61,7 +45,7 @@ event: vk::Event, dependency_info: &vk::DependencyInfoKHR, ) {- self.synchronization2_fn+ self.fp .cmd_set_event2_khr(command_buffer, event, dependency_info) }@@ -73,7 +57,7 @@ dependency_infos: &[vk::DependencyInfoKHR], ) { assert_eq!(events.len(), dependency_infos.len());- self.synchronization2_fn.cmd_wait_events2_khr(+ self.fp.cmd_wait_events2_khr( command_buffer, events.len() as u32, events.as_ptr(),@@ -89,7 +73,7 @@ query_pool: vk::QueryPool, query: u32, ) {- self.synchronization2_fn+ self.fp .cmd_write_timestamp2_khr(command_buffer, stage, query_pool, query) }@@ -100,8 +84,16 @@ submits: &[vk::SubmitInfo2KHR], fence: vk::Fence, ) -> VkResult<()> {- self.synchronization2_fn+ self.fp .queue_submit2_khr(queue, submits.len() as u32, submits.as_ptr(), fence) .result() }++ pub fn name() -> &'static CStr {+ vk::KhrSynchronization2Fn::name()+ }++ pub fn fp(&self) -> &vk::KhrSynchronization2Fn {+ &self.fp+ } }
Let me analyze the code diff for security vulnerabilities: 1. Vulnerability Existed: no The changes appear to be primarily structural refactoring rather than security fixes. The main changes are: - Removal of the `handle` field and related `device()` method - Renaming `synchronization2_fn` to `fp` - Reorganization of method order - No changes to the actual Vulkan API calls or their safety wrappers 2. Vulnerability Existed: no The changes maintain all the same safety checks (like the assert_eq for array lengths in cmd_wait_events2_khr) and don't introduce any new unsafe operations beyond what was already present in the original code. 3. Vulnerability Existed: no The memory safety aspects remain unchanged: - Still using proper pointer handling for Vulkan calls - Still maintaining Rust's safety guarantees through the wrapper structure - No changes to the unsafe blocks or their scope The diff appears to be a code cleanup/optimization rather than a security fix, with no identifiable vulnerabilities being addressed. The functionality remains identical while the structure is simplified by removing the redundant device handle storage.
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/themes/shared/preferences/preferences.inc.css+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/browser/themes/shared/preferences/preferences.inc.css@@ -219,6 +219,16 @@ -moz-context-properties: fill, stroke, fill-opacity, stroke-opacity; fill: currentColor; stroke: var(--in-content-page-background);+}++@media (prefers-contrast) {+ #category-more-from-mozilla:hover > .category-icon {+ stroke: var(--in-content-button-background-hover);+ }++ #category-more-from-mozilla[selected] > .category-icon {+ stroke: var(--in-content-button-background-hover);+ } } /* All panes */@@ -1062,7 +1072,7 @@ margin-inline-start: 4px; }-#defaultBrowserLanguage {+#primaryBrowserLocale { margin-inline-start: 0; min-width: 20em; }@@ -1188,10 +1198,19 @@ margin-inline-start: 6px; }+#moreFromMozillaCategory-header .title {+ margin-block-end: 4px;+}+ #moreFromMozillaCategory-header .subtitle {- color: var(--in-content-deemphasized-text);- margin: 4px 0 10px;+ color: var(--in-content-text-color);+ margin-block-end: 24px; line-height: 1.4em;+}++#moreFromMozillaCategory:not([hidden]) {+ display: flex;+ flex-direction: column; } #moreFromMozillaCategory .mozilla-product-item {@@ -1199,7 +1218,7 @@ } #moreFromMozillaCategory .product-title {- margin: 4px 0;+ margin: 4px 0 3px; background-repeat: no-repeat; background-size: contain; padding-inline-start: 30px;@@ -1216,8 +1235,8 @@ /* The firefox-mobile product has three columns and needs to constrain the * .product-info section to one of them. */-#firefox-mobile-vbox.advanced .product-info {- min-width: 200px;+#firefox-mobile-div.advanced .product-info {+ max-width: 200px; } #moreFromMozillaCategory .product-img {@@ -1232,7 +1251,8 @@ } #moreFromMozillaCategory .description {- color: var(--in-content-deemphasized-text);+ display: inline flow-root;+ color: var(--in-content-text-color); padding-inline-start: 30px; margin: 2px 0; line-height: 1.4em;@@ -1243,7 +1263,7 @@ } #moreFromMozillaCategory .small-button {- margin-block: 16px;+ margin-block: 14px 2px; margin-inline: 30px 0; }@@ -1251,7 +1271,7 @@ margin: 24px 0; }-#moreFromMozillaCategory vbox.advanced {+#moreFromMozillaCategory .mozilla-product-item.advanced { box-shadow: 0 2px 6px rgba(58, 57, 68, 0.2); border-radius: 4px;@@ -1261,7 +1281,7 @@ } @media (prefers-color-scheme: dark) {- #moreFromMozillaCategory vbox.advanced {+ #moreFromMozillaCategory .mozilla-product-item.advanced { background-color: rgb(66, 65, 77); } }@@ -1271,18 +1291,19 @@ } #moreFromMozillaCategory .text-link {- font-size: .87em; line-height: 1.4em;-- text-decoration: underline; margin-block: 2px 0; margin-inline: 6px 0; } #moreFromMozillaCategory .simple .text-link {- display: block;+ display: inline flow-root; margin-inline-start: 4px;+}++#moreFromMozillaCategory .text-link.hidden {+ display: none; } #firefox-mobile {@@ -1300,6 +1321,10 @@ #firefox-mobile-image { background-image: url("chrome://browser/skin/preferences/img-mobile.svg");+}++.advanced #firefox-mobile-image {+ display: flex; } #mozilla-vpn-image {@@ -1317,14 +1342,20 @@ .qr-code-box:not([hidden="true"]) { max-width: 320px; /* a unit better than px for this & next? */ min-height: 204px;- margin-block: 10px;+ margin-block: 10px 0; margin-inline-start: 30px;- background-color: #f9f9fb;+ background-color: var(--in-content-box-info-background); display: flex; flex-direction: column; align-items: center;- justify-content: space-around;+ justify-content: space-evenly; border-radius: 4px;+}++@media (prefers-contrast) {+ .qr-code-box:not([hidden="true"]) {+ border: 1px solid currentColor;+ } } .advanced .qr-code-box {@@ -1346,6 +1377,8 @@ padding: 2px; width: 80px; flex: 0 0 auto;+ -moz-context-properties: fill;+ fill: currentColor; } .advanced .qr-code-box-image {@@ -1367,7 +1400,7 @@ .qr-code-box-title { font-size: .87em;- font-weight: 600;+ font-weight: normal; line-height: 1.42em; text-align: center;@@ -1377,11 +1410,13 @@ } .simple .qr-code-box-title {- width: 302px;+ margin-block: 0;+ width: 296px; } .simple .qr-code-box {- padding: 4px 20px 24px;+ padding-inline: 24px;+ padding-block: 20px } .simple .qr-code-box-image {@@ -1394,21 +1429,16 @@ margin-block: revert; }-#moreFromMozillaCategory .qr-code-button {+#moreFromMozillaCategory .qr-code-link { font-size: .87em;- font-weight: 400; line-height: 1.42em;- text-decoration: underline;- color: #5b5b66;-- flex: 2 0 auto;- margin-block-start: 10px;+ margin-block-start: 0; margin-inline: 0; /* make sure we're correctly centered by overriding button rule */ }-#moreFromMozillaCategory .advanced .qr-code-button {+#moreFromMozillaCategory .advanced .qr-code-link { margin-inline: 16px;- padding-block-start: 30px;+ margin-block-start: 30px; } @media (prefers-color-scheme: dark) {@@ -1416,20 +1446,11 @@ background-color: rgba(91,91,102,0.45); }- .qr-code-box-image {- -moz-context-properties: fill;- fill: white;- }- .advanced .qr-code-box-image { background-color: white; fill: black; }- #moreFromMozillaCategory .qr-code-button {- color: #fbfbfe;- }- .qr-code-box-title { color: #fbfbfe; }
After analyzing the provided CSS diff, I don't find any security-related vulnerabilities being fixed. The changes appear to be primarily styling improvements, accessibility enhancements (like prefers-contrast support), and structural adjustments to the UI elements. Here's the analysis following your requested format: Vulnerability Existed: no No security vulnerabilities found in the CSS changes. The modifications are cosmetic and structural in nature. The changes include: 1. Added prefers-contrast media query support for better accessibility 2. Renamed an ID selector from #defaultBrowserLanguage to #primaryBrowserLocale 3. Various styling adjustments for margins, colors, and layouts 4. Improved flexbox layouts and responsive design 5. Dark mode support enhancements 6. QR code display improvements These are all UI/UX improvements rather than security fixes. CSS changes typically don't involve security vulnerabilities unless they're related to clickjacking protections or similar issues, which aren't present here. Would you like me to analyze any other specific aspects of 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/third_party/rust/wgpu-hal/src/dx12/command.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/third_party/rust/wgpu-hal/src/dx12/command.rs@@ -319,15 +319,30 @@ // Only one barrier if it affects the whole image. self.temp.barriers.push(raw); } else {- // Generate barrier for each layer/level combination.+ // Selected texture aspect is relevant if the texture format has both depth _and_ stencil aspects.+ let planes = if crate::FormatAspects::from(barrier.texture.format)+ .contains(crate::FormatAspects::DEPTH | crate::FormatAspects::STENCIL)+ {+ match barrier.range.aspect {+ wgt::TextureAspect::All => 0..2,+ wgt::TextureAspect::StencilOnly => 1..2,+ wgt::TextureAspect::DepthOnly => 0..1,+ }+ } else {+ 0..1+ };+ for rel_mip_level in 0..mip_level_count { for rel_array_layer in 0..array_layer_count {- raw.u.Transition_mut().Subresource = barrier.texture.calc_subresource(- barrier.range.base_mip_level + rel_mip_level,- barrier.range.base_array_layer + rel_array_layer,- 0,- );- self.temp.barriers.push(raw);+ for plane in planes.clone() {+ raw.u.Transition_mut().Subresource =+ barrier.texture.calc_subresource(+ barrier.range.base_mip_level + rel_mip_level,+ barrier.range.base_array_layer + rel_array_layer,+ plane,+ );+ self.temp.barriers.push(raw);+ } } } }@@ -607,10 +622,15 @@ } if let Some(ref ds) = desc.depth_stencil_attachment { let mut flags = native::ClearFlags::empty();- if !ds.depth_ops.contains(crate::AttachmentOps::LOAD) {+ let aspects = ds.target.view.format_aspects;+ if !ds.depth_ops.contains(crate::AttachmentOps::LOAD)+ && aspects.contains(crate::FormatAspects::DEPTH)+ { flags |= native::ClearFlags::DEPTH; }- if !ds.stencil_ops.contains(crate::AttachmentOps::LOAD) {+ if !ds.stencil_ops.contains(crate::AttachmentOps::LOAD)+ && aspects.contains(crate::FormatAspects::STENCIL)+ { flags |= native::ClearFlags::STENCIL; }
Here's the analysis of the provided code diff for security fixes:
1. Vulnerability Existed: yes
Improper Texture Aspect Handling [third_party/rust/wgpu-hal/src/dx12/command.rs] [Lines 319-330]
Old Code:
```rust
// Generate barrier for each layer/level combination.
for rel_mip_level in 0..mip_level_count {
for rel_array_layer in 0..array_layer_count {
raw.u.Transition_mut().Subresource = barrier.texture.calc_subresource(
barrier.range.base_mip_level + rel_mip_level,
barrier.range.base_array_layer + rel_array_layer,
0,
);
self.temp.barriers.push(raw);
}
}
```
Fixed Code:
```rust
// Selected texture aspect is relevant if the texture format has both depth _and_ stencil aspects.
let planes = if crate::FormatAspects::from(barrier.texture.format)
.contains(crate::FormatAspects::DEPTH | crate::FormatAspects::STENCIL)
{
match barrier.range.aspect {
wgt::TextureAspect::All => 0..2,
wgt::TextureAspect::StencilOnly => 1..2,
wgt::TextureAspect::DepthOnly => 0..1,
}
} else {
0..1
};
for rel_mip_level in 0..mip_level_count {
for rel_array_layer in 0..array_layer_count {
for plane in planes.clone() {
raw.u.Transition_mut().Subresource =
barrier.texture.calc_subresource(
barrier.range.base_mip_level + rel_mip_level,
barrier.range.base_array_layer + rel_array_layer,
plane,
);
self.temp.barriers.push(raw);
}
}
}
```
2. Vulnerability Existed: yes
Improper Depth/Stencil Clear Handling [third_party/rust/wgpu-hal/src/dx12/command.rs] [Lines 607-622]
Old Code:
```rust
if let Some(ref ds) = desc.depth_stencil_attachment {
let mut flags = native::ClearFlags::empty();
if !ds.depth_ops.contains(crate::AttachmentOps::LOAD) {
flags |= native::ClearFlags::DEPTH;
}
if !ds.stencil_ops.contains(crate::AttachmentOps::LOAD) {
flags |= native::ClearFlags::STENCIL;
}
```
Fixed Code:
```rust
if let Some(ref ds) = desc.depth_stencil_attachment {
let mut flags = native::ClearFlags::empty();
let aspects = ds.target.view.format_aspects;
if !ds.depth_ops.contains(crate::AttachmentOps::LOAD)
&& aspects.contains(crate::FormatAspects::DEPTH)
{
flags |= native::ClearFlags::DEPTH;
}
if !ds.stencil_ops.contains(crate::AttachmentOps::LOAD)
&& aspects.contains(crate::FormatAspects::STENCIL)
{
flags |= native::ClearFlags::STENCIL;
}
```
The fixes address potential security issues related to improper handling of texture aspects and depth/stencil operations. The first fix properly handles texture aspects when generating barriers, particularly for textures with both depth and stencil components. The second fix ensures clear operations are only performed when the corresponding aspect (depth or stencil) is actually present in the format. These changes prevent potential memory corruption or undefined behavior that could be exploited.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.enable.blur.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.enable.blur.html@@ -17,15 +17,15 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.globalCompositeOperation = 'destination-atop'; ctx.shadowColor = '#0f0'; ctx.shadowBlur = 0.1; ctx.fillStyle = '#f00'; 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 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 [testing/web-platform/tests/html/canvas/offscreen/shadows/2d.shadow.enable.blur.html] [17-25]
-var offscreenCanvas = new OffscreenCanvas(100, 50);
-var ctx = offscreenCanvas.getContext('2d');
+var canvas = new OffscreenCanvas(100, 50);
+var ctx = canvas.getContext('2d');
Additional Details:
The changes simply rename the variable from `offscreenCanvas` to `canvas` and update the corresponding assertion call. There are no security implications in this change - it's purely a code style/readability improvement. The functionality remains exactly the same, just with a different variable name. No security vulnerabilities were addressed or introduced by 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/path-objects/2d.path.arcTo.shape.start.worker.js+++ /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.arcTo.shape.start.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);@@ -24,11 +24,11 @@ ctx.moveTo(0, 25); ctx.arcTo(200, 25, 200, 50, 10); ctx.stroke();-_assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");-_assertPixel(offscreenCanvas, 1,48, 0,255,0,255, "1,48", "0,255,0,255");-_assertPixel(offscreenCanvas, 50,25, 0,255,0,255, "50,25", "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, 1,48, 0,255,0,255, "1,48", "0,255,0,255");+_assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "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 diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming (from `offscreenCanvas` to `canvas`) and corresponding updates to the variable name in the assertions. There are no security-related changes in the code logic or functionality.
Here's the analysis following your requested format:
Vulnerability Existed: no
No security vulnerability found [File] [Lines 13-24]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 1,1, 0,255,0,255, "1,1", "0,255,0,255");
The changes are purely cosmetic/refactoring with no security implications. The functionality remains exactly the same, only the variable name has changed.
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/webdriver/src/server.rs+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/webdriver/src/server.rs@@ -11,30 +11,14 @@ use crate::Parameters; use bytes::Bytes; use http::{self, Method, StatusCode};-use once_cell::sync::Lazy;-use regex::Regex; use std::marker::PhantomData;-use std::net::{- IpAddr, Ipv4Addr, Ipv6Addr, SocketAddr, TcpListener as StdTcpListener, ToSocketAddrs,-};+use std::net::{SocketAddr, TcpListener as StdTcpListener}; use std::sync::mpsc::{channel, Receiver, Sender}; use std::sync::{Arc, Mutex}; use std::thread; use tokio::net::TcpListener; use url::{Host, Url}; use warp::{self, Buf, Filter, Rejection};--// Not a complete regex for parsing the Host header, but enough to parse out-// either a ip6 address surrounded by [], or an undelimted hostname or ipv4 address,-// any of which can be followed by an optonal : followed by a port.-// Validation of the host part is done in Host::parse-static HOST_REGEXP: Lazy<Regex> = Lazy::new(|| {- Regex::new(concat!(- r"^(?P<host>(:?\[[^\]]+\])|(:?[^ :]+))",- r"(:?:(?P<port>[[:digit:]]+))?$"- ))- .unwrap()-}); // Silence warning about Quit being unused for now. #[allow(dead_code)]@@ -218,8 +202,9 @@ } pub fn start<T, U>(- host: String, address: SocketAddr,+ allow_hosts: Vec<Host>,+ allow_origins: Vec<Url>, handler: T, extension_routes: Vec<(Method, &'static str, U)>, ) -> ::std::io::Result<Listener>@@ -241,7 +226,13 @@ let mut listener = rt .handle() .enter(|| TcpListener::from_std(listener).unwrap());- let wroutes = build_warp_routes(host, address, &extension_routes, msg_send.clone());+ let wroutes = build_warp_routes(+ address,+ allow_hosts,+ allow_origins,+ &extension_routes,+ msg_send.clone(),+ ); let fut = warp::serve(wroutes).run_incoming(listener.incoming()); rt.block_on(fut); })?;@@ -259,18 +250,19 @@ } fn build_warp_routes<U: 'static + WebDriverExtensionRoute + Send + Sync>(- host: String, address: SocketAddr,+ allow_hosts: Vec<Host>,+ allow_origins: Vec<Url>, ext_routes: &[(Method, &'static str, U)], chan: Sender<DispatchMessage<U>>, ) -> impl Filter<Extract = impl warp::Reply, Error = Rejection> + Clone { let chan = Arc::new(Mutex::new(chan)); let mut std_routes = standard_routes::<U>(); let (method, path, res) = std_routes.pop().unwrap();- let server_host = Host::parse(&host).expect("Failed to parse server hostname as a host"); let mut wroutes = build_route(- server_host.clone(), address,+ allow_hosts.clone(),+ allow_origins.clone(), method, path, res,@@ -279,8 +271,9 @@ for (method, path, res) in std_routes { wroutes = wroutes .or(build_route(- server_host.clone(), address,+ allow_hosts.clone(),+ allow_origins.clone(), method, path, res.clone(),@@ -292,8 +285,9 @@ for (method, path, res) in ext_routes { wroutes = wroutes .or(build_route(- server_host.clone(), address,+ allow_hosts.clone(),+ allow_origins.clone(), method.clone(), path, Route::Extension(res.clone()),@@ -305,108 +299,52 @@ wroutes }-fn parse_host(host_port: &str) -> WebDriverResult<(Host, Option<u16>)> {- // Get a (host, port) tuple from host:port- let make_err = || {- WebDriverError::new(- ErrorStatus::UnknownError,- format!("Invalid Host {}", host_port),- )+fn is_host_allowed(server_address: &SocketAddr, allow_hosts: &[Host], host_header: &str) -> bool {+ // Validate that the Host header value has a hostname in allow_hosts and+ // the port matches the server configuration+ let header_host_url = match Url::parse(&format!("http://{}", &host_header)) {+ Ok(x) => x,+ Err(_) => {+ return false;+ } };- let captures = HOST_REGEXP.captures(host_port).ok_or_else(make_err)?;- let host = captures- .name("host")- .map(|m| m.as_str())- .ok_or_else(make_err)- .and_then(|host| Host::parse(host).map_err(|_| make_err()))?;-- let maybe_port = if let Some(port) = captures.name("port").map(|m| m.as_str()) {- Some(port.parse().map_err(|_| make_err())?)- } else {- None+ let host = match header_host_url.host() {+ Some(host) => host.to_owned(),+ None => {+ // This shouldn't be possible since http URL always have a+ // host, but conservatively return false here, which will cause+ // an error response+ return false;+ } };- Ok((host, maybe_port))-}--fn host_is_local(host: &Host) -> bool {- // Check if host is a simple synonym of localhost- // i.e. "127.0.0.1", "::1", or "localhost" with a loopback ip- match host {- Host::Domain(ref domain) => {- // Check if the domain is a well-known local domain and it's actually bound to a local ip- domain == "localhost"- // port here is just a dummy; the DNS lookup doesn't depend on it- && (domain.to_string(), 80)- .to_socket_addrs()- .map(|addr_iter| {- addr_iter.map(|addr| addr.ip()).any(|ip| match ip {- IpAddr::V4(ip_v4) => ip_v4.is_loopback(),- IpAddr::V6(ip_v6) => ip_v6.is_loopback(),- })- })- .unwrap_or(false)+ let port = match header_host_url.port_or_known_default() {+ Some(port) => port,+ None => {+ // This shouldn't be possible since http URL always have a+ // default port, but conservatively return false here, which will cause+ // an error response+ return false; }- Host::Ipv4(ip) => ip == &Ipv4Addr::LOCALHOST,- Host::Ipv6(ip) => ip == &Ipv6Addr::LOCALHOST,- }-}--fn host_and_port_match_server(- server_host: &Host,- server_address: &SocketAddr,- header_host_port: (Host, Option<u16>),-) -> bool {- // Validate that the result of parsing the Host header matches the server configuration-- // If there's no port we're a HTTP server so default to 80- let host = header_host_port.0;- let port = header_host_port.1.unwrap_or(80);- let host_matches = if host_is_local(server_host) && host_is_local(&host) {- // If both the host header and the server are standard loopback names,- // accept the match. This means that the server can bind to 127.0.0.1 and- // the request can be for http://localhost for example- true- } else if host == *server_host {- match host {- Host::Domain(ref domain) => {- // For a domain we also check that the ip matches- (domain.to_string(), port)- .to_socket_addrs()- .map(|addr_iter| {- addr_iter- .map(|addr| addr.ip())- .any(|ip| ip == server_address.ip())- })- .unwrap_or(false)- }- Host::Ipv4(_) | Host::Ipv6(_) => true,- }- } else {- false+ };++ let host_matches = match host {+ Host::Domain(_) => allow_hosts.contains(&host),+ Host::Ipv4(_) | Host::Ipv6(_) => true, }; let port_matches = server_address.port() == port; host_matches && port_matches }-fn origin_is_local(url_str: &str) -> WebDriverResult<bool> {- // Validate that the URL string from an Origin header corresponds to a local interface- let make_err = || {- WebDriverError::new(- ErrorStatus::UnknownError,- format!("Invalid Origin {}", url_str),- )- };-- let url = Url::parse(url_str).map_err(|_| make_err())?;- let sockets = url.socket_addrs(|| None).map_err(|_| make_err())?;-- Ok(!sockets.is_empty() && sockets.iter().all(|x| x.ip().is_loopback()))+fn is_origin_allowed(allow_origins: &[Url], origin_url: Url) -> bool {+ // Validate that the Origin header value is in allow_origins+ allow_origins.contains(&origin_url) } fn build_route<U: 'static + WebDriverExtensionRoute + Send + Sync>(- server_host: Host, server_address: SocketAddr,+ allow_hosts: Vec<Host>,+ allow_origins: Vec<Url>, method: Method, path: &'static str, route: Route<U>,@@ -470,19 +408,19 @@ return warp::reply::with_status("".into(), StatusCode::OK); } if let Some(host) = host_header {- let host_port = match parse_host(&host) {- Ok(x) => x,- Err(err) => {- return warp::reply::with_status(- serde_json::to_string(&err).unwrap(),- StatusCode::INTERNAL_SERVER_ERROR,- )- }- };- if !host_and_port_match_server(&server_host, &server_address, host_port) {+ if !is_host_allowed(&server_address, &allow_hosts, &host) {+ warn!(+ "Rejected request with Host header {}, allowed values are [{}]",+ host,+ allow_hosts+ .iter()+ .map(|x| format!("{}:{}", x.to_string(), server_address.port()))+ .collect::<Vec<_>>()+ .join(",")+ ); let err = WebDriverError::new( ErrorStatus::UnknownError,- format!("Host header doesn't match server {}", host),+ format!("Invalid Host header {}", host), ); return warp::reply::with_status( serde_json::to_string(&err).unwrap(),@@ -490,6 +428,7 @@ ); }; } else {+ warn!("Rejected request with missing Host header"); let err = WebDriverError::new( ErrorStatus::UnknownError, "Missing Host header".to_string(),@@ -500,17 +439,33 @@ ); } if let Some(origin) = origin_header {- let origin_match_err = match origin_is_local(&origin) {- Ok(true) => None,- Ok(false) => Some(WebDriverError::new(+ let make_err = || {+ warn!(+ "Rejected request with Origin header {}, allowed values are [{}]",+ origin,+ allow_origins+ .iter()+ .map(|x| x.to_string())+ .collect::<Vec<_>>()+ .join(",")+ );+ WebDriverError::new( ErrorStatus::UnknownError,- format!("Request Origin {} isn't local", origin),- )),- Err(err) => Some(err),+ format!("Invalid Origin header {}", origin),+ ) };- if origin_match_err.is_some() {+ let origin_url = match Url::parse(&origin) {+ Ok(url) => url,+ Err(_) => {+ return warp::reply::with_status(+ serde_json::to_string(&make_err()).unwrap(),+ StatusCode::INTERNAL_SERVER_ERROR,+ );+ }+ };+ if !is_origin_allowed(&allow_origins, origin_url) { return warp::reply::with_status(- serde_json::to_string(&origin_match_err).unwrap(),+ serde_json::to_string(&make_err()).unwrap(), StatusCode::INTERNAL_SERVER_ERROR, ); }@@ -527,6 +482,10 @@ Some("application/x-www-form-urlencoded") | Some("multipart/form-data") | Some("text/plain") => {+ warn!(+ "Rejected POST request with disallowed content type {}",+ content_type.unwrap_or_else(|| "".into())+ ); let err = WebDriverError::new( ErrorStatus::UnknownError, "Invalid Content-Type",@@ -606,45 +565,11 @@ #[cfg(test)] mod tests { use super::*;- use std::net::{IpAddr, Ipv4Addr, Ipv6Addr};+ use std::net::IpAddr; use std::str::FromStr; #[test]- fn test_parse_host() {- assert_eq!(- parse_host("example.org"),- Ok((Host::parse("example.org").unwrap(), None))- );- assert_eq!(- parse_host("example.org:8000"),- Ok((Host::parse("example.org").unwrap(), Some(8000)))- );- assert_eq!(- parse_host("127.0.0.1:8000"),- Ok((Host::parse("127.0.0.1").unwrap(), Some(8000)))- );- assert_eq!(- parse_host("127.0.0.1"),- Ok((Host::parse("127.0.0.1").unwrap(), None))- );- assert_eq!(- parse_host("[::1]"),- Ok((Host::parse("[::1]").unwrap(), None))- );- assert_eq!(- parse_host("[::1]:443"),- Ok((Host::parse("[::1]").unwrap(), Some(443)))- );- assert!(parse_host("localhost:").is_err());- assert!(parse_host("localhost/foo").is_err());- assert!(parse_host("localhost:65536").is_err());- assert!(parse_host("::1:8000").is_err());- assert!(parse_host("localhost:80:433").is_err());- assert!(parse_host("localhost:80:abc").is_err());- }-- #[test]- fn test_host_and_port_match_server() {+ fn test_host_allowed() { let addr_80 = SocketAddr::new(IpAddr::from_str("127.0.0.1").unwrap(), 80); let addr_8000 = SocketAddr::new(IpAddr::from_str("127.0.0.1").unwrap(), 8000); let addr_v6_80 = SocketAddr::new(IpAddr::from_str("::1").unwrap(), 80);@@ -652,129 +577,111 @@ // We match the host ip address to the server, so we can only use hosts that actually resolve let localhost_host = Host::Domain("localhost".to_string());- let ipv4_host = Host::Ipv4(Ipv4Addr::from_str("127.0.0.1").unwrap());- let ipv6_host = Host::Ipv6(Ipv6Addr::from_str("::1").unwrap());+ let test_host = Host::Domain("example.test".to_string()); let subdomain_localhost_host = Host::Domain("subdomain.localhost".to_string());- assert!(host_and_port_match_server(- &localhost_host,+ assert!(is_host_allowed( &addr_80,- (localhost_host.clone(), Some(80))- ));- assert!(host_and_port_match_server(- &localhost_host,+ &[localhost_host.clone()],+ "localhost:80"+ ));+ assert!(is_host_allowed( &addr_80,- (localhost_host.clone(), None)- ));- assert!(host_and_port_match_server(- &ipv4_host,+ &[test_host.clone()],+ "example.test:80"+ ));+ assert!(is_host_allowed( &addr_80,- (ipv4_host.clone(), None)- ));- assert!(host_and_port_match_server(- &ipv4_host,+ &[test_host.clone(), localhost_host.clone()],+ "example.test"+ ));+ assert!(is_host_allowed(+ &addr_80,+ &[subdomain_localhost_host.clone()],+ "subdomain.localhost"+ ));++ // ip address cases+ assert!(is_host_allowed(&addr_80, &[], "127.0.0.1:80"));+ assert!(is_host_allowed(&addr_v6_80, &[], "127.0.0.1"));+ assert!(is_host_allowed(&addr_80, &[], "[::1]"));+ assert!(is_host_allowed(&addr_8000, &[], "127.0.0.1:8000"));+ assert!(is_host_allowed(+ &addr_80,+ &[subdomain_localhost_host.clone()],+ "[::1]"+ ));+ assert!(is_host_allowed(+ &addr_v6_8000,+ &[subdomain_localhost_host.clone()],+ "[::1]:8000"+ ));++ // Mismatch cases++ assert!(!is_host_allowed(&addr_80, &[test_host], "localhost"));++ assert!(!is_host_allowed(&addr_80, &[], "localhost:80"));++ // Port mismatch cases++ assert!(!is_host_allowed(+ &addr_80,+ &[localhost_host.clone()],+ "localhost:8000"+ ));+ assert!(!is_host_allowed( &addr_8000,- (ipv4_host.clone(), Some(8000))- ));- assert!(host_and_port_match_server(- &ipv6_host,- &addr_v6_80,- (ipv6_host.clone(), None)- ));- assert!(host_and_port_match_server(- &ipv6_host,+ &[localhost_host.clone()],+ "localhost"+ ));+ assert!(!is_host_allowed( &addr_v6_8000,- (ipv6_host.clone(), Some(8000))- ));-- // Cases where the server and host mismatch, but they're both known to be localhost- assert!(host_and_port_match_server(- &localhost_host,- &addr_8000,- (ipv4_host.clone(), Some(8000))- ));- assert!(host_and_port_match_server(- &localhost_host,- &addr_8000,- (ipv6_host.clone(), Some(8000))- ));- assert!(host_and_port_match_server(- &ipv4_host,- &addr_8000,- (localhost_host.clone(), Some(8000))- ));- assert!(host_and_port_match_server(- &ipv4_host,- &addr_8000,- (ipv6_host.clone(), Some(8000))- ));- assert!(host_and_port_match_server(- &ipv6_host,- &addr_8000,- (localhost_host.clone(), Some(8000))- ));- assert!(host_and_port_match_server(- &ipv6_host,- &addr_8000,- (ipv4_host.clone(), Some(8000))- ));-+ &[localhost_host.clone()],+ "[::1]"+ ));+ }++ #[test]+ fn test_origin_allowed() {+ assert!(is_origin_allowed(+ &[Url::parse("http://localhost").unwrap()],+ Url::parse("http://localhost").unwrap()+ ));+ assert!(is_origin_allowed(+ &[Url::parse("http://localhost").unwrap()],+ Url::parse("http://localhost:80").unwrap()+ ));+ assert!(is_origin_allowed(+ &[+ Url::parse("https://test.example").unwrap(),+ Url::parse("http://localhost").unwrap()+ ],+ Url::parse("http://localhost").unwrap()+ ));+ assert!(is_origin_allowed(+ &[+ Url::parse("https://test.example").unwrap(),+ Url::parse("http://localhost").unwrap()+ ],+ Url::parse("https://test.example:443").unwrap()+ )); // Mismatch cases-- assert!(!host_and_port_match_server(- &subdomain_localhost_host,- &addr_8000,- (localhost_host.clone(), Some(8000))- ));-- assert!(!host_and_port_match_server(- &subdomain_localhost_host,- &addr_8000,- (ipv4_host.clone(), Some(8000))- ));-- assert!(!host_and_port_match_server(- &subdomain_localhost_host,- &addr_8000,- (ipv6_host.clone(), Some(8000))- ));-- assert!(!host_and_port_match_server(- &Host::parse("127.0.0.2").unwrap(),- &addr_8000,- (localhost_host.clone(), Some(8000))- ));-- // Mismatch ports- assert!(!host_and_port_match_server(- &localhost_host,- &addr_80,- (localhost_host.clone(), Some(8000))- ));- assert!(!host_and_port_match_server(- &localhost_host,- &addr_8000,- (localhost_host.clone(), None)- ));- }-- #[test]- fn test_origin_is_local() {- // This depends on network configuration; we assume that localhost, 127.0.0.1 and [::1] are loopback- // and that example.org and 1.1.1.1 are not.- assert!(origin_is_local("https://127.0.0.1").unwrap());- assert!(origin_is_local("http://127.0.0.1:8000").unwrap());- assert!(origin_is_local("http://[::1]").unwrap());- assert!(origin_is_local("https://[::1]:9999").unwrap());- assert!(origin_is_local("http://localhost").unwrap());- assert!(origin_is_local("https://localhost").unwrap());- assert!(origin_is_local("http://localhost:4444").unwrap());- assert!(!origin_is_local("http://example.org").unwrap());- assert!(!origin_is_local("https://example.org:1000").unwrap());- assert!(!origin_is_local("http://1.1.1.1").unwrap());- assert!(origin_is_local("localhost").is_err());- assert!(origin_is_local("localhost:443").is_err());- assert!(origin_is_local("127.0.0.1:443").is_err());- assert!(origin_is_local("[::1]").is_err());- }-}+ assert!(!is_origin_allowed(+ &[],+ Url::parse("http://localhost").unwrap()+ ));+ assert!(!is_origin_allowed(+ &[Url::parse("http://localhost").unwrap()],+ Url::parse("http://localhost:8000").unwrap()+ ));+ assert!(!is_origin_allowed(+ &[Url::parse("https://localhost").unwrap()],+ Url::parse("http://localhost").unwrap()+ ));+ assert!(!is_origin_allowed(+ &[Url::parse("https://example.test").unwrap()],+ Url::parse("http://subdomain.example.test").unwrap()+ ));+ }+}
Here is the analysis of the provided code diff for security fixes: 1. Vulnerability Existed: yes **Host Header Injection/Validation Vulnerability** [testing/webdriver/src/server.rs] [Lines: 218-565] [Old Code] Used custom regex parsing and complex host validation logic that could potentially be bypassed [Fixed Code] Simplified host validation using explicit allow lists (`allow_hosts`) and URL parsing 2. Vulnerability Existed: yes **Origin Header Injection/Validation Vulnerability** [testing/webdriver/src/server.rs] [Lines: 218-565] [Old Code] Had custom origin validation that checked for local addresses only [Fixed Code] Uses explicit allow lists (`allow_origins`) for origin validation 3. Vulnerability Existed: yes **Insecure Default Host/Origin Validation** [testing/webdriver/src/server.rs] [Lines: 218-565] [Old Code] Had implicit assumptions about localhost/loopback addresses being safe [Fixed Code] Requires explicit allow lists to be provided for both hosts and origins 4. Vulnerability Existed: yes **Potential DNS Rebinding Vulnerability** [testing/webdriver/src/server.rs] [Lines: 218-565] [Old Code] Performed DNS lookups during host validation which could be exploited [Fixed Code] Removes DNS lookups and relies on explicit allow lists The main security improvements are: 1. Removal of complex regex-based host parsing 2. Replacement with explicit allow lists for both hosts and origins 3. Removal of DNS lookups during validation 4. More straightforward and secure validation logic 5. Better logging of rejected requests 6. Clear separation between host and origin validation The changes appear to address several potential security vulnerabilities related to host/header validation and DNS rebinding attacks by implementing a more secure whitelist-based approach.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/security/sandbox/linux/SandboxFilter.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/security/sandbox/linux/SandboxFilter.cpp@@ -35,6 +35,7 @@ #include "SandboxLogging.h" #include "SandboxOpenedFiles.h" #include "mozilla/PodOperations.h"+#include "mozilla/ProcInfo_linux.h" #include "mozilla/TemplateLib.h" #include "mozilla/UniquePtr.h" #include "prenv.h"@@ -746,6 +747,8 @@ // source). Those values could be detected by bit masking, // but it's simpler to just have a default-deny policy. Arg<clockid_t> clk_id(0);+ clockid_t this_process =+ MAKE_PROCESS_CPUCLOCK(getpid(), CPUCLOCK_SCHED); return If(clk_id == CLOCK_MONOTONIC, Allow()) #ifdef CLOCK_MONOTONIC_COARSE // Used by SandboxReporter, among other things.@@ -758,9 +761,11 @@ #endif .ElseIf(clk_id == CLOCK_THREAD_CPUTIME_ID, Allow()) #ifdef MOZ_GECKO_PROFILER+ // Allow clock_gettime on the same process.+ .ElseIf(clk_id == this_process, Allow()) // Allow clock_gettime on a thread.- // 4 -> CPUCLOCK_PERTHREAD_MASK. 2 -> CPUCLOCK_SCHED.- .ElseIf((clk_id & 7u) == (4u | 2u), Allow())+ .ElseIf((clk_id & 7u) == (CPUCLOCK_PERTHREAD_MASK | CPUCLOCK_SCHED),+ Allow()) #endif #ifdef CLOCK_BOOTTIME .ElseIf(clk_id == CLOCK_BOOTTIME, Allow())@@ -1997,4 +2002,46 @@ new SocketProcessSandboxPolicy(aMaybeBroker)); }+class UtilitySandboxPolicy final : public SandboxPolicyCommon {+ public:+ explicit UtilitySandboxPolicy(SandboxBrokerClient* aBroker)+ : SandboxPolicyCommon(aBroker, ShmemUsage::MAY_CREATE,+ AllowUnsafeSocketPair::NO) {}++ ResultExpr PrctlPolicy() const override {+ Arg<int> op(0);+ return Switch(op)+ .CASES((PR_SET_NAME, // Thread creation+ PR_SET_DUMPABLE, // Crash reporting+ PR_SET_PTRACER), // Debug-mode crash handling+ Allow())+ .Default(InvalidSyscall());+ }++ ResultExpr EvaluateSyscall(int sysno) const override {+ switch (sysno) {+ case __NR_getrusage:+ return Allow();+ case __NR_ioctl: {+ Arg<unsigned long> request(1);+ // ffmpeg, and anything else that calls isatty(), will be told+ // that nothing is a typewriter:+ return If(request == TCGETS, Error(ENOTTY)).Else(InvalidSyscall());+ }+ case __NR_prctl: {+ return Allow();+ }+ // Pass through the common policy.+ default:+ return SandboxPolicyCommon::EvaluateSyscall(sysno);+ }+ }+};++UniquePtr<sandbox::bpf_dsl::Policy> GetUtilitySandboxPolicy(+ SandboxBrokerClient* aMaybeBroker) {+ return UniquePtr<sandbox::bpf_dsl::Policy>(+ new UtilitySandboxPolicy(aMaybeBroker));+}+ } // namespace mozilla
I'll analyze the provided code diff for security fixes following the specified format.
1. Vulnerability Existed: yes
Clock ID Validation Vulnerability [security/sandbox/linux/SandboxFilter.cpp] [Lines 746-761]
Old Code:
```cpp
Arg<clockid_t> clk_id(0);
return If(clk_id == CLOCK_MONOTONIC, Allow())
[...]
.ElseIf(clk_id == CLOCK_THREAD_CPUTIME_ID, Allow())
#ifdef MOZ_GECKO_PROFILER
// Allow clock_gettime on a thread.
// 4 -> CPUCLOCK_PERTHREAD_MASK. 2 -> CPUCLOCK_SCHED.
.ElseIf((clk_id & 7u) == (4u | 2u), Allow())
#endif
```
Fixed Code:
```cpp
Arg<clockid_t> clk_id(0);
clockid_t this_process =
MAKE_PROCESS_CPUCLOCK(getpid(), CPUCLOCK_SCHED);
return If(clk_id == CLOCK_MONOTONIC, Allow())
[...]
.ElseIf(clk_id == CLOCK_THREAD_CPUTIME_ID, Allow())
#ifdef MOZ_GECKO_PROFILER
// Allow clock_gettime on the same process.
.ElseIf(clk_id == this_process, Allow())
// Allow clock_gettime on a thread.
.ElseIf((clk_id & 7u) == (CPUCLOCK_PERTHREAD_MASK | CPUCLOCK_SCHED),
Allow())
#endif
```
2. Vulnerability Existed: not sure
Missing Sandbox Policy for Utility Processes [security/sandbox/linux/SandboxFilter.cpp] [Lines 1997-2002]
Old Code:
```cpp
new SocketProcessSandboxPolicy(aMaybeBroker));
}
```
Fixed Code:
```cpp
new SocketProcessSandboxPolicy(aMaybeBroker));
}
class UtilitySandboxPolicy final : public SandboxPolicyCommon {
public:
explicit UtilitySandboxPolicy(SandboxBrokerClient* aBroker)
: SandboxPolicyCommon(aBroker, ShmemUsage::MAY_CREATE,
AllowUnsafeSocketPair::NO) {}
ResultExpr PrctlPolicy() const override {
Arg<int> op(0);
return Switch(op)
.CASES((PR_SET_NAME, // Thread creation
PR_SET_DUMPABLE, // Crash reporting
PR_SET_PTRACER), // Debug-mode crash handling
Allow())
.Default(InvalidSyscall());
}
ResultExpr EvaluateSyscall(int sysno) const override {
switch (sysno) {
case __NR_getrusage:
return Allow();
case __NR_ioctl: {
Arg<unsigned long> request(1);
// ffmpeg, and anything else that calls isatty(), will be told
// that nothing is a typewriter:
return If(request == TCGETS, Error(ENOTTY)).Else(InvalidSyscall());
}
case __NR_prctl: {
return Allow();
}
// Pass through the common policy.
default:
return SandboxPolicyCommon::EvaluateSyscall(sysno);
}
}
};
UniquePtr<sandbox::bpf_dsl::Policy> GetUtilitySandboxPolicy(
SandboxBrokerClient* aMaybeBroker) {
return UniquePtr<sandbox::bpf_dsl::Policy>(
new UtilitySandboxPolicy(aMaybeBroker));
}
```
The first vulnerability fix addresses a clock ID validation issue where the process clock wasn't properly checked, potentially allowing access to timing information from other processes. The second change adds a new sandbox policy for utility processes, but it's unclear if this was fixing an existing vulnerability or just adding new functionality.
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/mobile/android/app/mobile.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/mobile/android/app/mobile.js@@ -528,20 +528,6 @@ // Hide common parts of URLs like "www." or "http://" pref("browser.urlbar.trimURLs", true);-// initial web feed readers list-pref("browser.contentHandlers.types.0.title", "chrome://browser/locale/region.properties");-pref("browser.contentHandlers.types.0.uri", "chrome://browser/locale/region.properties");-pref("browser.contentHandlers.types.0.type", "application/vnd.mozilla.maybe.feed");-pref("browser.contentHandlers.types.1.title", "chrome://browser/locale/region.properties");-pref("browser.contentHandlers.types.1.uri", "chrome://browser/locale/region.properties");-pref("browser.contentHandlers.types.1.type", "application/vnd.mozilla.maybe.feed");-pref("browser.contentHandlers.types.2.title", "chrome://browser/locale/region.properties");-pref("browser.contentHandlers.types.2.uri", "chrome://browser/locale/region.properties");-pref("browser.contentHandlers.types.2.type", "application/vnd.mozilla.maybe.feed");-pref("browser.contentHandlers.types.3.title", "chrome://browser/locale/region.properties");-pref("browser.contentHandlers.types.3.uri", "chrome://browser/locale/region.properties");-pref("browser.contentHandlers.types.3.type", "application/vnd.mozilla.maybe.feed");- // Shortnumber matching needed for e.g. Brazil: // 01187654321 can be found with 87654321 pref("dom.phonenumber.substringmatching.BR", 8);
Here's the analysis of the provided code diff:
1. Vulnerability Existed: not sure
[Potential Hardcoded Content Handlers] [mobile/android/app/mobile.js] [Lines 528-538]
[Old Code]
// initial web feed readers list
pref("browser.contentHandlers.types.0.title", "chrome://browser/locale/region.properties");
pref("browser.contentHandlers.types.0.uri", "chrome://browser/locale/region.properties");
pref("browser.contentHandlers.types.0.type", "application/vnd.mozilla.maybe.feed");
pref("browser.contentHandlers.types.1.title", "chrome://browser/locale/region.properties");
pref("browser.contentHandlers.types.1.uri", "chrome://browser/locale/region.properties");
pref("browser.contentHandlers.types.1.type", "application/vnd.mozilla.maybe.feed");
pref("browser.contentHandlers.types.2.title", "chrome://browser/locale/region.properties");
pref("browser.contentHandlers.types.2.uri", "chrome://browser/locale/region.properties");
pref("browser.contentHandlers.types.2.type", "application/vnd.mozilla.maybe.feed");
pref("browser.contentHandlers.types.3.title", "chrome://browser/locale/region.properties");
pref("browser.contentHandlers.types.3.uri", "chrome://browser/locale/region.properties");
pref("browser.contentHandlers.types.3.type", "application/vnd.mozilla.maybe.feed");
[Fixed Code]
[Removed entirely]
Additional Details:
- The diff shows removal of hardcoded content handlers configuration. While not clearly a security vulnerability, hardcoded configurations can sometimes lead to security issues if they point to insecure resources or create unexpected behavior.
- The removal might indicate a move away from hardcoded values to more dynamic or secure configuration methods.
- Without more context about how these handlers were used, it's difficult to determine if this was an actual security fix or just a configuration 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/path-objects/2d.path.arc.twopie.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/path-objects/2d.path.arc.twopie.1.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 = '#0f0'; ctx.fillRect(0, 0, 100, 50);@@ -23,7 +23,7 @@ ctx.beginPath(); ctx.arc(50, 25, 50, 0, 2*Math.PI - 1e-4, true); ctx.stroke();-_assertPixel(offscreenCanvas, 50,20, 0,255,0,255, "50,20", "0,255,0,255");+_assertPixel(canvas, 50,20, 0,255,0,255, "50,20", "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 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] [testing/web-platform/tests/html/canvas/offscreen/path-objects/2d.path.arc.twopie.1.worker.js] [Lines 13-23]
[Old Code]
var offscreenCanvas = new OffscreenCanvas(100, 50);
var ctx = offscreenCanvas.getContext('2d');
...
_assertPixel(offscreenCanvas, 50,20, 0,255,0,255, "50,20", "0,255,0,255");
[Fixed Code]
var canvas = new OffscreenCanvas(100, 50);
var ctx = canvas.getContext('2d');
...
_assertPixel(canvas, 50,20, 0,255,0,255, "50,20", "0,255,0,255");
The changes are simply renaming the variable from `offscreenCanvas` to `canvas` throughout the file, which doesn't address any security issues. The functionality remains identical.
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/compositing/2d.composite.solid.source-atop.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.solid.source-atop.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 = 'rgba(0, 255, 255, 1.0)';@@ -26,7 +26,7 @@ ctx.globalCompositeOperation = 'source-atop'; ctx.fillStyle = 'rgba(255, 255, 0, 1.0)'; ctx.fillRect(0, 0, 100, 50);-_assertPixelApprox(offscreenCanvas, 50,25, 255,255,0,255, "50,25", "255,255,0,255", 5);+_assertPixelApprox(canvas, 50,25, 255,255,0,255, "50,25", "255,255,0,255", 5); 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 affect security. Here's the analysis:
1. Vulnerability Existed: no
Variable Renaming [testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.solid.source-atop.html] [Lines 17-18, 26]
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');
```
2. Vulnerability Existed: no
Variable Renaming [testing/web-platform/tests/html/canvas/offscreen/compositing/2d.composite.solid.source-atop.html] [Line 26]
Old Code:
```
_assertPixelApprox(offscreenCanvas, 50,25, 255,255,0,255, "50,25", "255,255,0,255", 5);
```
Fixed Code:
```
_assertPixelApprox(canvas, 50,25, 255,255,0,255, "50,25", "255,255,0,255", 5);
```
The changes are purely cosmetic/refactoring in nature, renaming the variable `offscreenCanvas` to `canvas` for consistency or clarity. There are no security implications 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/devtools/client/debugger/src/reducers/ui.js+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/devtools/client/debugger/src/reducers/ui.js@@ -80,8 +80,9 @@ case "HIGHLIGHT_LINES": const { start, end, sourceId } = action.location;- let lineRange = {};+ let lineRange;+ // Lines are one-based so the check below is fine. if (start && end && sourceId) { lineRange = { start, end, sourceId }; }@@ -90,7 +91,7 @@ case "CLOSE_QUICK_OPEN": case "CLEAR_HIGHLIGHT_LINES":- return { ...state, highlightedLineRange: {} };+ return { ...state, highlightedLineRange: undefined }; case "OPEN_CONDITIONAL_PANEL": return {@@ -130,63 +131,4 @@ } }-// NOTE: we'd like to have the app state fully typed-// https://github.com/firefox-devtools/debugger/blob/master/src/reducers/sources.js#L179-L185--export function getSelectedPrimaryPaneTab(state) {- return state.ui.selectedPrimaryPaneTab;-}--export function getActiveSearch(state) {- return state.ui.activeSearch;-}--export function getFrameworkGroupingState(state) {- return state.ui.frameworkGroupingOn;-}--export function getShownSource(state) {- return state.ui.shownSource;-}--export function getPaneCollapse(state, position) {- if (position == "start") {- return state.ui.startPanelCollapsed;- }-- return state.ui.endPanelCollapsed;-}--export function getHighlightedLineRange(state) {- return state.ui.highlightedLineRange;-}--export function getConditionalPanelLocation(state) {- return state.ui.conditionalPanelLocation;-}--export function getLogPointStatus(state) {- return state.ui.isLogPoint;-}--export function getOrientation(state) {- return state.ui.orientation;-}--export function getViewport(state) {- return state.ui.viewport;-}--export function getCursorPosition(state) {- return state.ui.cursorPosition;-}--export function getInlinePreview(state) {- return state.ui.inlinePreviewEnabled;-}--export function getEditorWrapping(state) {- return state.ui.editorWrappingEnabled;-}- export default update;
Let me analyze the code diff for potential security fixes:
1. Vulnerability Existed: not sure
[Potential State Initialization Issue] [devtools/client/debugger/src/reducers/ui.js] [Lines 80-90]
[Old Code]
let lineRange = {};
...
return { ...state, highlightedLineRange: {} };
[Fixed Code]
let lineRange;
...
return { ...state, highlightedLineRange: undefined };
Additional Details: The change from initializing with empty object to undefined might be related to preventing potential false positive checks in the application logic, though it's not clearly a security fix.
2. Vulnerability Existed: no
[Code Cleanup] [devtools/client/debugger/src/reducers/ui.js] [Lines 130-131]
[Old Code]
// NOTE: we'd like to have the app state fully typed
// https://github.com/firefox-devtools/debugger/blob/master/src/reducers/sources.js#L179-L185
[Fixed Code]
(removed)
Additional Details: This appears to be just a comment cleanup with no security implications.
3. Vulnerability Existed: no
[Function Removal] [devtools/client/debugger/src/reducers/ui.js] [Lines 131-4]
[Old Code]
(multiple exported selector functions)
[Fixed Code]
(all removed)
Additional Details: The removal of selector functions appears to be code reorganization rather than a security fix.
Note: While there are changes in the code, none clearly indicate specific security vulnerabilities being fixed. The most notable change is the handling of the `highlightedLineRange` state, but this appears to be more of a code quality improvement than a security fix.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/js/src/jsapi-tests/testGCGrayMarking.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/js/src/jsapi-tests/testGCGrayMarking.cpp@@ -281,8 +281,9 @@ // Start an incremental GC and run until gray roots have been pushed onto // the mark stack. JS::PrepareForFullGC(cx);+ js::SliceBudget budget(TimeBudget(1000000)); JS::StartIncrementalGC(cx, JS::GCOptions::Normal, JS::GCReason::DEBUG_GC,- 1000000);+ budget); MOZ_ASSERT(cx->runtime()->gc.state() == gc::State::Sweep); MOZ_ASSERT(cx->zone()->gcState() == Zone::MarkBlackAndGray);@@ -409,8 +410,9 @@ // Start an incremental GC and run until gray roots have been pushed onto // the mark stack. JS::PrepareForFullGC(cx);+ js::SliceBudget budget(TimeBudget(1000000)); JS::StartIncrementalGC(cx, JS::GCOptions::Normal, JS::GCReason::DEBUG_GC,- 1000000);+ budget); MOZ_ASSERT(cx->runtime()->gc.state() == gc::State::Sweep); MOZ_ASSERT(cx->zone()->gcState() == Zone::MarkBlackAndGray);
Analyzing the provided code diff, here's the security analysis:
1. Vulnerability Existed: not sure
Potential API Misuse Vulnerability [js/src/jsapi-tests/testGCGrayMarking.cpp] [Lines 281-283, 409-411]
Old Code:
JS::StartIncrementalGC(cx, JS::GCOptions::Normal, JS::GCReason::DEBUG_GC,
1000000);
Fixed Code:
js::SliceBudget budget(TimeBudget(1000000));
JS::StartIncrementalGC(cx, JS::GCOptions::Normal, JS::GCReason::DEBUG_GC,
budget);
Additional Details:
- The change involves replacing a direct numeric parameter with a proper `SliceBudget` object for garbage collection scheduling
- While this appears to be an API usage improvement, it's not clear if the previous usage represented an actual security vulnerability
- The change might be related to better resource management or preventing potential GC timing issues, but no specific vulnerability is identified
- The modification occurs in two similar locations in the file, both following the same pattern of change
No other vulnerabilities are apparent in this diff. The changes appear to be API usage improvements rather than direct security fixes.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/testing/web-platform/tests/html/canvas/offscreen/pixel-manipulation/2d.imageData.get.unaffected.html+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/testing/web-platform/tests/html/canvas/offscreen/pixel-manipulation/2d.imageData.get.unaffected.html@@ -17,8 +17,8 @@ }); t.step(function() {-var offscreenCanvas = new OffscreenCanvas(100, 50);-var ctx = offscreenCanvas.getContext('2d');+var canvas = new OffscreenCanvas(100, 50);+var ctx = canvas.getContext('2d'); ctx.fillStyle = '#0f0'; ctx.fillRect(0, 0, 50, 50)@@ -34,8 +34,8 @@ var imgdata = ctx.getImageData(0, 0, 50, 50); ctx.restore(); ctx.putImageData(imgdata, 50, 0);-_assertPixelApprox(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255", 2);-_assertPixelApprox(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255", 2);+_assertPixelApprox(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255", 2);+_assertPixelApprox(canvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255", 2); t.done(); });
After analyzing the provided code diff, I don't see any security vulnerabilities being fixed. The changes appear to be purely variable renaming and don't affect security. Here's the analysis:
1. Vulnerability Existed: no
No security vulnerability found
File: testing/web-platform/tests/html/canvas/offscreen/pixel-manipulation/2d.imageData.get.unaffected.html
Lines: 17-18, 34-35
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');
2. Vulnerability Existed: no
No security vulnerability found
File: testing/web-platform/tests/html/canvas/offscreen/pixel-manipulation/2d.imageData.get.unaffected.html
Lines: 34-35
Old Code:
_assertPixelApprox(offscreenCanvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255", 2);
_assertPixelApprox(offscreenCanvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255", 2);
Fixed Code:
_assertPixelApprox(canvas, 25,25, 0,255,0,255, "25,25", "0,255,0,255", 2);
_assertPixelApprox(canvas, 75,25, 0,255,0,255, "75,25", "0,255,0,255", 2);
The changes simply rename the variable `offscreenCanvas` to `canvas` throughout the file, which doesn't impact security. This appears to be a code style/consistency change rather than a security fix.
If an attacker could control the contents of an iframe sandboxed with <code>allow-popups</code> but not <code>allow-scripts</code>, they were able to craft a link that, when clicked, would lead to JavaScript execution in violation of the sandbox. This vulnerability affects Firefox < 98, Firefox ESR < 91.7, and Thunderbird < 91.7.
--- /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_97_END/firefox-FIREFOX_RELEASE_97_END/gfx/layers/BufferTexture.cpp+++ /root/PatchLeaks-main/products/firefox_downloads/FIREFOX_RELEASE_98_END/firefox-FIREFOX_RELEASE_98_END/gfx/layers/BufferTexture.cpp@@ -94,6 +94,9 @@ virtual uint8_t* GetBuffer() override { return mShmem.get<uint8_t>(); } virtual size_t GetBufferSize() override { return mShmem.Size<uint8_t>(); }++ bool CropYCbCrPlanes(const gfx::IntSize& aYSize,+ const gfx::IntSize& aCbCrSize) override; protected: mozilla::ipc::Shmem mShmem;@@ -506,5 +509,26 @@ aAllocator->DeallocShmem(mShmem); }+bool ShmemTextureData::CropYCbCrPlanes(const gfx::IntSize& aYSize,+ const gfx::IntSize& aCbCrSize) {+ if (mDescriptor.type() != BufferDescriptor::TYCbCrDescriptor) {+ return false;+ }++ const auto& current = mDescriptor.get_YCbCrDescriptor();+ if (current.ySize() < aYSize || current.cbCrSize() < aCbCrSize) {+ NS_WARNING("Cropped size should not exceed the original size!");+ return false;+ }++ auto newDescritor = YCbCrDescriptor(+ current.display(), aYSize, current.yStride(), aCbCrSize,+ current.cbCrStride(), current.yOffset(), current.cbOffset(),+ current.crOffset(), current.stereoMode(), current.colorDepth(),+ current.yUVColorSpace(), current.colorRange());+ mDescriptor = BufferDescriptor(newDescritor);+ return true;+}+ } // namespace layers } // namespace mozilla
Let me analyze the code diff for potential security fixes.
Vulnerability Existed: not sure
Potential Buffer Overflow/Input Validation [gfx/layers/BufferTexture.cpp] [Lines 509-526]
[Old Code]
(None - this is a new function)
[Fixed Code]
bool ShmemTextureData::CropYCbCrPlanes(const gfx::IntSize& aYSize,
const gfx::IntSize& aCbCrSize) {
if (mDescriptor.type() != BufferDescriptor::TYCbCrDescriptor) {
return false;
}
const auto& current = mDescriptor.get_YCbCrDescriptor();
if (current.ySize() < aYSize || current.cbCrSize() < aCbCrSize) {
NS_WARNING("Cropped size should not exceed the original size!");
return false;
}
auto newDescritor = YCbCrDescriptor(
current.display(), aYSize, current.yStride(), aCbCrSize,
current.cbCrStride(), current.yOffset(), current.cbOffset(),
current.crOffset(), current.stereoMode(), current.colorDepth(),
current.yUVColorSpace(), current.colorRange());
mDescriptor = BufferDescriptor(newDescritor);
return true;
}
Additional Details:
1. The new function adds input validation to prevent cases where the cropped size exceeds the original size, which could potentially lead to buffer overflows.
2. The function checks the descriptor type and validates the crop sizes before proceeding with the operation.
3. While not explicitly fixing a known vulnerability, this appears to be a defensive programming measure that could prevent memory safety issues.
No other obvious vulnerabilities are present in this diff. The changes appear to be adding new functionality with proper safety checks rather than fixing existing 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.