Re: [PATCH] um: vector: avoid NULL queue dereference in legacy RX mode

[Anton Ivanov]

On 28/05/2026 08:13, Johannes Berg wrote:
> On Wed, 2026-05-27 at 18:35 -0300, Henry Barreto wrote:
> > From: Henry Barreto <me@xxxxxxxxxxxxxxxx>
> >
> > Bringing a UML vector netdev up can panic in vector_net_open() with a
> > fault in _raw_spin_lock().
> >
> > vector_net_open() calls vector_reset_stats(), which takes the RX and TX
> > queue locks. However, queue allocation depends on runtime transport
> > options. With tap transport, vector RX/TX queues are not created and the
> > legacy header buffers are used instead. Taking a queue lock then
> > dereferences a NULL queue pointer.
> >
> > Take the queue locks in vector_reset_stats() only when the corresponding
> > queue exists. Also move the RX queue lock in vector_poll() into the
> > VECTOR_RX path, so legacy RX does not touch rx_queue.
> >
> > Fixes: 612a8c8e0b43 ("um: vector: Replace locks guarding queue depth with atomics")
>
> So ... you're effectively saying that the tap transport has been broken
> since 6.12, released ~1.5 years ago.

The one I use is raw :) It is the most useful.

Tap badly needs someone to expose the socket which the kernel uses to implement it. I started writing a kernel helper at some point, but never finished it. It should be able to produce "stupid speeds" with it.

And, yes indeed, this was broken by 612a8c8e0b43ba7e3d0e51f6f76a5fec4912d439 / 2024-07-05 which by the look of it I did not test for tap.

Nice catch.

> Maybe we should just remove that entirely since nobody complained?
>
> johannes

--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/