Closed Bug 1745595 (CVE-2022-34479) Opened 2 years ago Closed 2 years ago

Resize Popup Window Will Also Render Over the Address Bar leads to Address Bar Spoofing

Categories

(Core :: Widget: Gtk, defect)

x86_64
Linux
defect

Tracking

()

VERIFIED FIXED
103 Branch
Tracking Status
firefox-esr91 102+ verified
firefox101 --- wontfix
firefox102 + verified
firefox103 + verified

People

(Reporter: sourc7, Assigned: karlt)

References

Details

(Keywords: csectype-spoof, perf-alert, sec-high, Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main102+][adv-esr91.11+])

Attachments

(12 files)

61.12 KB, text/html
Details
180.20 KB, video/mp4
Details
61.25 KB, text/html
Details
117.04 KB, image/png
Details
22.81 KB, text/plain
Details
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
376 bytes, text/plain
Details
Attached file spoof.bundle.html

After resize popup window using window.sizeToContent() on page with large margin top, surprisingly the address bar UI will pushed up and replaced with HTML5 page content, therefore it possible to spoof the address bar.

I can only reproduce this on Linux (X11 and Wayland) and WebRender enabled. But I couldn't reproduce this on WebRender (Software) or gfx.webrender.software set to true.

Tested on:

  • Firefox Nightly 97.0a1 (2021-12-11) (64-bit) using Arch Linux KDE (X11 and Wayland) on Intel i5-1035G1 (1920x1080 DPI 125% and DPI 100%)
  • Firefox Nightly 97.0a1 (2021-12-11) (64-bit) using Arch Linux KDE (X11) on AMD Ryzen PRO 4650G (2560x1440 DPI 125%)
  • Firefox ESR 91.4.0esr (64-bit) using Arch Linux KDE (X11) on AMD Ryzen PRO 4650G (2560x1440 DPI 125%)

Steps to reproduce:

  1. Visit attached spoof.bundle.html
  2. Click "1920x1080" or "2560x1440"
  3. Address bar is now spoofed with HTML5 page content

(Try to increase the marginTop on the testcase if Firefox popup address bar UI still appear on your display.)

Flags: sec-bounty?
Type: task → defect
Component: Security → Address Bar

Moving to graphics given this is behaving differently on webrender software vs. general webrender.

Group: firefox-core-security → gfx-core-security
Component: Address Bar → Graphics
Product: Firefox → Core

The popup is in an odd security state: even though the url is https://bug1745595.bmoattachments.org/etc -- there's a "document" icon (neither a locked lock, or a "not secure") and when clicked it claims the document is "about:blank" and no TLS/cert info. That would be independent of the graphics issue.

The above was on Mac where I can't reproduce the problem in this bug -- I see the real URL bar. Guess we should spin off a separate bug for that.

Tyson tried on Ubuntu Linux (Gnome) and couldn't reproduce. Unique to KDE? Unique to Arch linux? We need to narrow that down. Calling "moderate" for now because the target audience seems limited, but we can revise if we learn more.

Component: Graphics → Graphics: WebRender

(In reply to [Back in January] Daniel Veditz [:dveditz] from comment #3)

Tyson tried on Ubuntu Linux (Gnome) and couldn't reproduce. Unique to KDE? Unique to Arch linux? We need to narrow that down. Calling "moderate" for now because the target audience seems limited, but we can revise if we learn more.

Thanks Dan for the update, it turns out it only affect window protocol x11 and xwayland.

On Arch Linux KDE (Wayland) the Firefox window protocol default to xwayland, after set environment MOZ_ENABLE_WAYLAND=1 and window protocol changed from xwayland to wayland I unable reproduce the issue.

I confirm I able to reproduce the issue on Ubuntu 21.10 after switch to "Ubuntu on Xorg" on user login or after logout.

(In reply to description)

Firefox Nightly 97.0a1 (2021-12-11) (64-bit) using Arch Linux KDE (X11 and Wayland) on Intel i5-1035G1 (1920x1080 DPI 125% and DPI 100%)

Sorry I was mistakenly think that xwayland same as wayland, turns out it's different.

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)
Blocks: gfx-triage
Flags: needinfo?(jmathies)

sec-mod, and xwayland is not a popular config. Maybe the redhat folks can take a look?

No longer blocks: gfx-triage
Component: Graphics: WebRender → Widget: Gtk
Flags: needinfo?(gpascutto)

Hmm, comment 4 claims it affects x11, which is the default.

Flags: needinfo?(gpascutto)

I can reproduce this on my (K)Ubuntu 21.10 in X11. I don't know if that's the default for that release (it is what I'm using!), but surely current Ubuntu LTS is using X11?

If that's the case there may be an argument this is a sec-high? Alexandre, do you have stats of the distro usage and X11 vs Wayland?

Flags: needinfo?(lissyx+mozillians)

As for Wayland vs XWayland, our own builds only default to Wayland as of bug 1749174.

Fedora and Ubuntu switched to Wayland a while ago, but I think that's after the Ubuntu LTS. Fedora has no LTS so they're probably good There's this thing called RHEL :-/

Martin, I know that this probably doesn't affect Fedora (but it likely affects RHEL!). Would you or someone from your team be willing to take this with the appropriate urgency? I think you're the most familiar with this code at this point.

Flags: needinfo?(stransky)
Severity: -- → S2
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

I'll try some RHEL.

Flags: needinfo?(stransky)

(In reply to Gian-Carlo Pascutto [:gcp] from comment #8)

I can reproduce this on my (K)Ubuntu 21.10 in X11. I don't know if that's the default for that release (it is what I'm using!), but surely current Ubuntu LTS is using X11?

If that's the case there may be an argument this is a sec-high? Alexandre, do you have stats of the distro usage and X11 vs Wayland?

as shared on matrix: https://sql.telemetry.mozilla.org/queries/84095/source#208316

Flags: needinfo?(lissyx+mozillians)

I'm unable to reproduce in RHEL 8.5/firefox 91.5.0esr. I got:
Compositing: Webrender (non software) - I had to set gfx.webrender.enabled to true to make it working
Intel driver
Window Protocol: xwayland

I recently checked this is still reproducible in Firefox Nightly 100.0a1 (2022-04-01) (64-bit) on Arch Linux (KDE x11). Is there any update on this?

Summary: Resize Popup Window Will Also Move the Address Bar leads to Address Bar Spoofing → Resize Popup Window Will Also Render Over the Address Bar leads to Address Bar Spoofing

(In reply to Irvan Kurniawan (:sourc7) from comment #15)

I recently checked this is still reproducible in Firefox Nightly 100.0a1 (2022-04-01) (64-bit) on Arch Linux (KDE x11). Is there any update on this?

--> :gcp . Looks like this is now sec-high and it's been a few months. You could reproduce - do we know where to start looking for a fix?

Flags: needinfo?(gpascutto)

No. (I know this is sad, but we don't have a lot of GTK skill in house right now, let alone availability)

Flags: needinfo?(gpascutto)

Martin, does it affect RHEL? Are you able to assist here?

Flags: needinfo?(stransky)

Hello Gian-Carlo,
we tested that on RHEL and it's not affected by this issue (see https://bugzilla.mozilla.org/show_bug.cgi?id=1745595#c14).
May that be something Ubuntu specific then?

Flags: needinfo?(stransky)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #19)

Hello Gian-Carlo,ww
we tested that on RHEL and it's not affected by this issue (see https://bugzilla.mozilla.org/show_bug.cgi?id=1745595#c14).
May that be something Ubuntu specific then?

I'm recently installed RHEL 8.5 on my machine, then set gfx.webrender.enabled to true on preinstalled Firefox 91.7.0esr.

After tweaking the testcase, finally I also able to reproduce this on RHEL 8.5, xwayland. I'll share the updated testcase soon.

Attached file spoof.bundle2.html

Alright here the updated testcase. I've tested this works on RHEL 8.5 on Laptop i5-1035G1 (1920x1080) and VirtualBox Guest (1920x1080 and 2560x1440) reproduced on Firefox 91.7.0esr and Firefox Nightly 100.0a1 (Compositing: WebRender and Window Protocol: xwayland).

Hi Martin can you try the updated testcase on your machine?

If it still doesn't work, try increase the marginTop and the resize function iteration. Thanks!

Flags: needinfo?(stransky)

Attached screenshot demonstration reproduced in Firefox 91.7.0esr (64-bit) WebRender enabled on RHEL 8.5 using spoof.bundle2.html.

With the spoof.bundle2.html I can reproduce the issue only when gfx.webrender.enabled=true. I've tried browser toolbox to locate the box with toolbar and it seems to be above the page content. I don't see any differences in position in the DOM in browser toolbox. I can do further debugging if desired, please let me know what more I can do for you.

Component: Widget: Gtk → Graphics: WebRender
Flags: needinfo?(stransky)

I can also reproduce with upstream binary of Firefox 99.

Flags: needinfo?(karlt)

I can reproduce on KDE with a single 3840x2160 monitor, echo Xft.dpi: 192.0 | xrdb -merge, and marginTop = 960 or 920 depending on whether the task bar is always visible or not.

This doesn't seem to be related to the invalidation bug often seen on presenting new windows as focus changes do not change the rendering.

This reproduces on 91.0a1 (2021-06-10), but tabs on earlier nightlies are crashing for me.

The effect is as if the window is sized too large for the display and then shrunk, but the content rendered by Firefox is not adjusted. Any subsequent resize of the window by window manager controls corrects the rendering and a scroll bar is presented.

The bug does not demonstrate the same symptoms with gfx.webrender.software:true, but the scroll bar is still not visible until a subsequent resize of the window. The difference may be that with non-software webrender the top of the window is clipped, but the bottom of the window is clipped with software webrender. Adding some text to the testcase and attempting to select the text indicates that hit testing is consistent with rendering when gfx.webrender.software:true but not when false.

Component: Graphics: WebRender → Widget: Gtk
Flags: needinfo?(karlt)

The problem can be seen at the end of the log.
Here, the size from the configure event is dispatched to layout correctly.

configure event 6,36 -> 3828 x 2118 scale 1'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
moz_container_size_allocate [7f2fea8c5400] 0,0 -> 3828 x 2118'
nsWindow::OnSizeAllocate 0,0 -> 3828 x 2118'
nsWindow::DispatchResized() size [3828, 2118]'
GetScreenBounds 0,0 -> 3828 x 2118, unscaled 0,0 -> 3828 x 2118'
GetScreenBounds 0,0 -> 3828 x 2118, unscaled 0,0 -> 3828 x 2118'
GetScreenBounds 0,0 -> 3828 x 2118, unscaled 0,0 -> 3828 x 2118'

The browser then requests that the window be made larger, and optimistically tells layout that the window will be larger:

nsWindow::SetSizeMode 0'
    already set'
nsWindow::Resize 3840.000000 2190.000000'
nsWindow::ResizeInt x:0 y:0 -> w:3840 h:2190 aMove 0'
  ConstrainSize: w:3840 h;2190'
nsWindow::NativeMoveResize move 0 resize 1 to 0,0 -> 3840 x 2190'
nsWindow::DispatchResized() size [3840, 2190]'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'

A configure event notifies the browser that the request for a larger window was denied, but this is not passed on to layout:

configure event 6,36 -> 3828 x 2118 scale 1'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'
GetScreenBounds 0,0 -> 3840 x 2190, unscaled 0,0 -> 3840 x 2190'

This problem of ending up with an incorrect optimistic size from a request that is never effected has shown up before.
The fix designed for that resolves the issue for attachment 9270710 [details], but does not address the whole problem: the same effect can still be produced by increasing the number and frequency of sizeToContent() calls. That's because GTK doesn't necessarily send a configure request from which to expect a configure notify event: "If the configure request has not changed, we don't ever resend it, because it could mean fighting the user or window manager."

Changing the behavior to only update widget sizes (mBounds) for managed windows after resizes are confirmed leads to many test failures in tests expecting synchronous application of sizes.

Keeping the behavior of optimistically and synchronously presuming resize sizes for resizes before the first size-allocate (but still changing behavior of later resizes) leads to a much smaller set of failures.

Assignee: nobody → karlt

This provides a consistent order of bounds changes corresponding to resize
event notifications. Previously the size reported in bounds could bounce as
requested sizes were saved, then overwritten in OnSizeAllocate() with
previously queued sizes, and then usually eventually rewritten with the final
size in OnSizeAllocate() again.

Depends on D147727

The requestAnimationFrame() callback used in IdlePromise() may run sooner than
1/60 second, providing insufficient time for changes to be effected.
https://searchfox.org/mozilla-central/rev/e567185fa464270f94430e7cf62d134f4df9a69f/layout/base/nsRefreshDriver.cpp#1730-1731

Waiting for the "resize" and "MozUpdateWindowPos" events should provide
minimum wait in the common cases that the OS completes the changes requested.

This change should also resolve
https://bugzilla.mozilla.org/show_bug.cgi?id=1702255

Depends on D147728

With the associated widget/gtk/nsWindow.cpp changes, this should also resolve
https://bugzilla.mozilla.org/show_bug.cgi?id=1766919 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1766991

Depends on D147729

This and the associated widget/gtk/nsWindow.cpp changes may also help with
https://bugzilla.mozilla.org/show_bug.cgi?id=1723436

Depends on D147730

Depends on: 1771278

Comment on attachment 9278899 [details]
Bug 1745595 record window size changes from app-initiated resizes asynchronously after the first size-allocate r?stransky

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: There are some hints here about the resize not being honored by the OS.
    What is not mentioned is that the chrome can be missing in some such situations.
  • Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Unknown
  • Which older supported branches are affected by this flaw?: All
  • If not all supported branches, which bug introduced the flaw?: None
  • Do you have backports for the affected branches?: No
  • If not, how different, hard to create, and risky will they be?: Backports will likely need hand crafting for at least some specific branches due to frequent/recent changes in the code.
    The same approaches should be generally applicable.
  • How likely is this patch to cause regressions; how much testing does it need?: This is high risk. The code has seen high turnover due to many different edge cases.

Testing would focus on X11 and Wayland Linux platforms.
Popup sizing and positioning would be tested with different chrome UI popup windows, opened from different positions and resized where possible (e.g. bookmarks popup).

Changes to other platforms involve only Geckodriver, not typical usage, and are well covered by automated tests.

  • Is Android affected?: No
Attachment #9278899 - Flags: sec-approval?
Attachment #9278898 - Flags: sec-approval?
Attachment #9278900 - Flags: sec-approval?
Attachment #9278901 - Flags: sec-approval?
Attachment #9278902 - Flags: sec-approval?

Comment on attachment 9278899 [details]
Bug 1745595 record window size changes from app-initiated resizes asynchronously after the first size-allocate r?stransky

Approved to land, and uplift if/when ready

Attachment #9278899 - Flags: sec-approval? → sec-approval+
Attachment #9278898 - Flags: sec-approval? → sec-approval+
Attachment #9278900 - Flags: sec-approval? → sec-approval+
Attachment #9278901 - Flags: sec-approval? → sec-approval+
Attachment #9278902 - Flags: sec-approval? → sec-approval+
Attachment #9278899 - Attachment description: Bug 1745595 - record window size changes from app-initiated resizes asynchronously after the first size-allocate r?stransky → Bug 1745595 record window size changes from app-initiated resizes asynchronously after the first size-allocate r?stransky
Attachment #9278900 - Attachment description: Bug 1745595 - wait for expected geometry after move or resize r?whimboo → Bug 1745595 wait for expected geometry after move or resize r?whimboo
Group: gfx-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 103 Branch

Comment on attachment 9278900 [details]
Bug 1745595 wait for expected geometry after move or resize r?whimboo

Beta/Release Uplift Approval Request

  • User impact if declined: sec-high
  • Is this code covered by automated tests?: Unknown
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Use attachment 9270710 [details] with X11 Linux and 1920x1080 or 2560x1440 monitor.

Partial coverage in automated tests.

  • List of other uplifts needed: None
  • Risk to taking this patch: High
  • Why is the change risky/not risky? (and alternatives if risky): The code has seen high turnover due to many different edge cases.
  • String changes made/needed: None
  • Is Android affected?: No

Beta/102 needs all patches but needs older diffs of two revisions from before rebases across recent trunk changes:
https://phabricator.services.mozilla.com/D147728?id=585997
https://phabricator.services.mozilla.com/D147729?id=587806

The easiest way to get the complete set of five changesets is

% hg pull -r 1456543b113c https://hg.mozilla.org/try
% hg rebase --rev 7ca436eeed37..1456543b113c -d <dest>
Attachment #9278900 - Flags: approval-mozilla-beta?
Attachment #9278898 - Flags: approval-mozilla-beta?
Attachment #9278899 - Flags: approval-mozilla-beta?
Attachment #9278901 - Flags: approval-mozilla-beta?
Attachment #9278902 - Flags: approval-mozilla-beta?
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][comment 36 for 102/beta uplift instructions]

Comment on attachment 9278900 [details]
Bug 1745595 wait for expected geometry after move or resize r?whimboo

Approved for 102 beta 8, thanks.

Attachment #9278900 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9278898 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9278899 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9278901 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9278902 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+

Karl, are you in contact with our QA team for the manual test or do you need me to loop in a Softvision Desktop QA person? Thanks

Flags: needinfo?(karlt)

We're also going to need rebased patches for ESR91 by this time next week.

(In reply to Pascal Chevrel:pascalc from comment #39)

Karl, are you in contact with our QA team for the manual test or do you need me to loop in a Softvision Desktop QA person? Thanks

I don't have a contact. If you are able to loop someone in, that would be great, thanks.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #40)

We're also going to need rebased patches for ESR91 by this time next week.

Thanks for the detail there. I'll get onto that.

Flags: needinfo?(karlt) → needinfo?(pascalc)
Flags: needinfo?(pascalc)

Cristian will handle the work here.

Flags: needinfo?(cristian.baica)
QA Whiteboard: [qa-triaged]

I've managed to reproduce the issue on Ubuntu 20.04 (1920x1080 and 2560x1440 resolutions) and Ubuntu 22.04 using the Fx 97.0a1 (2021-12-11 build).
The issue is verified fixed in the latest Fx103.0a1 build using Ubuntu 20.04 and Ubuntu 22.04 environments. For Ubuntu 20.04 the issue was verified on both 1080p and 1440p(2k resolution). This was tested with and without wayland and I'm happy to report the issue is fixed in both cases. For Ubuntu 22.04 I could only test the 1080p resolution and mentioned the issue is fixed there as well.

Waiting on Fx 102.0b8 to build and verify there as well.

Flags: needinfo?(cristian.baica)
Flags: sec-bounty? → sec-bounty+
See Also: → 1727653

The issue is verified fixed in Fx102.0b8 on Ubuntu and Ubuntu Wayland (20.04). The address bar is no longer spoofed.

Status: RESOLVED → VERIFIED

This uses the same approach as in D147730.
The test was removed on newer branches by D127252.

Comment on attachment 9278900 [details]
Bug 1745595 wait for expected geometry after move or resize r?whimboo

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: sec-high
  • User impact if declined: sec-high
  • Fix Landed on Version: 103
  • Risk to taking this patch: High
  • Why is the change risky/not risky? (and alternatives if risky): The code has seen high turnover due to many different edge cases.

The easiest way to get the complete set of five changesets is

% hg pull -r e3f4c1155287 https://hg.mozilla.org/try
% hg rebase --rev c3b21017a41e..e3f4c1155287 -d <dest>

D147730 attachment 9278901 [details] is not required (and not included in c3b21017a41e..e3f4c1155287), due to the test not existing on ESR91.

Attachment #9278900 - Flags: approval-mozilla-esr91?
Attachment #9278898 - Flags: approval-mozilla-esr91?
Attachment #9278899 - Flags: approval-mozilla-esr91?
Attachment #9278902 - Flags: approval-mozilla-esr91?
Attachment #9281716 - Flags: approval-mozilla-esr91?
Blocks: 1766991
Blocks: 1766919
Blocks: 1723436
Blocks: 1702255

Comment on attachment 9278898 [details]
Bug 1745595 - type ResizeInt() parameters to specify units r?stransky

Approved for 91.11esr. Thanks for rebasing.

Attachment #9278898 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+
Attachment #9278899 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+
Attachment #9278900 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+
Attachment #9278902 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+
Attachment #9281716 - Flags: approval-mozilla-esr91? → approval-mozilla-esr91+

The issue is verified fixed using the latest Fx 102.0 ESR and Fx91.11.0 ESR on Ubuntu 20.04. Both builds were tested on 1080p and 1440p, on both wayland and 'regular' Ubuntu, with webrender enabled. The address bar was no longer spoofed.

Flags: qe-verify+
Whiteboard: [reporter-external] [client-bounty-form] [verif?][comment 36 for 102/beta uplift instructions] → [reporter-external] [client-bounty-form] [verif?][comment 36 for 102/beta uplift instructions][adv-main102+]
Whiteboard: [reporter-external] [client-bounty-form] [verif?][comment 36 for 102/beta uplift instructions][adv-main102+] → [reporter-external] [client-bounty-form] [verif?][adv-main102+]

(In reply to Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout) from comment #35)

wait for expected geometry after move or resize r=whimboo,webdriver-reviewers
https://hg.mozilla.org/integration/autoland/rev/c2cd1e58dd94f78e6ed04798669635259a546964
https://hg.mozilla.org/mozilla-central/rev/c2cd1e58dd94

== Change summary for alert #34402 (as of Fri, 10 Jun 2022 13:12:12 GMT) ==

Improvements:

Ratio Test Platform Options Absolute values (old vs new)
8% reddit-billgates-post-2.hot fcp linux1804-64-shippable-qr cold fission webrender 307.05 -> 283.75
8% reddit-billgates-post-2.top fcp linux1804-64-shippable-qr cold fission webrender 307.05 -> 283.75
8% reddit-billgates-post-2.billg fcp linux1804-64-shippable-qr cold fission webrender 307.05 -> 283.75

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=34402

== Change summary for alert #34554 (as of Fri, 17 Jun 2022 15:12:47 GMT) ==

Improvements:

Ratio Test Platform Options Absolute values (old vs new)
4% twitter fcp linux1804-64-shippable-qr cold fission webrender 228.89 -> 220.24

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=34554

Keywords: perf-alert
Attached file advisory.txt
Alias: CVE-2022-34479
Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main102+] → [reporter-external] [client-bounty-form] [verif?][adv-main102+][adv-esr91.11+]
Duplicate of this bug: 1617506
Group: core-security-release
Duplicate of this bug: 304123
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: