CVE-2023-40077 AI-generated analysis

platform/frameworks/av, media foundation (MetaDataBase, media/module/foundation/MetaDataBase.cpp), reached via httplive (HTTP Live Streaming) per the commit subject

AI-generated: written from the bulletin and the fixing diffs by claude-fable-5-1, then checked against the code by claude-opus-5-5 (8 corrections). Verify against the commit before relying on it.

Adds a std::mutex to MetaDataBase::MetaDataInternal and takes it in clear, remove, setData, findData, hasData, toString, dumpToLog and writeToParcel, so concurrent threads no longer race on the KeyedVector of items.

Root cause

MetaDataBase stores its items in a KeyedVector<uint32_t, typed_data> inside MetaDataInternal with no synchronization. When one thread mutates the vector (setData, remove, clear) while another thread looks it up or iterates it (findData, hasData, toString, dumpToLog, writeToParcel), the vector can change underneath the reader, which then accesses the wrong memory. The commit message attributes the use-after-free to the httplive path.

How the fix works

• media/module/foundation/MetaDataBase.cpp: adds #include <mutex> and a std::mutex mLock member to struct MetaDataBase::MetaDataInternal. That struct is accessed through the mInternalData pointer, so const methods can also lock it.
• MetaDataBase::clear and MetaDataBase::remove: take std::lock_guard<std::mutex> on mInternalData->mLock before touching mItems.
• MetaDataBase::setData: the lock is taken before indexOfKey and the add or replace of the item that follows.
• MetaDataBase::findData and MetaDataBase::hasData (both const): the lock is taken before indexOfKey.
• MetaDataBase::toString and MetaDataBase::dumpToLog: the lock is taken before iterating mItems by index (size()/keyAt). MetaDataBase::writeToParcel: the lock is taken before reading mItems.size().
• Single commit with 11 insertions and no logic or data-structure change. The fix only adds mutual exclusion around the existing KeyedVector operations.

Completeness

• The eight functions touched by the diff are now serialized by a per-object mutex.
• The diff does not touch the MetaDataBase copy constructor, operator=, constructor or destructor. The material does not show whether these access mItems without the lock.
• The lock is per MetaDataBase instance and does not address the lifetime of the MetaDataBase object itself.

Behavior changes

• The patched MetaDataBase functions now acquire a non-recursive std::mutex, so calls on the same object from different threads serialize. There are no new error codes or API changes.
• Re-entrant use (calling another locked method on the same object while the lock is held) would deadlock. The diff shows no such nesting inside the patched functions.

Per major

• Android 14: same fix: commit f980a9bee224 landed in android-security-14.0.0_r3. At android-security-14.0.0_r29, 8/8 lines of the patched region are present in media/module/foundation/MetaDataBase.cpp.
• Android 15: not affected (not listed by the bulletin). The patched region (8/8 lines) is present at android-security-15.0.0_r17.
• Android 16: not affected (not listed by the bulletin). The patched region (8/8 lines) is present at android-security-16.0.0_r8.
• Android 17: not affected (not listed by the bulletin). The patched region (8/8 lines) is present at android-security-17.0.0_r1.

Unknowns

• The specific httplive call sites and threads that raced on the MetaDataBase object (the commit message only names the component).
• Whether the MetaDataBase copy constructor or operator= access mItems without the new lock.
• Whether the data pointer returned by findData points into vector-owned storage and is used by callers after the lock is released.
• The fix commits for Android 11, 12, 12L and 13, and the path of MetaDataBase.cpp on those branches.

Back to December 2023 · Findings