proc_read_vec: bound trailing NUL trim to the current string table

[iefa-m]

proc_read_vec tests strtab - *bufp >= 2 before trimming the extra trailing NUL, but the string table it just filled starts at *bufp + off rather than at *bufp. The environ read is handed a non-zero off, so when the tracee exec'd with an empty environment and nothing landed in this table, the test looks at the last two bytes of the argv pointer vector written by the previous call; those are its NULL terminator, so the trim always fires and strtab drops below the start of the table. strtab_len then underflows to SIZE_MAX and strtab_to_vec evaluates strtab + SIZE_MAX, which ubsan reports as a pointer overflow; an envp holding one empty string trips the same test and is miscounted as zero entries, so ptrace_verify_post_exec compares the wrong envc.

Compare against *bufp + off, which is what the strtab_len calculation two lines down already uses. The bound belongs next to the table it describes rather than to the whole allocation, so a caller chaining a second read into the same buffer does not have to know the trim exists. Reads where at least two bytes arrive behave exactly as before.

[millert]

Good catch, thanks!