1980788 - (CVE-2025-10533) Unsafe pointer arithmetic due to integer overflow in FilterProcessing::ApplyMorphologyHorizontal_Scalar reported by local ASan run

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Andrew Creskey [:acreskey]]

I was running this ASan build locally, loading 1000 websites and ASan halted on the following undefined behaviour

/builds/worker/checkouts/gecko/gfx/2d/FilterProcessingScalar.cpp:51:16: runtime error: addition of unsigned offset to 0x629004321f10 overflowed to 0x629004321200
    #0 0x000136db626c in mozilla::gfx::FilterProcessing::ApplyMorphologyHorizontal_Scalar(unsigned char*, int, unsigned char*, int, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, int, mozilla::gfx::MorphologyOperator)+0xbb8 (XUL:arm64+0x349e26c)
    #1 0x000136d583bc in mozilla::gfx::FilterNodeMorphologySoftware::Render(mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&)+0x43c (XUL:arm64+0x34403bc)
    #2 0x000136d50484 in mozilla::gfx::FilterNodeSoftware::GetOutput(mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&)+0x2e4 (XUL:arm64+0x3438484)
    #3 0x000136d527f8 in mozilla::gfx::FilterNodeSoftware::GetInputDataSourceSurface(unsigned int, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::FilterNodeSoftware::FormatHint, mozilla::gfx::ConvolveMatrixEdgeMode, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*)+0x6cc (XUL:arm64+0x343a7f8)
    #4 0x000136d6fd1c in mozilla::gfx::FilterNodeCropSoftware::Render(mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&)+0x1b4 (XUL:arm64+0x3457d1c)
    #5 0x000136d50484 in mozilla::gfx::FilterNodeSoftware::GetOutput(mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&)+0x2e4 (XUL:arm64+0x3438484)
    #6 0x000136d527f8 in mozilla::gfx::FilterNodeSoftware::GetInputDataSourceSurface(unsigned int, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::FilterNodeSoftware::FormatHint, mozilla::gfx::ConvolveMatrixEdgeMode, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*)+0x6cc (XUL:arm64+0x343a7f8)
    #7 0x000136d56e20 in mozilla::gfx::FilterNodeTransformSoftware::Render(mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&)+0x150 (XUL:arm64+0x343ee20)
    #8 0x000136d50484 in mozilla::gfx::FilterNodeSoftware::GetOutput(mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&)+0x2e4 (XUL:arm64+0x3438484)
...

Full ASan file attached.

The 1000 sites were being navigated with this web addon that was put together while investigating Bug 1980171.

The list of sites is here
I haven't figured out which site triggers the overflow, but I'll attach partial MOZ_LOGs for clues and if I can refine this I'll add it.

Comment 1

[Andrew Creskey [:acreskey]]

Attachment: asan_log.13257

ASan file reporting
/builds/worker/checkouts/gecko/gfx/2d/FilterProcessingScalar.cpp:51:16: runtime error: addition of unsigned offset to 0x629004321f10 overflowed to 0x629004321200

Comment 2

[Andrew Creskey [:acreskey]]

Attachment: partial_moz_log.txt

The last 10MB of moz_logs, timestamp,nsHttp:3,Navigation:4 recorded for this session.

Comment 3

[Robert Longson [:longsonr]]

maybe consider making https://searchfox.org/mozilla-central/source/gfx/2d/FilterNodeSoftware.cpp#1272 a MOZ_RELEASE_ASSERT (and taking it out of the ifdef DEBUG). That would not really fix this bug but it might make it crash safely instead.

Comment 4

[Andrew Creskey [:acreskey]]

This is the site where I'm seeing the issue
https://www.bootstrapcdn.com/

Comment 5

[Daniel Holbert [:dholbert]]

Hmm, do you reliably (or even just occasionally) hit the issue when just loading https://www.bootstrapcdn.com/ in an ASAN build? Or is there more to it than that?

I just visited in a local debug+ASAN build, and in a mozregression-launched ASAN build (mozregression --launch 2025-08-05 -B asan) -- loaded https://www.bootstrapcdn.com/ and scrolled to the end -- and didn't yet get any crashes or ASAN error-logging.

Comment 6

[Andrew Creskey [:acreskey]]

Yes, I'm seeing the issue just loading the site in my optimized ASan build, every load.
This is the binary, MacOs, AArch64
https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=BbNWs2qUTeKbBUfG2sBjpw.0&tier=1%2C2%2C3&revision=bdbbbe0e7dd12d5ac15e38fec3a7bcc2f4ca5a3d

It looks like it's built with -O2 for optimizations.

MOZ_AUTOMATION=1 --target=aarch64-apple-darwin MOZBUILD_STATE_PATH=/builds/worker/.mozbuild MOZ_FETCHES_DIR=/builds/worker/fetches HOST_CFLAGS=-g HOST_CXXFLAGS=-g HOST_LDFLAGS=-g 'CFLAGS= -fcrash-diagnostics-dir=/builds/worker/artifacts -fcrash-diagnostics-dir=/builds/worker/artifacts' 'CXXFLAGS= -fcrash-diagnostics-dir=/builds/worker/artifacts -fcrash-diagnostics-dir=/builds/worker/artifacts' --enable-optimize=-O2 CCACHE=sccache SCCACHE_VERBOSE_STATS=1 --enable-debug-symbols=-gline-tables-only --enable-address-sanitizer --enable-undefined-sanitizer ENABLE_CLANG_PLUGIN=1 --enable-fuzzing LLVM_SYMBOLIZER=/builds/worker/fetches/llvm-symbolizer/bin/llvm-symbolizer MOZ_SOURCE_REPO=https://hg.mozilla.org/try MOZ_SOURCE_CHANGESET=998370f63b9e193c95a964a9a9631fbde186086b --enable-js-shell --disable-profiling --enable-gczeal --enable-rust-simd MAR_CHANNEL_ID=firefox-mozilla-central ACCEPTED_MAR_CHANNEL_IDS=firefox-mozilla-central --disable-crashreporter MOZ_SIMPLE_PACKAGE_NAME=target MOZ_PKG_SPECIAL=asan DMG_TOOL=/builds/worker/fetches/dmg/dmg MOZ_PACKAGE_JSSHELL=1 MKFSHFS=/builds/worker/fetches/hfsplus/newfs_hfs HFS_TOOL=/builds/worker/fetches/dmg/hfsplus --disable-install-strip

Tyson said that he's also not seeing the issue on the Linux Site-Scout sweeps, bug 1847294

Comment 7

[Andrew Creskey [:acreskey]]

Also detected this error on https://developer.hashicorp.com/packer via a local Site-Scout sweep, MacOs.

Comment 8

[Andrew Creskey [:acreskey]]

Attachment: _issue_20250812-171456-result-507471.zip

Site-scout report

Comment 9

[BugBot [:suhaib / :marco]]

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

For more information, please visit BugBot documentation.

Comment 10

[Robert Longson [:longsonr]]

When debugging https://searchfox.org/firefox-main/source/gfx/2d/FilterProcessingScalar.cpp#51

sourceIndex = -3344

so we're indexing before the start of the array - that would be OK if sourceIndex was a part of some larger array.
y=-4, x=0, startX=-4, endX=4, aSourceStride = 832, aDestRect=(0, -4, 198, 28)

https://searchfox.org/firefox-main/source/gfx/2d/FilterNodeSoftware.cpp#1297

srcRect=(-4, -4, 206, 28)
destRect=(0, 0, 198, 20)
tmpRect=(0, -4, 198, 28)

https://searchfox.org/firefox-main/source/gfx/2d/DataSurfaceHelpers.cpp#91

aPoint=(4,4)

so it looks like we are in a larger array here.

Unfortunately there is more than one feMorphology filter on the page and I'm not certain I'm debugging the right one.

Comment 11

[Andrew Creskey [:acreskey]]

Attachment: FilterProcessingScalar.cpp_.zip

I've bumped into this error on 8 other sites (attached the site-scout / Asan logs)

Comment 12

[Andrew Creskey [:acreskey]]

List of the other sites, perhaps easier to isolate there:

https://www.jsdelivr.com/
http://bootstrapcdn.com/
https://owncloud.com/
https://developer.hashicorp.com/consul
https://developer.hashicorp.com/terraform
https://developer.hashicorp.com/packer
https://newrelic.com/
https://buildkite.com/

Comment 13

[Robert Longson [:longsonr]]

Attachment: not for check in - add asserts

The patch is not for check in. It checks (or tries to check) whether we are reading from outside the input surface - something valgrind seems to be suggesting since it can't be about writing to the local u array as we know that is an array of size 4 and we're writing 4 items to it.

I can't get the asserts to fire though on any of the sites in comment 6.

Not sure whether adding the patch locally to a valgrind build will reveal anything. I'm rather stumped at this point though.

Valgrind should be smart enough to understand that

uint8_t a[2];
foo(a{1])

void foo(uint8_t* a) {
a[-1] = 0;
}

is OK shouldn't it?

Comment 14

[Robert Longson [:longsonr]]

Daniel, since you have a local debug+ASAN build maybe you can try the patch and see if any of the asserts fire.

If someone wants to try an optimised ASAN build you'll have to convert the MOZ_ASSERT lines to MOZ_RELEASE_ASSERT

Comment 15

[Robert Longson [:longsonr]]

Ahh I think I've got it...

int i = -1;
size_t j = 0;

i + j is not -1 it's a big number.

Comment 16

[Robert Longson [:longsonr]]

Attachment: (secure)

Comment 17

[Robert Longson [:longsonr]]

This really needs fixing on all supported branches including ESR.

Comment 18

[Robert Longson [:longsonr]]

Comment on attachment 9510114 [details]
(secure)

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Seems one of the more straightforward bugs to figure out an exploit for. I can't really hide what's wrong here and what we're doing to fix it. Note that this bug does not affect platforms with SSE2 capable CPUs.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: all
• If not all supported branches, which bug introduced the flaw?: Bug 924102
• Do you have backports for the affected branches?: Yes
• If not, how different, hard to create, and risky will they be?: We might have to land bug 1984915 first in order to get this to land cleanly. Note that bug 1984915 is simple and harmless.
• How likely is this patch to cause regressions; how much testing does it need?: I think we understand the problem and all we're doing is casting to the right type here so we're OK.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 19

[Daniel Holbert [:dholbert]]

We might want to bump the sec rating to sec-high. This is a case where we want to do the following (where foo is a pointer partway through a larger buffer, with -1 being a perfectly reasonable spot to index):
foo[-1] = someVal

...but instead (because of comment 15), we inadvertently do the following:
foo[(size_t)(-1)] = someVal
...and since size_t is unsigned and can't represent -1, that means we're really doing something like:
foo[18446744073709551615] = someVal

Theoretically the compiler/CPU might manage to wrap that giant value beyond the end of memory back around to the proper -1 index, which would be great; but I'm not sure we can rely on that. Searching around, I'm not finding any concrete answers on whether this is defined vs. undefined behavior.

Comment 20

[Daniel Holbert [:dholbert]]

(In reply to Robert Longson [:longsonr] from comment #18)

• Do you have backports for the affected branches?: Yes
• If not, how different, hard to create, and risky will they be?: We might have to land bug 1984915 first in order to get this to land cleanly. Note that bug 1984915 is simple and harmless.

Good news: I just confirmed that the patch applies cleanly to esr-115 (which is as far back as we would uplift this). So no other backports/supporting-patches needed here.

Comment 21

[Daniel Veditz [:dveditz]]

Comment on attachment 9510114 [details]
(secure)

sec-approval=dveditz

Comment 22

[Robert Longson [:longsonr]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D262967

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/9f1f385a4c6c
https://hg.mozilla.org/integration/autoland/rev/0a32cc2a0e70
Use std::size rather than hardcoding an array size r=dholbert

Comment 24

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: possibly reading and writing to random memory locations
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: run an asan build on the sites listed in the bug and check that there are no errors reported
• Risk associated with taking this patch: low
• Explanation of risk level: just ensuring that we're dealing with the right values when we have negative numbers
• String changes made/needed: none
• Is Android affected?: yes

Comment 25

[Robert Longson [:longsonr]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D262967

Comment 26

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Differential D263127 Bug 1980788 - Use std::size rather than hardcoding an array size r=dholbert Needs ReviewCustom Policy Authored by longsonr on Fri, Aug 29, 3:58 PM. Edit Revision Update Diff Download Raw Diff Edit Related Revisions... Edit Related Objects... View Stack in Lando New Changes Mute Notifications Award Token Flag For Later Tags secure-revision bmo-layout-core-security Referenced Files None Subscribers longsonr acreskey dholbert dmeehan jfkthame mccr8 RyanVM This is a secure revision. Please use the CC list of the associated bug in Bugzilla to manage access and subscribership of this revision. Changes made here may be overwritten. Please do not land this revision using arc land to prevent data leakage. Details Reviewers None Group Reviewers release-managers Bugzilla Bug ID 1980788 Uplift Request form User impact if declined possibly reading and writing to random memory locations Code covered by automated testing no Fix verified in Nightly no Needs manual QE test yes Steps to reproduce for manual QE testing run an asan build on the sites listed in the bug and check that there are no errors reported Risk associated with taking this patch low Explanation of risk level just ensuring that we're dealing with the right values when we have negative numbers String changes made/needed none Is Android affected? yes Summary Original Revision: https://phabricator.services.mozilla.com/D262967 Diff Detail Repository rFIREFOXBETA firefox-beta Branch beta Build Status Buildable 841458 Build 942183: Source Code Analysis Event Timeline longsonr created this revision.Fri, Aug 29, 3:58 PM Herald added a project: secure-revision. · View Herald TranscriptFri, Aug 29, 3:58 PM phab-bot published this revision for review.Fri, Aug 29, 3:59 PM phab-bot changed the visibility from "Custom Policy" to "Custom Policy". phab-bot changed the edit policy from "Custom Policy" to "Custom Policy". phab-bot added a project: bmo-layout-core-security. phab-bot added subscribers: dmeehan, acreskey, jfkthame and 4 others. longsonr updated the uplift request field.Fri, Aug 29, 4:02 PM phab-bot added a reviewer: release-managers.Fri, Aug 29, 4:02 PM Revision Contents Files History Commits Path Size gfx/ 2d/ FilterProcessingScalar.cpp Diff 1114349 gfx/2d/FilterProcessingScalar.cpp Show First 20 Lines • Show All 41 Lines • ▼ Show 20 Lines static void ApplyMorphologyHorizontal_Scalar( for (int32_t y = aDestRect.Y(); y < aDestRect.YMost(); y++) { for (int32_t y = aDestRect.Y(); y < aDestRect.YMost(); y++) { int32_t startX = aDestRect.X() - aRadius; int32_t startX = aDestRect.X() - aRadius; int32_t endX = aDestRect.X() + aRadius; int32_t endX = aDestRect.X() + aRadius; for (int32_t x = aDestRect.X(); x < aDestRect.XMost(); for (int32_t x = aDestRect.X(); x < aDestRect.XMost(); x++, startX++, endX++) { x++, startX++, endX++) { int32_t sourceIndex = y * aSourceStride + 4 * startX; int32_t sourceIndex = y * aSourceStride + 4 * startX; uint8_t u[4]; uint8_t u[4]; for (size_t i = 0; i < 4; i++) { for (int32_t i = 0; i < int32_t(std::size(u)); i++) { u[i] = aSourceData[sourceIndex + i]; u[i] = aSourceData[sourceIndex + i]; } } sourceIndex += 4; sourceIndex += 4; for (int32_t ix = startX + 1; ix <= endX; ix++, sourceIndex += 4) { for (int32_t ix = startX + 1; ix <= endX; ix++, sourceIndex += 4) { for (size_t i = 0; i < 4; i++) { for (int32_t i = 0; i < int32_t(std::size(u)); i++) { if (Operator == MORPHOLOGY_OPERATOR_ERODE) { if (Operator == MORPHOLOGY_OPERATOR_ERODE) { u[i] = umin(u[i], aSourceData[sourceIndex + i]); u[i] = umin(u[i], aSourceData[sourceIndex + i]); } else { } else { u[i] = umax(u[i], aSourceData[sourceIndex + i]); u[i] = umax(u[i], aSourceData[sourceIndex + i]); } } } } } } int32_t destIndex = y * aDestStride + 4 * x; int32_t destIndex = y * aDestStride + 4 * x; for (size_t i = 0; i < 4; i++) { for (int32_t i = 0; i < int32_t(std::size(u)); i++) { aDestData[destIndex + i] = u[i]; aDestData[destIndex + i] = u[i]; } } } } } } } } void FilterProcessing::ApplyMorphologyHorizontal_Scalar( void FilterProcessing::ApplyMorphologyHorizontal_Scalar( const uint8_t* aSourceData, int32_t aSourceStride, uint8_t* aDestData, const uint8_t* aSourceData, int32_t aSourceStride, uint8_t* aDestData, Show All 18 Lines static void ApplyMorphologyVertical_Scalar( int32_t startY = aDestRect.Y() - aRadius; int32_t startY = aDestRect.Y() - aRadius; int32_t endY = aDestRect.Y() + aRadius; int32_t endY = aDestRect.Y() + aRadius; for (int32_t y = aDestRect.Y(); y < aDestRect.YMost(); for (int32_t y = aDestRect.Y(); y < aDestRect.YMost(); y++, startY++, endY++) { y++, startY++, endY++) { for (int32_t x = aDestRect.X(); x < aDestRect.XMost(); x++) { for (int32_t x = aDestRect.X(); x < aDestRect.XMost(); x++) { int32_t sourceIndex = startY * aSourceStride + 4 * x; int32_t sourceIndex = startY * aSourceStride + 4 * x; uint8_t u[4]; uint8_t u[4]; for (size_t i = 0; i < 4; i++) { for (int32_t i = 0; i < int32_t(std::size(u)); i++) { u[i] = aSourceData[sourceIndex + i]; u[i] = aSourceData[sourceIndex + i]; } } sourceIndex += aSourceStride; sourceIndex += aSourceStride; for (int32_t iy = startY + 1; iy <= endY; for (int32_t iy = startY + 1; iy <= endY; iy++, sourceIndex += aSourceStride) { iy++, sourceIndex += aSourceStride) { for (size_t i = 0; i < 4; i++) { for (int32_t i = 0; i < int32_t(std::size(u)); i++) { if (Operator == MORPHOLOGY_OPERATOR_ERODE) { if (Operator == MORPHOLOGY_OPERATOR_ERODE) { u[i] = umin(u[i], aSourceData[sourceIndex + i]); u[i] = umin(u[i], aSourceData[sourceIndex + i]); } else { } else { u[i] = umax(u[i], aSourceData[sourceIndex + i]); u[i] = umax(u[i], aSourceData[sourceIndex + i]); } } } } } } int32_t destIndex = y * aDestStride + 4 * x; int32_t destIndex = y * aDestStride + 4 * x; for (size_t i = 0; i < 4; i++) { for (int32_t i = 0; i < int32_t(std::size(u)); i++) { aDestData[destIndex + i] = u[i]; aDestData[destIndex + i] = u[i]; } } } } } } } } void FilterProcessing::ApplyMorphologyVertical_Scalar( void FilterProcessing::ApplyMorphologyVertical_Scalar( const uint8_t* aSourceData, int32_t aSourceStride, uint8_t* aDestData, const uint8_t* aSourceData, int32_t aSourceStride, uint8_t* aDestData, ▲ Show 20 Lines • Show All 175 Lines • Show Last 20 Lines Add Comment Bold Italics Monospaced Link Bulleted List Numbered List Code Block Quote Table Upload File Meme Preview Help Fullscreen Mode Pin Form On Screen Privacy · Cookies · Legal
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: run an asan build on the sites listed in the bug and check that there are no errors reported
• Risk associated with taking this patch: low
• Explanation of risk level: just ensuring that we're dealing with the right values when we have negative numbers
• String changes made/needed: none
• Is Android affected?: yes

Comment 27

[Robert Longson [:longsonr]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D262967

Comment 28

[Robert Longson [:longsonr]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D262967

Comment 29

[Robert Longson [:longsonr]]

Attachment: (secure)

Original Revision: https://phabricator.services.mozilla.com/D262967

Comment 30

[Phabricator Automation]

firefox-esr115 Uplift Approval Request

• User impact if declined: possibly reading and writing to random memory locations
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: run an asan build on the sites listed in the bug and check that there are no errors reported
• Risk associated with taking this patch: low
• Explanation of risk level: just ensuring that we're dealing with the right values when we have negative numbers
• String changes made/needed: none
• Is Android affected?: yes

Comment 31

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/0a32cc2a0e70

Comment 32

[Daniel Holbert [:dholbert]]

(In reply to Phabricator Automation from comment #26)

firefox-esr140 Uplift Approval Request

User impact if declined: Differential D263127 Bug 1980788 - Use std::size rather than hardcoding an array size r=dholbert Needs ReviewCustom [...]

Something clearly went a bit awry in comment 26's firefox-esr140 uplift request form (Robert noticed and pinged me on matrix); not sure what happened there, but in any case: release managers, please just interpret the answers as being the same as those in comment 130 for firefox-esr115 :)

Comment 33

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/7c2395c10d3a
https://hg.mozilla.org/releases/mozilla-beta/rev/757ff6eacb6d

Comment 34

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/158270b6cdbc

Comment 35

[Daniel Bodea [:danibodea]]

• Firstly, I have to say that I cannot attempt reproduction on the original build because it contains no artifacts; it is empty.

• Secondly, I noticed that the originaly reporter build was a macOS AArch64 asan, which I cannot find in the Archive.

• So decided to try reproducing and confirmting on Windows 10:
  I assume I have reproduced the original issue using these steps:

1. Installed an asan build from before the fix from here on my Windows 10 system:
   Nightly v144.0a1 Asan Reporter Build ID: 20250828092344
2. Extracted the build.
3. Opened the build using a new profile.
4. Loaded about:debugging#/runtime/this-firefox
5. Clicked on "Load Temporarry Add-on..."
6. Loaded the Autobrowser add-on
7. Opened the Website Tab Loader Addon window and started the process.
   Result: The build fails at some point by crashing without a crashreport; sometimes showing "Couldn't load XPCOM" error.
   Expected: The build does not freeze or fail, but loads all 1000 websites.

I have attempted to confirm the fix using these steps:

1. Installed an asan build from after the fix from here on my Windows 10 system:
   Nightly v144.0a1 Asan Reporter Build ID: 20250901094023
2. Extracted the build.
3. Opened the build using a new profile.
4. Loaded about:debugging#/runtime/this-firefox
5. Clicked on "Load Temporarry Add-on..."
6. Loaded the Autobrowser add-on
7. Opened the Website Tab Loader Addon window and started the process.
   Result: The build fails at some point by crashing without a crashreport; No XPCOM error is shown.
   Expected: The build does not freeze or fail, but loads all 1000 websites.

• As a conclusion, I do not know whether the fix does anything to help here. Can you help us understand what the issue is and how to verify it? Does this affect all operating systems? Thanks!

Comment 36

[Robert Longson [:longsonr]]

I'm afraid I can't help you, you'd need to speak to Andrew. All I can say is that I used the debugger to see what was going on, determined that the array index was huge instead of the intended negative value and fixed that. I've not tried to make an asan build myself.

Comment 37

[Andrew Creskey [:acreskey]]

(In reply to Robert Longson [:longsonr] from comment #15)

Ahh I think I've got it...

int i = -1;
size_t j = 0;

i + j is not -1 it's a big number.

Good catch!

Let me try this overnight.

I've never built ASan locally, I just push to try and request the asan job.

Comment 38

[Andrew Creskey [:acreskey]]

Side note:
Mozilla's Site-Scout is much better tooling for browsing lives sites
https://github.com/MozillaSecurity/site-scout

Comment 39

[Daniel Holbert [:dholbert]]

note, I suspect the reason Danibodea [and I] can't repro is that we're using SSE2-capable CPUs, which are unaffected per longsonr's observation in comment 18.

We take a different codepath on builds for those platforms, per the USE_SSE2 check here: https://searchfox.org/firefox-main/rev/cd639e07f74b203d72b0f4a2bea757ae9e10401a/gfx/2d/FilterProcessing.cpp#65-76

Comment 40

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/a8dde2a6b796

Comment 41

[Andrew Creskey [:acreskey]]

(In reply to Andrew Creskey [:acreskey] from comment #12)

List of the other sites, perhaps easier to isolate there:

https://www.jsdelivr.com/
http://bootstrapcdn.com/
https://owncloud.com/
https://developer.hashicorp.com/consul
https://developer.hashicorp.com/terraform
https://developer.hashicorp.com/packer
https://newrelic.com/
https://buildkite.com/

Using the source from Sept 2 mozilla central nightly, and this binary, I'm happy to report that I did not encounter the FilterProcessing::ApplyMorphologyHorizontal_Scalar asan error on any of the above sites nor in a longer run of live sites via Site-Scout.

Comment 42

[Mira Lobontiu (Android QA)]

Hi all!
Does this issue need Android verification as well?
If yes, please provide steps to reproduce.
Thank you!

Comment 43

[Daniel Bodea [:danibodea]]

Since this verification would need specific CPUs (we're using SSE2-capable CPUs, which are unaffected per longsonr's observation in comment 18) as per comment 39 and the fact that verification builds would need to be built locally as per comment 37, Desktop QA cannot confirm verification.

Comment 44

[Daniel Holbert [:dholbert]]

(In reply to Mira Lobontiu (Android QA) from comment #42)

Does this issue need Android verification as well?

No, I don't think it does - Andrew's comment 41 is sufficient. Thanks!