Re: security alerts in busybox

On Sun, 26 Apr 2026 at 16:02, Jody Bruchon via busybox
<[email protected]> wrote:
>
> On 2026-04-26 9:55 AM, Roberto A. Foglietta wrote:
> > On Sun, 26 Apr 2026 at 15:42, Jody Bruchon via busybox
> > <[email protected]> wrote:
> >> On 2026-04-26 6:11 AM, Roberto A. Foglietta wrote:
> >>   > This function is reading data beyond its allocation, for sure in that
> >> branch
> >>   > /* Handle data tail (for blocks indivisible by sizeof(jduphash_t)) */
> >> len = getrest_in_jduphash(count); if (len) { partial_salt =
> >> JDUP_HASH_CONSTANT & tail_mask[len]; element = *data & tail_mask[len];
> >>
> >> I don't know where you picked that poorly mangled code up but that's not
> >> what's in my branch at all:
> >> https://codeberg.org/jbruchon/jbusybox/src/branch/master/miscutils/jdupes.c#L508-L518
> > I agree that it is poorly managed, because it is your code written in
> > a manner that is easy to understand and as you quickly find out it is
> > poorly managed.
> >
> > /* Handle data tail (for blocks indivisible by sizeof(jodyhash_t)) */
> > len = count & (sizeof(jodyhash_t) - 1);
> > if (len) {
> >
> > In fact, it does not matter HOW you alloc the data buffer: the
> > prototype is still flawed in its definition and when data is allocated
> > in chunks of specific size, the second if never runs. Otherwise it
> > reads beyond the allocation. Which is exactly the "poorly managed"
> > definition of a coding style, I totally agree. Thanks for having said
> > that about your own code first. I would not have dared so much.
>
> Tell me you never actually read the code without telling me. const
> size_t count is a byte count. If count is not divisible by 4 aka
> sizeof(uint32_t) aka 2^2 then if (len) is true. AND masking by 0x03
> (which is what this function does in practice) is the simplest way to do
> this.

AND as logical 32bit operation applies on a pointer 32bit size which
points at a 32bit (4 bytes) area of memory but that 4 bytes are not
allocated in full, just partially.

size in bytes 1027,
last pointer 1024 (+4bytes)
cast pointer reads 4 bytes
one more beyond the limit
the extra value is masked
AFTER being read beyond the limit
a strict task manager will kill the process
usually not, and that is the problem

I am not sure if you pretend to not be able to differentiate the read
from the evaluation or just playing hoping to trick me, but the show
is grated anyway.

Best regards, R-