High watch CVSS 8.8 chrome OOB 📄 Reporter bug report 🔧 Commit mapped

Overview

High
Severity
8.8
CVSS
No
Exploited ITW
Fixed
Fix Status
ImpactHeap buffer overflow in libaom
DescriptionHeap buffer overflow in libaom
ComponentChromium
Sub-componentCfM-R138
Bug ClassOOB
Action tierwatch — corruption primitive but gated (uncommon) — not default-reachable
Computed by PatchGap's deterministic exploitability ruler from the fixing commit. patch-now = RCE-class & attacker-reachable in a default config, or exploited in the wild; watch = real security signal below that bar; noise = no security relevance.
Tracker432035817
Fix commit4ac713469d51 (chromium/src) +3/-3
CWECWE-122 (Heap buffer overflow)
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
CISA KEVNot listed
CreditedAnonymous
Reported2025-07-15 (per vendor advisory)
Fix landed2025-08-29 (public git)
Disclosed2025-08-12

Background

`libaom`
the AOMedia reference AV1 codec library, vendored into Chromium at third_party/libaom/source/libaom and 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_64x64 to single spatial layer”), a libaom encoder 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.

Key insight
Chromium fixed this by rolling 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

  1. Reach the AV1 encoder Content drives libaom encoding inside Chrome, for example through WebRTC or WebCodecs AV1 encoding (inferred; the diff does not show which Chromium entry points use libaom).
  2. 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).
  3. Trigger the source-SAD path Encoding frames under that configuration makes the encoder compute or read src_sad_blk_64x64 entries outside the bounds of the buffer, producing the heap overflow named by the advisory (inferred; the exact sink is not in the diff).
  4. 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

The advisory rates this as high severity, a “Heap buffer overflow in libaom”, and does not report exploitation in the wild. If reachable from web content, it gives heap corruption in whichever sandboxed process runs the 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

  • DEPS
  • third_party/libaom/README.chromium
  • third_party/libaom/source/libaom

Audit Directions

  • Per-layer buffer sizing in SVC encoders
    In libaom (and libvpx’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’s mi_rows/mi_cols or 64x64 block counts.
  • Feature gating as a bounds fix
    When 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, scalabilityMode reconfiguration) that reach the same buffer with mismatched dimensions.
  • Rolls that hide the fix
    For third_party CVEs fixed through DEPS, 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.
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'),
Loading diff…

Original Bug Report

reported by [email protected]

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?)

  1. 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.
  2. Pull out the three tabs to three separate windows, all visible on-screen.
  3. 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

View on issue tracker