Re: security alerts in busybox

Ladislav Michl via busybox <[email protected]> Sat, 25 Apr 2026 21:46:02 +0200
Newsgroups gmane.linux.busybox
Message-ID <ae0Z-lDqQEU20m6v@lenoch>
On Fri, Apr 24, 2026 at 04:40:47PM +0200, Roberto A. Foglietta via busybox wrote:
> Hi,
> 
> Using a static code analyser, I found:
> 
> Open potentially alerts by severity/class in branch `main`:
> 
> - **security**: 103 critical, 96 high, 4 medium, **203 total**
> 
> Alerts above are related to C-language code, none otherwise.
> 
> Are these false positives? Well, it is more about corner cases like
> using the applet in a strong parallel mode like xargs -p8 does. If
> used for maintenance on a large enough infrastructure, the corner case
> has a chance to be met, for example.

Could you provide a short insight how that happends given these are
separate processes?

> https://github.com/robang74/busybox/commits/security/
> 
> commit f69e57f62798ae2bca9f5071adb45bfb002002b1 (HEAD -> security,
> origin/security)
> Author: Roberto A. Foglietta <[email protected]>
> Date:   Fri Apr 24 15:33:58 2026 +0200
> 
>     util-linux/ipcs.c: use of potentially dangerous function (fix)
> 
>     Alerts: #96-93,91,88-83,81-77
> 
>     +:git-shell:security:busybox> size busybox
>        text    data     bss     dec     hex filename
>     1155501   18124    2056 1175681  11f081 busybox
>     1155670   18132    2056 1175858  11f132 busybox
>                                +177
> 
> These are trivial alerts, therefore I faced it first to provide an
> example. And the second main question is straightforward: does this
> fix worth 177 bytes? In relative terms it is 150 ppm compared with the
> full size footprint. In terms of certifications is a solid step
> towards peace of mind.

These are not trivial alerts, but pure garbage. Adding even single
byte to 'fix' non-existant bug does not make any sense.

I would greatly appreciate if you could stop spamming this list with
the output of random analyzer tool which is clearly lacking context,
thus providing results which needs careful validation. That obviously
did not happen here...

	L.