CVE-2025-48596 AI-generated analysis
platform/frameworks/native, libbinder (libs/binder/Parcel.cpp)
Parcel::appendFrom in libbinder now sets mDataSize to mDataPos only when the new position exceeds the current size, instead of unconditionally adding len to mDataSize.
Root cause
In libs/binder/Parcel.cpp, Parcel::appendFrom copied len bytes into the destination at mDataPos, advanced mDataPos by len and then ran `mDataSize += len` unconditionally. If the destination's mDataPos was below mDataSize at call time, the write overlapped existing data and added fewer than len new bytes, but mDataSize still grew by the full len. The capacity check before the copy only compares mDataPos + len against mDataCapacity, so the inflated mDataSize could exceed both the valid data and the capacity checked for, leaving the Parcel with a size field that does not match its buffer.
How the fix works
- libs/binder/Parcel.cpp : Parcel::appendFrom - the line `mDataSize += len;` after the memcpy and `mDataPos += len;` is replaced with `if (mDataPos > mDataSize) mDataSize = mDataPos;`, so mDataSize becomes max(old mDataSize, new mDataPos). mDataSize therefore cannot pass mDataPos + len unless it was already larger, and mDataPos + len is the value the preceding capacity check compares against.
- Single one-line commit; no other files, no change to the range checks against the source parcel, validateReadData, growData or the kernel-object (flat_binder_object) copying that follows.
Completeness
- In the part of appendFrom shown in the material, this is the only update to mDataSize. The new expression is correct for both the pure-append case (mDataPos == mDataSize before the call, same result as the old code) and the overwrite-in-the-middle case.
- The object-copying block after the fix (kernelFields / mObjects handling) is untouched by this commit, and the material shows only part of it. The material does not show whether it depends on the old mDataSize value.
- Other Parcel write paths (writeInplace, setDataSize, etc.) are not part of this change; the material only shows appendFrom.
Behavior changes
- After appendFrom into a position below the current data size, dataSize() now reflects the real end of data (max of old size and new position) rather than an inflated value.
- No new error codes; return values of appendFrom are unchanged.
Per major
- Android 14: same fix: platform/frameworks/native aa67ec623b7d in android-security-14.0.0_r24, one-line change in Parcel::appendFrom; at android-security-14.0.0_r29, 2/3 lines of the patched region are present, including the fixed line.
- Android 15: same fix: platform/frameworks/native de36dac70667 in android-security-15.0.0_r12, identical one-line change (different line offset); at android-security-15.0.0_r17, 2/3 lines of the patched region are present.
- Android 16: same fix: platform/frameworks/native 6ffdde944d4e in android-security-16.0.0_r3, identical one-line change; at android-security-16.0.0_r8, 2/3 lines of the patched region are present.
- Android 17: not affected per the bulletin (not listed); at android-security-17.0.0_r1, 2/3 lines of the patched region are present.
Unknowns
- The material does not show which downstream read/write path uses the inflated mDataSize to produce the EoP impact the bulletin rates.
- Whether the binder_parcel_fuzzer or unit tests were extended in a separate commit is not shown.
- The bulletin lists Android 13 as affected, but the material includes no Android 13 commit.
- The rest of appendFrom after the object-count growth checks is not shown.