2008365 - (CVE-2026-2794) Memory disclosure vulnerability in ContentParent::RecvGetIconForExtension

Status: RESOLVED FIXED

(GeckoView :: General, defect, P2)

Description

[stevej]

Vulnerability Logic:

1. RecvGetIconForExtension allocates a buffer bits using bits->AppendElements(size).
2. For uint8_t, AppendElements does not zero-initialize the memory; it simply allocates the space on the heap.
3. This buffer is passed to AndroidBridge::Bridge()->GetIconForExtension.
4. Inside GetIconForExtension, there is a size check: if (len == bufSize) memcpy(...).
5. If len != bufSize, the memcpy is skipped entirely.
6. The function returns IPC_OK() without modifying the bits buffer further.
7. Result: The bits array, containing raw uninitialized memory from the Parent process heap, is sent back to the untrusted Child process.

Impact:
A compromised child process could trigger this path to read uninitialized memory from the parent process (Sandbox Escape / Information Disclosure).

Suggested Fix:

1. Ensure the buffer is zero-initialized upon allocation (e.g., use AppendElements with a value or SetLength + memset).
2. Or, ensure RecvGetIconForExtension returns an error if GetIconForExtension fails to populate the buffer.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:owlish, could you consider increasing the severity of this security bug?

For more information, please visit BugBot documentation.

Comment 2

[Andrew McCreight [:mccr8]]

I think the fix here is something like changing

bits->AppendElements(aIconSize * aIconSize * 4);

to

bits->InsertElementsAt(0, aIconSize * aIconSize * 4, 0);

It would be good if we could quickly fix the sec-high bug.

Comment 3

[stevej]

Just asking guys, since this report marked as sec-high. Do you have any SLA for resolving report like this?

Comment 4

[Andrew McCreight [:mccr8]]

(In reply to stevej from comment #3)

Do you have any SLA for resolving report like this?

No, but hopefully it'll get fixed soon as it has been assigned and it should be easy to fix.

Comment 5

[Andrew McCreight [:mccr8]]

[Tracking Requested - why for this release]: sec-high bug that should be easy to fix

Comment 6

[Donal Meehan [:dmeehan]]

:Gela, next week is the last week of beta for Fx148

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox148 (beta) and tracked for firefox149 (nightly). However, the bug still has low severity.

:owlish, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 8

[:Gela]

Attachment: (secure)

Comment 9

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: This is a small fix for a high security bug where in a non-zero initialized array, we risk leaking that daya into an untrusted content process. This change essentially resets the bytes to 0 first so no accidental data leaks happen before calling into the AndroidBridge.
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: I've done manual testing to ensure the downloaded files' icons appear as usual in the Downloads UI in the Firefox on Android app.
• Risk associated with taking this patch: low
• Explanation of risk level: It's a really small change where we zero-initialize the array first before passing it to the child process. The logic remains the same, we just override the existing data to 0 to avoid data leaks. This is Android only as the impacted code is wrapped in #ifdef MOZ_WIDGET_ANDROID
• String changes made/needed: No
• Is Android affected?: yes

Comment 10

[:Gela]

Attachment: (secure)

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

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/3b3d89cbc239
https://hg.mozilla.org/integration/autoland/rev/1dce5a7d4ddb
Update Content Parent r=tcampbell

Comment 12

[Andrew McCreight [:mccr8]]

This should have gotten sec-approval before landing. It would be a good idea to fill out the sec-approval form though the cart is kind of out of the barn already.

Comment 13

[:Gela]

Sorry @mccr8, I wasn't aware of the sec-approval process. Do I need to set a sec-approval flag somewhere in the ticket as well?

Here's the sec-approval form, please let me know if there's anything else I can provide. I'll keep this in mind for the next ticket.

[Security approval request comment]

• How easily can the security issue be deduced from the patch?
  There is a comment above the changed line explaining the reasoning for zero initializing the bytes which could reveal the vulnerability.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
  The comment does, yes.
• Which older supported branches are affected by this flaw?
  All variations of Firefox on Android are impacted by this flaw.
• If not all supported branches, which bug introduced the flaw?
  N/A.
• Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
  I do not have backports.
• How likely is this patch to cause regressions; how much testing does it need?
  It's a trivial change and highly unlikely to cause regressions. I performed manual testing by downloading various file types and ensuring that the icons for different extensions appear correctly.

Comment 14

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

https://hg.mozilla.org/mozilla-central/rev/1dce5a7d4ddb

Comment 15

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/c7e6321e7f6c
https://hg.mozilla.org/releases/mozilla-beta/rev/814f1a2ae29b

Comment 16

[Daniel Veditz [:dveditz]]

Comment on attachment 9544315 [details]
(secure)

(In reply to :Gela from comment #13)

• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
  The comment does, yes.

The main agenda of that question was to prompt developers to consider changing their patch so they can get to an answer other than "yes". During the sec-approval review we come to our own conclusions, and we would have asked you to remove those comments before landing if we'd done things in the right order.

It shouldn't be too much risk in this case since this is only useful to an attacker if they've already compromised a child process, and by squeaking into the 148 release at the last minute there's not much window of opportunity to take advantage of it. Please read the Security issue approval process and keep it in mind. If you need to look it up in the future you can find the link in the orange band at the top of every security bug.

sec-approval+

Comment 17

[Daniel Veditz [:dveditz]]

(In reply to :Gela from comment #13)

• How easily can the security issue be deduced from the patch?
  There is a comment above the changed line explaining the reasoning for zero initializing the bytes which could reveal the vulnerability.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
  The comment does, yes.
• Which older supported branches are affected by this flaw?
  All variations of Firefox on Android are impacted by this flaw.
• If not all supported branches, which bug introduced the flaw?
  N/A.
• Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
  I do not have backports.
• How likely is this patch to cause regressions; how much testing does it need?
  It's a trivial change and highly unlikely to cause regressions. I performed manual testing by downloading various file types and ensuring that the icons for different extensions appear correctly.

Comment 18

[stevej]

Hello guys, can you edit my name in security advisories firefox from stevej to Steven Julian?

Comment 19

[Andrew McCreight [:mccr8]]

(In reply to stevej from comment #18)

Hello guys, can you edit my name in security advisories firefox from stevej to Steven Julian?

Comment 20

[Simon Friedberger [:simonf]]

Fixed, please put whatever you want as credit in your Bugzilla profile as real name. That's what the scripts pick up automatically.