Re: [PATCH] eal: fix alarm cancel list walk

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri,  4 Sep 2026 13:20:31 -0700
Stephen Hemminger <stephen@networkplumber.org> wrote:

> All three implementations of rte_eal_alarm_cancel() free entries while
> walking the alarm list with LIST_FOREACH, which leaves the iterator
> pointing into freed memory.
> 
> Linux and FreeBSD use two loops: one draining matches from the head of
> the list, then a LIST_FOREACH over the rest that frees the current
> entry and assigns the saved ap_prev to ap so iteration resumes from the
> predecessor.  ap_prev is only refreshed to a live entry by an iteration
> that does not remove, and the head loop leaves it NULL when it empties
> the list.  A removal in the second loop then sets ap to NULL or to an
> already freed entry, and the LIST_FOREACH increment dereferences it.
> GCC -fanalyzer reports the freed case:
> 
>   lib/eal/linux/eal_alarm.c:224:44: warning: use after 'free' of 'ap'
> 	[CWE-416] [-Wanalyzer-use-after-free]
> 
> Windows has no such dance: it calls alarm_remove_unsafe() straight from
> the loop body, so the increment reads freed memory on every removal but
> the last.
> 
> Replace all of these with LIST_FOREACH_SAFE.  FreeBSD sys/queue.h and
> the bundled Windows sys/queue.h already provide it; glibc does not, so
> define it locally as is already done in several drivers.
> 
> Fixes: af75078fece3 ("first public release")
> Fixes: f4cbdbc7fbd2 ("eal/windows: implement alarm API")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---

The windows bug is real, the other platforms it is not a bug but just
Gcc getting confused. Will split and resend