netdev - Re: [PATCH net v1] taprio: Fix sending packets without dequeueing them

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: <20200312.112634.1418678520292902314.davem@davemloft.net>
Date:   Thu, 12 Mar 2020 11:26:34 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     vinicius.gomes@...el.com
Cc:     netdev@...r.kernel.org, jhs@...atatu.com, xiyou.wangcong@...il.com,
        jiri@...nulli.us, aaron.f.brown@...el.com, sasha.neftin@...el.com,
        michael.schmidt@....uni-siegen.de
Subject: Re: [PATCH net v1] taprio: Fix sending packets without dequeueing
 them

From: Vinicius Costa Gomes <vinicius.gomes@...el.com>
Date: Mon,  9 Mar 2020 10:39:53 -0700

> There was a bug that was causing packets to be sent to the driver
> without first calling dequeue() on the "child" qdisc. And the KASAN
> report below shows that sending a packet without calling dequeue()
> leads to bad results.
> 
> The problem is that when checking the last qdisc "child" we do not set
> the returned skb to NULL, which can cause it to be sent to the driver,
> and so after the skb is sent, it may be freed, and in some situations a
> reference to it may still be in the child qdisc, because it was never
> dequeued.
> 
> The crash log looks like this:
 ...
> Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
> Reported-by: Michael Schmidt <michael.schmidt@....uni-siegen.de>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@...el.com>

Applied and queued up for -stable, thanks.