All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Zhengchao Shao <shaozhengchao@huawei.com>,
	netdev@vger.kernel.org, jhs@mojatatu.com,
	xiyou.wangcong@gmail.com, jiri@resnulli.us, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com
Cc: vladimir.oltean@nxp.com, weiyongjun1@huawei.com,
	yuehaibing@huawei.com, shaozhengchao@huawei.com
Subject: Re: [PATCH net,v2] net/sched: taprio: fix slab-out-of-bounds Read in taprio_dequeue_from_txq
Date: Thu, 08 Jun 2023 17:42:00 -0700	[thread overview]
Message-ID: <87zg59sbzb.fsf@intel.com> (raw)
In-Reply-To: <20230608062756.3626573-1-shaozhengchao@huawei.com>

Zhengchao Shao <shaozhengchao@huawei.com> writes:

> As shown in [1], out-of-bounds access occurs in two cases:
> 1)when the qdisc of the taprio type is used to replace the previously
> configured taprio, count and offset in tc_to_txq can be set to 0. In this
> case, the value of *txq in taprio_next_tc_txq() will increases
> continuously. When the number of accessed queues exceeds the number of
> queues on the device, out-of-bounds access occurs.

The more I think about this, the more I think the problem is somewhere
else, i.e. even enqueuing a packet from a TC with zero queues associated
with it doesn't make much sense.

The behaviors that make more sense to me are:
  1. reject configurations with '0@0' as invalid;
  2. drop the packets from TCs mapped to the "empty set" queue (0@0)
  during enqueue();

btw, (2) sounds better to me at this point.

Or is there another valid/sensible interpretation to '0@0' that I am missing? 

> 2)When packets are dequeued, taprio can be deleted. In this case, the tc
> rule of dev is cleared. The count and offset values are also set to 0. In
> this case, out-of-bounds access is also caused.

This looks like more like working around the issue than fixing it, and
it just happens, it's a coincidence, that both issues have the same
symptoms.

>
> Now the restriction on the queue number is added.
>
> [1] https://groups.google.com/g/syzkaller-bugs/c/_lYOKgkBVMg
> Fixes: 2f530df76c8c ("net/sched: taprio: give higher priority to higher TCs in software dequeue mode")
> Reported-by: syzbot+04afcb3d2c840447559a@syzkaller.appspotmail.com
> Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
> ---
> v2: set q->cur_txq[tc] to prevent out-of-bounds access during next dequeue
> ---
>  net/sched/sch_taprio.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
> index 3c4c2c334878..82983a6eb8f8 100644
> --- a/net/sched/sch_taprio.c
> +++ b/net/sched/sch_taprio.c
> @@ -799,6 +799,9 @@ static struct sk_buff *taprio_dequeue_tc_priority(struct Qdisc *sch,
>  
>  			taprio_next_tc_txq(dev, tc, &q->cur_txq[tc]);
>  
> +			if (q->cur_txq[tc] >= dev->num_tx_queues)
> +				q->cur_txq[tc] = first_txq;
> +
>  			if (skb)
>  				return skb;
>  		} while (q->cur_txq[tc] != first_txq);
> -- 
> 2.34.1
>
>

-- 
Vinicius

  parent reply	other threads:[~2023-06-09  0:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-08  6:27 [PATCH net,v2] net/sched: taprio: fix slab-out-of-bounds Read in taprio_dequeue_from_txq Zhengchao Shao
2023-06-08 14:37 ` Pedro Tammela
2023-06-09  0:42 ` Vinicius Costa Gomes [this message]
2023-06-09  1:57   ` shaozhengchao
2023-06-09  9:45     ` Vladimir Oltean
2023-06-12  0:49       ` shaozhengchao
2023-06-14 10:12         ` Vladimir Oltean
2023-06-09  9:50 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zg59sbzb.fsf@intel.com \
    --to=vinicius.gomes@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jhs@mojatatu.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shaozhengchao@huawei.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=weiyongjun1@huawei.com \
    --cc=xiyou.wangcong@gmail.com \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.