netdev - Re: [PATCH net] net/sched: fix race between deactivation and dequeue for NOLOCK qdisc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20190915.193704.1404390645611004194.davem@davemloft.net>
Date:   Sun, 15 Sep 2019 19:37:04 +0100 (WEST)
From:   David Miller <davem@...emloft.net>
To:     pabeni@...hat.com
Cc:     netdev@...r.kernel.org, dcaratti@...hat.com, shuali@...hat.com
Subject: Re: [PATCH net] net/sched: fix race between deactivation and
 dequeue for NOLOCK qdisc

From: Paolo Abeni <pabeni@...hat.com>
Date: Thu, 12 Sep 2019 12:02:42 +0200

> The test implemented by some_qdisc_is_busy() is somewhat loosy for
> NOLOCK qdisc, as we may hit the following scenario:
> 
> CPU1						CPU2
> // in net_tx_action()
> clear_bit(__QDISC_STATE_SCHED...);
> 						// in some_qdisc_is_busy()
> 						val = (qdisc_is_running(q) ||
> 						       test_bit(__QDISC_STATE_SCHED,
> 								&q->state));
> 						// here val is 0 but...
> qdisc_run(q)
> // ... CPU1 is going to run the qdisc next
> 
> As a conseguence qdisc_run() in net_tx_action() can race with qdisc_reset()
> in dev_qdisc_reset(). Such race is not possible for !NOLOCK qdisc as
> both the above bit operations are under the root qdisc lock().
> 
> After commit 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue") 
> the race can cause use after free and/or null ptr dereference, but the root 
> cause is likely older.
> 
> This patch addresses the issue explicitly checking for deactivation under
> the seqlock for NOLOCK qdisc, so that the qdisc_run() in the critical
> scenario becomes a no-op.
> 
> Note that the enqueue() op can still execute concurrently with dev_qdisc_reset(),
> but that is safe due to the skb_array() locking, and we can't avoid that
> for NOLOCK qdiscs.
> 
> Fixes: 021a17ed796b ("pfifo_fast: drop unneeded additional lock on dequeue")
> Reported-by: Li Shuang <shuali@...hat.com>
> Reported-and-tested-by: Davide Caratti <dcaratti@...hat.com>
> Signed-off-by: Paolo Abeni <pabeni@...hat.com>

Applied and queued up for -stable, thanks.