Heap Buffer Overflow in UnrollChunkyBytes() in cmspack.c

[Xuhxx]

Description

A heap buffer overflow vulnerability has been identified in the UnrollChunkyBytes() in cmspack.c in lcms2-2.16. The vulnerability may occurs due to insufficient boundary checking.

Result of ASAN:

=================================================================
==882103==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000335 at pc 0x555cfafdee23 bp 0x7ffc958d9130 sp 0x7ffc958d9128
READ of size 1 at 0x602000000335 thread T0
    #0 0x555cfafdee22 in UnrollChunkyBytes /home/CVE-lcms/project/lcms2.16/src/cmspack.c:130:13
    #1 0x555cfaff9b65 in CachedXFORM /home/CVE-lcms/project/lcms2.16/src/cmsxform.c:535:21
    #2 0x555cfafef94a in cmsDoTransform /home/CVE-lcms/project/lcms2.16/src/cmsxform.c:206:5
    #3 0x555cfaf3d275 in main /home/CVE-lcms/harness/harness-2.cc:70:13
    #4 0x7fc770f7cd8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 490fef8403240c91833978d494d39e537409b92e)
    #5 0x7fc770f7ce3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: 490fef8403240c91833978d494d39e537409b92e)
    #6 0x555cfae626d4 in _start (/home/CVE-lcms/harness/harness-2+0x776d4) (BuildId: b962610d7fe2b4a6)

0x602000000335 is located 0 bytes after 5-byte region [0x602000000330,0x602000000335)
allocated by thread T0 here:
    #0 0x555cfaefc4fe in malloc (/home/CVE-lcms/harness/harness-2+0x1114fe) (BuildId: b962610d7fe2b4a6)
    #1 0x555cfaf3d1d1 in main /home/CVE-lcms/harness/harness-2.cc:65:23
    #2 0x7fc770f7cd8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 490fef8403240c91833978d494d39e537409b92e)
    #3 0x7fc770f7ce3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: 490fef8403240c91833978d494d39e537409b92e)
    #4 0x555cfae626d4 in _start (/home/CVE-lcms/harness/harness-2+0x776d4) (BuildId: b962610d7fe2b4a6)

SUMMARY: AddressSanitizer: heap-buffer-overflow /home/CVE-lcms/project/lcms2.16/src/cmspack.c:130:13 in UnrollChunkyBytes
Shadow bytes around the buggy address:
  0x602000000080: fa fa fd fd fa fa fd fd fa fa fd fd fa fa 00 04
  0x602000000100: fa fa 00 04 fa fa fd fd fa fa fd fd fa fa fd fd
  0x602000000180: fa fa fd fd fa fa fd fd fa fa fd fd fa fa 00 04
  0x602000000200: fa fa 00 04 fa fa fd fd fa fa fd fd fa fa fd fd
  0x602000000280: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
=>0x602000000300: fa fa fd fd fa fa[05]fa fa fa 05 fa fa fa fa fa
  0x602000000380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000000400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000000480: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000000500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x602000000580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==882103==ABORTING

Affected Version

lcms2-2.16

POC

Poc-UnrollChunkyBytes.zip
You can reproduce the vulnerability with:
./harness input

Analysis

The vulnerability occurs due to insufficient boundary checking when processing input data during color transformation. Specifically:

Little-CMS/src/cmspack.c

Lines 126 to 141 in 453bafe

	for (i=0; i < nChan; i++) {
	cmsUInt32Number index = DoSwap ? (nChan - i - 1) : i;
	v = FROM_8_TO_16(*accum);
	v = Reverse ? REVERSE_FLAVOR_16(v) : v;
	if (Premul && alpha_factor > 0)
	{
	v = ((cmsUInt32Number)((cmsUInt32Number)v << 16) / alpha_factor);
	if (v > 0xffff) v = 0xffff;
	}
	wIn[index] = (cmsUInt16Number) v;
	accum++;
	}

The Issue arises when:

1. The function attempts to read nChan bytes from the input buffer without verifying if enough memory has been allocated
2. No validation is performed to ensure that accum + nChan stays within the bounds of the allocated buffer
3. The function assumes the input buffer contains enough data for the color transformation

[mm2]

It is likely you are calling cmsDoTransform with the wrong number of pixels. Without any source code I don't know.
Please double check your code prior submitting what you consider a "vulnerability". fread() can be also "vulnerable" if you call it wrongly.