netdev - Re: [PATCH] net: sched: fix potential null pointer deref

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: <tencent_4CF4EFF2144A820D7BBECA7D@qq.com>
Date:   Sat, 11 Jun 2022 13:00:48 +0200
From:   "Jianhao Xu" <jianhao_xu@...il.nju.edu.cn>
To:     "edumazet" <edumazet@...gle.com>
Cc:     "Daniel Borkmann" <daniel@...earbox.net>,
        "jhs" <jhs@...atatu.com>,
        "xiyou.wangcong" <xiyou.wangcong@...il.com>,
        "jiri" <jiri@...nulli.us>,
        "davem" <davem@...emloft.net>,
        "kuba" <kuba@...nel.org>,
        "pabeni" <pabeni@...hat.com>,
        "netdev" <netdev@...r.kernel.org>,
        "linux-kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] net: sched: fix potential null pointer deref

Thanks for your advice and sorry for the noise.

> All netdev devices have their dev->_tx allocated in netif_alloc_netdev_queues()
> 
> There is absolutely no way MQ qdisc could be attached to a device that
> has failed netif_alloc_netdev_queues() step.

I believe this makes sense. But I am still a bit confused, especially after we 
cross-checked the similar context of mq, mqprio, taprio. To be specific, we 
cross-checked whether `mq_class_ops`, `mqprio_class_ops`, and 
`taprio_class_ops` check the return value of  their respective version of 
`_queue_get` before dereferencing it. 

--------------- ----- --------- --------- 
class_ops      whether check the ret value of _queue_get
                     mq |  mqprio | taprio   
--------------- ----- --------- ---------  
select_queue    -     -         -         
graft               no    yes      yes       
leaf                 no    yes      yes       
find                yes    -         yes       
walk                -      -          -         
dump              no    no       no        
dump_stats     no    no       no     
--------------- ----- --------- --------- 

As shown in this table, `mq_leaf()` does not check the return value of 
`mq__queue_get()` before using the pointer, while `mqprio_leaf()` and 
`taprio_leaf()` do have such a NULL check. 

FYI, here is the code of `mqprio_leaf()` and we can find the NULL check.
```
//net/sched/sch_mqprio.c
static struct Qdisc *mqprio_leaf(struct Qdisc *sch, unsigned long cl)
{
	struct netdev_queue *dev_queue = mqprio_queue_get(sch, cl);

	if (!dev_queue)
		return NULL;

	return dev_queue->qdisc_sleeping;
}
```

That is also the situation of `mq_graft()`, `mqprio_graft()` and `taprio_graft()`. 
I am not sure whether it is reasonable to expect the class_ops of mq, mqprio, 
and taprio to be consistent in this way. If so, does it mean that it is possible 
that`mq_leaf()`and `mq_graft` may miss a check here, or mqprio, taprio have 
redundant checks?

Thanks again for your time. I apologize if my question is stupid.