NULL pointer dereference in libpff_record_entry_get_multi_value (wrong NULL check variable)

[ByamB4]

Description

NULL pointer write in libpff_record_entry_get_multi_value() at libpff_record_entry.c:2840. A copy-paste bug on line 2793 checks value_offset instead of value_size after allocating value_size.

CWE: CWE-476 (NULL Pointer Dereference)
Commit: 06f239d

Bug

// libpff_record_entry.c:2790-2793
internal_multi_value->value_size = (size_t *) memory_allocate(
    sizeof( size_t ) * internal_multi_value->number_of_values );

if( internal_multi_value->value_offset == NULL )  // BUG: should be value_size

If value_size allocation fails, the NULL return is never caught and is subsequently dereferenced at line 2840.

On 64-bit systems, the value_size allocation is 2x larger than value_offset (sizeof(size_t)=8 vs sizeof(uint32_t)=4), so a large number_of_values can cause value_size to fail while value_offset succeeds.

ASAN Output

==1==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
==1==The signal is caused by a WRITE memory access.
    #0 in libpff_record_entry_get_multi_value libpff_record_entry.c:2840
SUMMARY: AddressSanitizer: SEGV libpff_record_entry.c:2840

7/7 test cases pass with AddressSanitizer confirming the crash.

Suggested Fix

-if( internal_multi_value->value_offset == NULL )
+if( internal_multi_value->value_size == NULL )

Impact

• Denial of Service (crash) when parsing crafted PST/OST files with multi-value properties
• Affects any application using libpff to parse untrusted Personal Folder Files (e.g., email forensics tools, e-discovery, data migration)
• The OSS-Fuzz harness for libpff does not exercise getter APIs (only open/close), so this bug was not caught by continuous fuzzing

Environment

• Ubuntu 22.04, GCC with AddressSanitizer
• Discovered via manual code audit (variant analysis of allocation pattern)