After I compiling the program with Asan, I found a heap buffer overflow bug.
Description:
A heap-buffer-overflow occurs when parsing numeric arguments via parse_long. The function allocates only 4 bytes (uint32_t), but the returned buffer is later accessed as an 8-byte value (e.g., long or uint64_t), leading to an out-of-bounds read.
ASan Report
Root Cause
parse_long allocates memory using sizeof(uint32_t) (4 bytes), but the caller interprets the returned pointer as a larger type (likely long, 8 bytes on 64-bit systems). This mismatch causes a read beyond the allocated buffer.
Problematic Code
in options.c
in args.c
Analysis:
Allocation size: 4 bytes (uint32_t)
Actual usage: 8-byte read pool->pending_time(time_t 8 byte)
Result: Heap buffer overflow (read past allocated region)
Suggested Fixes:
(if 64-bit values are intended):
Update allocation and storage to match long:
int
parse_long (char *s, void **p)
{
*p = malloc(sizeof(long));
long n = strtol(s, NULL, 0);
memcpy(*p, &n, sizeof(n));
return sizeof(long);
}
After I compiling the program with Asan, I found a heap buffer overflow bug.
Description:
A heap-buffer-overflow occurs when parsing numeric arguments via parse_long. The function allocates only 4 bytes (uint32_t), but the returned buffer is later accessed as an 8-byte value (e.g., long or uint64_t), leading to an out-of-bounds read.
ASan Report
Root Cause
parse_long allocates memory using sizeof(uint32_t) (4 bytes), but the caller interprets the returned pointer as a larger type (likely long, 8 bytes on 64-bit systems). This mismatch causes a read beyond the allocated buffer.
Problematic Code
in options.c
in args.c
Analysis:
Allocation size: 4 bytes (uint32_t)
Actual usage: 8-byte read pool->pending_time(time_t 8 byte)
Result: Heap buffer overflow (read past allocated region)
Suggested Fixes:
(if 64-bit values are intended):
Update allocation and storage to match long: