[BUG] net: tun: flow update can repopulate a purged detached queue

[Cheng Yongkang <teel4res@gmail.com>]

Hi all,

tun_get_user() checks !tfile->detached before entering its receive RCU
section, but calls tun_flow_update() after leaving that section.  Queue
detach can complete between those points.  Detach's synchronize_net()
does not cover the hash computation made before the RCU section or the
flow insertion made after RCU unlock.

The late write therefore installs a flow entry with the detached
queue's queue_index after detach has already purged flow entries for
that queue.  A matching TX can then steer to a detached or out-of-range
queue.

Observed on Linux v7.3, commit
08ab31164c55f20c7a2653de3186ae333470e2c1.  A two-stage GDB condition
observed both:

  detach completed its flow purge
  tfile->detached == tun
  tun_flow_update() still ran
  queue_index=2, numqueues=2

The later TX produced:

  tun0 selects TX queue 2, but real number of TX queues is 2

The condition was hit in two independent runs and is distinct from the
purge off-by-one in candidate BR-018/027: even a complete purge can be
followed by this stale insertion.

The detached state and the flow update need to be covered by the same
ordering rule.  One option is to perform the flow lookup/update while
the receive RCU protection still guarantees that detach cannot pass its
synchronize_net(), then avoid using a detached tfile after unlock.

I found no matching upstream fix.

The reproducer, GDB script, and full logs are available on request.

This was found with a multi-agent workflow; the TOCTOU
was observed under QEMU/KVM.

Thanks,
Cheng Yongkang