|
|
[ST+HW]
New object-lifetime defect in GCP, a TA that is loadable and invokable on this
card and was absent from linux-firmware entirely.
GCP keeps a context-wide session refcount at ctx+0x1E00, incremented by the three
create paths and decremented by the destroys, with the zero transition calling
gcp_asd_rpc_305(2), the ASD-side release paired with the 305(1) acquire. FE0D
validates the caller's handle with an ITTE block and then falls through to the
decrement and release on both outcomes, so a rejected handle still costs a
decrement and, at zero, an early ASD release. Its sibling FE0B branches away on a
bad handle and skips that code entirely; two destroy handlers of the same shape
differing exactly on whether the refcount work is guarded is what makes this a
defect rather than a design choice.
The only gate on the handle is the range check handle>>30==0, so any value below
0x40000000 that does not match a slot is rejected and still decrements. CBZ stops
the counter at zero, so the effect is desync and premature release rather than a
wrap.
Hardware confirms the asymmetry with the sibling as control: FE0D with handle
0x01234567 returns 0x2000002f, which is only produced after gcp_asd_rpc_305(2) is
called and fails, while FE0B with an equally invalid handle returns plain 0x100
and never reaches that code.
Limits stated: the run starts with the count at zero because creating a live
session needs ASD 305(1) to succeed and it fails without real DRM state, the same
gate that blocks the 0x202 disclosure, so what is proven is entry into the
decrement/release path on a rejected handle rather than a decrement from a
positive count. Downstream impact lives inside ASD, which this rig cannot observe.
Also recorded as a negative: GCP's three session arrays tile the context exactly
with correct bounds on every index, slot counts taken from the creation loops'
own terminators, so this finding is about the refcount and not about indexing.
|
