Description

exec_ddprof() in src/lib/dd_profiling.cc (lines 271-274) allocates buffers that are 1 byte too small for the snprintf output:

char pid_buf[std::numeric_limits<pid_t>::digits10 + 1];   // = 10 bytes
(void)snprintf(pid_buf, sizeof(pid_buf), "%d", target_pid);
char pipefd_buf[std::numeric_limits<int>::digits10 + 1];   // = 10 bytes
(void)snprintf(pipefd_buf, sizeof(pipefd_buf), "%d", pipefd_to_library);

digits10 returns the number of decimal digits that can round-trip through the type (i.e., floor(log10(2^31 - 1)) = 9), not the number of digits in the maximum value. The maximum pid_t value (2,147,483,647) has 10 digits, so the buffer needs digits10 + 2 (10 digits + NUL), not digits10 + 1.

With the current size (10 bytes), snprintf silently truncates, passing a wrong PID to the execve call.

Practical mitigation

Linux caps PIDs at 2^22 (4,194,304 = 7 digits) by default, so this is unlikely to trigger in practice today. However, the code is technically wrong and could break if PID limits are raised.

Fix

Change + 1 to + 2 on both buffer declarations.

Related

This is in the same file as the off-by-one in #492 — another buffer sizing issue in the library mode entry point.

Classification

• CWE-131: Incorrect Calculation of Buffer Size