Re: [PATCH net v2 1/2] net/sched: sch_teql: fix slaves_lock IRQ deadlock

[Simon Horman <horms@kernel.org>]

On Sat, Oct 24, 2026 at 10:34:14AM -0400, Jamal Hadi Salim wrote:
> This is a followup of commit e5b811fe7931 ("net/sched: sch_teql:
> Introduce slaves_lock to avoid race condition and UAF") as reported by
> Sashiko.
> 
> The issue: master->slaves_lock serializes the master's ring of slave
> qdiscs.  The control paths -- teql_dequeue(), teql_destroy() and
> teql_qdisc_init() -- take it with spin_lock_bh(), while
> teql_master_xmit() (the master's ndo_start_xmit) takes it with plain
> spin_lock().
> 
> netpoll_send_skb() wraps the transmit in local_irq_save(), and
> __netpoll_send_skb() asserts lockdep_assert_irqs_disabled(), so
> teql_master_xmit() reached from netconsole always acquires slaves_lock
> with hard IRQs disabled.  On PREEMPT_RT spinlock_t is an rtmutex, and
> Documentation/locking/locktypes.rst names
> 
> 	local_irq_disable();
> 	spin_lock(&lock);
> 
> as a sequence that breaks there because the rtmutex requires a fully
> preemptible context.  This is reachable without any panic: the nbcon
> printer thread calls netconsole's write_thread() callback on every
> message.  The usual remedy -- folding the IRQ disable into the lock with
> spin_lock_irqsave() -- is unavailable because the local_irq_save() is
> netpoll's, not ours.
> 
> On non-RT the same asymmetry leaves slaves_lock acquirable with hard IRQs
> disabled on one path and held with hard IRQs enabled on another.  That is
> only exploitable during the panic console flush (netconsole is
> CON_NBCON_ATOMIC_UNSAFE, so console_is_usable() admits its write_atomic()
> only from nbcon_atomic_flush_unsafe(), which panic() alone calls), and
> even then an IRQ-saving lock does not help if the holder oopsed inside the
> section or was stopped by panic_other_cpus_shutdown().  So the non-RT half
> is hardening; the PREEMPT_RT half is the bug.
> 
> The Fix: take slaves_lock as a raw spinlock with IRQs saved at every
> site.  Since skb_queue_purge() takes the queue's spinlock_t and may not
> nest inside a raw lock on PREEMPT_RT, move its call in teql_destroy()
> outside the raw section; dat->q is the dying qdisc's own queue and was
> never serialized by slaves_lock, so the move is behaviour-neutral.
> 
> The new critical sections contain only RCU pointer assignments and
> netdev_get_tx_queue(); skb_queue_purge(), netif_wake_queue() and
> dev_reset_queue() are all outside them.  teql_destroy()'s ring walk is
> O(slaves), two pointer loads and a compare per iteration, so even a large
> ring is microseconds with IRQs off.  Keeping the purge conditional rather
> than dropping it outright is the conservative call for a backport.
> 
> Some context: commit 6301f6a34ed8 ("net/sched: sch_teql: move
> rcu_read_lock()/spin_lock() from _bh variants") hardened the parent
> fix; together they addressed the master->slaves resurrection
> use-after-free and the xmit-side BH warning but left the reverse
> direction -- a hard IRQ re-entering xmit while a control path holds the
> lock -- unaddressed.
> 
> Conditions to recreate the bug:
> - CONFIG_PREEMPT_RT, CONFIG_NET_SCH_TEQL, CONFIG_DUMMY and
>   CONFIG_NETCONSOLE.
> - Run `ip link add dev teqlslave0 type dummy`, bring teqlslave0 up, attach
>   it with `tc qdisc add dev teqlslave0 root teql0`, and bring teql0 up.
> - Configure a netconsole target on teql0 with explicit local and remote
>   IP addresses and a remote MAC address, then emit a console message.
>   The nbcon printer thread reaches teql_master_xmit() with hard IRQs
>   disabled by netpoll; taking slaves_lock as a spinlock_t is invalid on
>   PREEMPT_RT. No panic or concurrent qdisc change is required.
> - Reachable by an admin with CAP_NET_ADMIN; teql devices exist only in the
>   initial netns (no per-netns ops), so a user namespace does not suffice.
> 
> Fixes: e5b811fe7931 ("net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF")
> Reported-by: Sashiko (gemini) <sashiko-bot@kernel.org>
> Closes: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260630150922.238714-1-jhs%40mojatatu.com
> Link: https://lore.kernel.org/netdev/20260630150922.238714-1-jhs@mojatatu.com/
> Cc: stable@vger.kernel.org
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>

Reviewed-by: Simon Horman <horms@kernel.org>