On Fri, 4 Sep 2026 13:20:31 -0700
Stephen Hemminger <[email protected]> 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: [email protected]
>
> Signed-off-by: Stephen Hemminger <[email protected]>
> ---
The windows bug is real, the other platforms it is not a bug but just
Gcc getting confused. Will split and resend
