[BUG] net: tun: queue detach leaves stale flow steering indices

[Cheng Yongkang <teel4res@gmail.com>]

Hi all,

The TUN flow-steering purge after queue detach does not remove all
entries affected by moving the last queue into the detached slot.

__tun_detach() decrements numqueues before calling
tun_flow_delete_by_queue(), then uses numqueues + 1 for the purge.
Entries recorded with the detached queue's old index, and entries for
the queue moved down from the old last slot, can therefore survive.
TX flow steering subsequently selects the wrong queue fd, or selects an
out-of-range index that netdev_cap_txqueue() clamps to queue 0.

Observed on Linux v7.3, commit
08ab31164c55f20c7a2653de3186ae333470e2c1, with a three-queue TAP:

  learn F1 on queue 2
  detach queue 2
  send F1 reply
  tun0 selects TX queue 2, but real number of TX queues is 2
  packet is clamped to queue 0

  learn F2 on queue 1
  detach queue 1, moving queue 2 into slot 1
  send F2 reply
  the flow is read from queue 2's fd, not the no-entry baseline queue

The second differential directly proves wrong queue ownership, not only
the expected clamp warning.  Candidate BR-027 is the same off-by-one
purge root.

The detach path should purge both the old queue index and the moved
end-slot index, preferably before their meaning changes, or rebuild the
flow indices atomically when queues move.

I found no matching upstream fix.

The PoC and complete program/console logs are available on request.

This was found with a multi-agent workflow; the
behavior was reproduced in QEMU.

Thanks,
Cheng Yongkang