Re: [PR] fix: five memcpy calls in buffer/apr_buffer in apr_buffer.c [apr]

Den s=C3=B6n 17 maj 2026 kl 19:14 skrev orbisai0security (via GitHub)
<[email protected]>:
>
>
> orbisai0security commented on PR #73:
> URL: https://github.com/apache/apr/pull/73#issuecomment-4471676980
>
>    Thanks for the review. I agree that the current description overstates=
 the issue and incorrectly frames this as a confirmed critical overflow.
>
>    I=E2=80=99ll revise the PR to narrow it to defensive hardening only. I=
n particular, I=E2=80=99ll remove the =E2=80=9Cfive memcpy calls=E2=80=9D /=
 =E2=80=9Ccritical severity=E2=80=9D language and keep only the allocation-=
failure guard before memcpy(), since calling memcpy with a NULL destination=
 after alloc() failure would be undefined behaviour.
>
>    For the APR_BUFFER_MAX checks, I understand your point that they do no=
t prove that src->d.mem is actually backed by src->size bytes, so they do n=
ot fix the claimed issue. I=E2=80=99m happy to drop those from this PR unle=
ss you think they are still useful as a separate invariant check.
>
>    Would a smaller patch focused only on the alloc() NULL check, with tes=
ts/docs adjusted for expected behaviour, be acceptable?

I will refer this question to the rest of dev@

Cheers,
Daniel