Re: [PATCH] um: vector: fix NULL pointer derefs in queue-less transports

[Johannes Berg <johannes@sipsolutions.net>]

Sorry, I didn't pay much attention to this before...

On Fri, 2026-04-10 at 16:30 -0400, Michael Bommarito wrote:
> TAP transport sets neither VECTOR_RX nor VECTOR_TX, so
> vector_net_open() never allocates rx_queue or tx_queue.  HYBRID sets
> VECTOR_RX but not VECTOR_TX, so tx_queue is NULL there too.
> 
> vector_reset_stats(), vector_poll(), vector_get_ethtool_stats(), and
> vector_get_ringparam() unconditionally deref these queue pointers,
> causing a NULL pointer crash on SMP or with any lock debugging option.
> 
> Guard all queue pointer accesses with NULL checks.

I see how that fixes the crash, but maybe you could write a few words on
why it's still correct?

> -	spin_lock(&vp->tx_queue->head_lock);
> -	spin_lock(&vp->rx_queue->head_lock);
> +	if (vp->tx_queue)
> +		spin_lock(&vp->tx_queue->head_lock);
> +	if (vp->rx_queue)
> +		spin_lock(&vp->rx_queue->head_lock);
>  	memcpy(tmp_stats, &vp->estats, sizeof(struct vector_estats));

I could imagine for example this memcpy() observing a torn write or
something like that and getting strange results out?

Or is that just not a thing because UML is (still) mostly non-SMP?


Also I think there are related issues that wouldn't show up for a broken
configuration, such as if create_queue() fails to allocate memory and we
get an inconsistency between tx_queue / rx_queue pointers and VECTOR_TX
/ VECTOR_RX flags? Though I'll admit that seems highly unlikely.

johannes