1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
|
# GCP version sweep: all three defects are present in every harvested build
The HDCP sweep is the precedent — its four overflow sites turned out to exist in all 17
builds, which turns "a bug" into "a bug that has never been fixed". The same question is
asked here of GCP's three defects, across every GCP body in the Windows-driver corpus.
`fw/gcp_version_sweep.py` locates each handler by its **own log string**
(`AMD_TA_GCP: DestroyCryptoSession ENTER`) rather than by address, because addresses move
between builds, then recovers the enclosing function and compares it.
## Result
| GCP build | `FE0F` liveness-free lookup | `FE0D` refcount on rejected handle | `FE0C` increment before failing acquire |
|---|---|---|---|
| 22.0.0.53 | DEFECT | DEFECT | DEFECT |
| 22.0.0.57 | DEFECT | DEFECT | DEFECT |
| 22.0.0.60 | DEFECT | DEFECT | DEFECT |
| 22.0.0.62 | DEFECT | DEFECT | DEFECT |
| 22.0.0.64 | DEFECT | DEFECT | DEFECT |
| 22.0.0.68 | DEFECT | DEFECT | DEFECT |
| 22.0.0.71 | DEFECT | DEFECT | DEFECT |
| 22.0.0.73 | DEFECT | DEFECT | DEFECT |
| 22.0.0.77 | DEFECT | DEFECT | DEFECT |
| **22.0.4.50** (analysed, on-card) | DEFECT | DEFECT | DEFECT |
**All three are present in all ten bodies.** None is a regression; none was ever fixed.
(`22.0.4.49` appears in the inventory but its body was not retained by the
content-minus-signature dedup, so ten bodies cover eleven version strings.)
## The one place a build differs, and why it is not a fix
`FE0F` grows from 82 to 114 bytes at 22.0.0.62. The scan loop is unchanged —
```
add.w r0, r6, #0x18 ; the never-written decode_handle field
movs r2, #8
bl <memcmp>
cbz r0, <match>
adds r6, #0x58 ; next slot
```
— and the 32 extra bytes are **three additional logging calls** on the not-found path
(`blx r5` with `0xf000`, `0`, `0x331`). AMD touched this function and added diagnostics
without adding the missing state test. Our on-card 22.0.4.50 matches the *older*, shorter
form, so the 22.0.4.x branch does not even carry the extra logging.
## Two method corrections worth recording
* **Byte hashing is the wrong comparator across builds.** Literal-pool offsets and branch
displacements move, so identical logic hashes differently. The sweep compares the
**mnemonic sequence** instead, which is stable under relocation.
* **A handler has several epilogues.** Walking forward to the first `pop {…,pc}` past the
string reference measured only the leading guard — 30 bytes for a 100-byte function, which
is what first made every build look "CHANGED". The walk now continues to the last epilogue
before the next prologue.
* **Signature detectors must key on the defect, not its surroundings.** The first `FE0C`
check required `orr #0x20000000`, which is merely how 22.0.4.50 *wraps* the error code;
older builds return the acquire's status directly. Keying on the actual defect — refcount
committed, then a conditional acquire whose failure returns — shows all ten builds affected.
## Why this matters for the report
A defect spanning the whole available build range removes the most convenient dismissal
("fixed in a later driver") and sets the disclosure scope: every Navi-3x consumer driver in
the corpus, from the earliest harvested GCP build to the one currently on the card.
|
