CVE-2025-8879
Overview
Background
- `libaom`
- the AOMedia reference AV1 codec library, vendored into Chromium at
third_party/libaom/source/libaomand pinned to an exact upstream commit. - `DEPS` roll
- a Chromium change that only moves a third-party dependency’s pinned revision; the actual code fix lives in the upstream repository and is not part of the Chromium diff.
- `src_sad_blk_64x64`
- per the subject of the associated Chromium merge commit (“Restrict
src_sad_blk_64x64to single spatial layer”), alibaomencoder buffer of per-64x64-block source SAD (sum of absolute differences) values; its sizing and indexing are not visible in this diff. - Spatial layers (SVC)
- scalable encoding in which one stream carries several resolutions, so per-frame buffers sized for one layer’s dimensions may not fit another layer’s (inferred relevance).
Root Cause Analysis
This patch is a pure DEPS roll, and the Chromium-side diff contains no libaom source changes. It moves the pinned libaom revision from 2cca4aba034f99842c2e6cdc173f83801d289764 to 1a5d58271aa6133b6fa7da9fa365290cc4f2cc4d, in three places: DEPS, the third_party/libaom/source/libaom gitlink, and the Revision: field in third_party/libaom/README.chromium. The advisory classifies the bug as a heap buffer overflow in libaom. The associated merge commit’s subject, “Restrict src_sad_blk_64x64 to single spatial layer”, suggests that the encoder used the src_sad_blk_64x64 buffer while encoding multiple spatial layers, where its allocation and the block grid being indexed could disagree in size, which would overflow the heap allocation (inferred; the upstream hunk is not in this diff).
The fix works by pulling in the upstream commit that limits use of that buffer to single-spatial-layer encoding, but the specific bounds or condition it adds cannot be verified from what is shown here.
libaom to 1a5d58271aa6133b6fa7da9fa365290cc4f2cc4d. The underlying mistake, per the merge subject, is that the src_sad_blk_64x64 path was used in multi-spatial-layer encoding where the buffer’s size assumptions do not hold (inferred), and upstream fixed it by restricting that path to a single spatial layer.Attack Path
- Reach the AV1 encoder
Content drives
libaomencoding inside Chrome, for example through WebRTC or WebCodecs AV1 encoding (inferred; the diff does not show which Chromium entry points uselibaom). - Request spatial scalability The attacker configures an encode with more than one spatial layer, which the merge subject names as the condition the fix removes (inferred).
- Trigger the source-SAD path
Encoding frames under that configuration makes the encoder compute or read
src_sad_blk_64x64entries outside the bounds of the buffer, producing the heap overflow named by the advisory (inferred; the exact sink is not in the diff). - Memory corruption The out-of-bounds access corrupts heap memory in the process hosting the encoder. Any further exploitation is not shown (inferred).
Impact Assessment
libaom encoder, most likely a renderer or utility/GPU process (inferred). Code execution or a sandbox escape is not demonstrated by this diff (inferred at most). The likely precondition is that the page can start an AV1 encode with multiple spatial layers (inferred).Files Changed
DEPSthird_party/libaom/README.chromiumthird_party/libaom/source/libaom
Audit Directions
- Per-layer buffer sizing in SVC encodersIn
libaom(andlibvpx’s equivalent real-time paths), check every per-block side buffer (SAD maps, content/scene-detection arrays, cyclic-refresh maps) for whether it is allocated at one resolution but indexed using the current spatial layer’smi_rows/mi_colsor 64x64 block counts. - Feature gating as a bounds fixWhen a fix disables a feature for some configurations instead of correcting the index math, look for other configurations (resolution changes mid-stream, dynamic layer changes,
scalabilityModereconfiguration) that reach the same buffer with mismatched dimensions. - Rolls that hide the fixFor
third_partyCVEs fixed throughDEPS, map the rolled range to upstream commits and diff them directly; also check every Chromium branch’s pin (the bug was merged to several branch heads) for the same exposure.
Patch
diff --git a/third_party/libaom/README.chromium b/third_party/libaom/README.chromium
index 7bbcd267..f9a09ff 100644
--- a/third_party/libaom/README.chromium
+++ b/third_party/libaom/README.chromium
@@ -2,7 +2,7 @@
Short Name: libaom
URL: https://aomedia.googlesource.com/aom/
Version: N/A
-Revision: 2cca4aba034f99842c2e6cdc173f83801d289764
+Revision: 1a5d58271aa6133b6fa7da9fa365290cc4f2cc4d
CPEPrefix: cpe:/a:aomedia:aomedia:3.12.1
License: BSD-2-Clause, Patent
License Android Compatible: yes
diff --git a/third_party/libaom/source/libaom b/third_party/libaom/source/libaom
index 2cca4ab..1a5d582 160000
--- a/third_party/libaom/source/libaom
+++ b/third_party/libaom/source/libaom
@@ -1 +1 @@
-Subproject commit 2cca4aba034f99842c2e6cdc173f83801d289764
+Subproject commit 1a5d58271aa6133b6fa7da9fa365290cc4f2cc4d
diff --git a/DEPS b/DEPS
index 1b0ae0a..3bc48a4 100644
--- a/DEPS
+++ b/DEPS
@@ -2285,7 +2285,7 @@
Var('chromium_git') + '/external/libaddressinput.git' + '@' + '2610f7b1043d6784ada41392fc9392d1ea09ea07',
'src/third_party/libaom/source/libaom':
- Var('aomedia_git') + '/aom.git' + '@' + '2cca4aba034f99842c2e6cdc173f83801d289764',
+ Var('aomedia_git') + '/aom.git' + '@' + '1a5d58271aa6133b6fa7da9fa365290cc4f2cc4d',
'src/third_party/crabbyavif/src':
Var('chromium_git') + '/external/github.com/webmproject/CrabbyAvif.git' + '@' + Var('crabbyavif_revision'),
Original Bug Report
Crash with three-way self Jitsi Meet call
IMPORTANT: Your crash has already been automatically reported to our crash system. Please file this bug only if you can provide more information about it.
Chrome Version: 138.0.7204.158 Operating System: Mac OS X 15.5.0
URL (if applicable) where crash occurred: https://beta.meet.jit.si/ATestJitsiConference/.
Can you reproduce this crash?
What steps will reproduce this crash? (If it’s not reproducible, what were you doing just before the crash?)
- Join a three-way call to the same Jitsi Meet conference, in three separate tabs. Turn on sending video on each tab. Turn on background blur for each video.
- Pull out the three tabs to three separate windows, all visible on-screen.
- Wait.
All three tabs crashed for me near-simultaneously. I have uploaded all three crashes. The three crash IDs are:
Crash from Tuesday, July 15, 2025 at 3:49:02 PM Status: Uploaded Uploaded Crash Report ID: 859a626b13b72cf4 Upload Time: Tuesday, July 15, 2025 at 4:04:03 PM Local Crash Context: 9e038f09-8976-45b5-8199-eae8e159ef68
Crash from Tuesday, July 15, 2025 at 3:48:39 PM Status: Uploaded Uploaded Crash Report ID: 4687da90671adb6e Upload Time: Tuesday, July 15, 2025 at 4:04:03 PM Local Crash Context: 10632e25-608c-4274-b3fd-7c5255fe0a9b
Crash from Tuesday, July 15, 2025 at 3:48:35 PM Status: Uploaded Uploaded Crash Report ID: f9d9ae28f307b76a Upload Time: Tuesday, July 15, 2025 at 4:04:03 PM Local Crash Context: 78a40942-7628-4a1f-8a03-99b59c3251d6
DO NOT CHANGE BELOW THIS LINE Crash ID: crash/f9d9ae28f307b76a