From patchwork Wed Jun 28 04:53:54 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gao Feng X-Patchwork-Id: 781452 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3wy9SR6mVjz9s4q for ; Wed, 28 Jun 2017 14:54:31 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753610AbdF1EyY (ORCPT ); Wed, 28 Jun 2017 00:54:24 -0400 Received: from m181-177.vip.163.com ([123.58.177.181]:58994 "EHLO m181-177.vip.163.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751616AbdF1EyW (ORCPT ); Wed, 28 Jun 2017 00:54:22 -0400 Received: from ikuai8.com (unknown [114.242.17.234]) by smtp2 (Coremail) with SMTP id oWZ4CgC35KhjNlNZFKEoDg--.14965S2; Wed, 28 Jun 2017 12:54:04 +0800 (CST) From: gfree.wind@vip.163.com To: jhs@mojatatu.com, xiyou.wangcong@gmail.com, jiri@resnulli.us, davem@davemloft.net, netdev@vger.kernel.org Cc: Gao Feng Subject: [PATCH net v2] net: sched: Fix one possible panic when no destroy callback Date: Wed, 28 Jun 2017 12:53:54 +0800 Message-Id: <1498625634-115351-1-git-send-email-gfree.wind@vip.163.com> X-Mailer: git-send-email 1.9.1 X-CM-TRANSID: oWZ4CgC35KhjNlNZFKEoDg--.14965S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxJr45Cry5ZF4UKF43Zr4rGrg_yoW8GF47p3 ZF9anrKry8Cr1fC3Z3Ar15GryrKFs3GrW5WrnYg34Yy3Z3Ww15tF9FgrWakFy5CF45Aan8 tF4av343Zr18uFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jUsqXUUUUU= X-Originating-IP: [114.242.17.234] X-CM-SenderInfo: 5jiuvvgozl0vg6yl1hqrwthudrp/1tbiIgwFs1V4A-ST4QAAsw Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Gao Feng When qdisc fail to init, qdisc_create would invoke the destroy callback to cleanup. But there is no check if the callback exists really. So it would cause the panic if there is no real destroy callback like the qdisc codel, fq, and so on. Take codel as an example following: When a malicious user constructs one invalid netlink msg, it would cause codel_init->codel_change->nla_parse_nested failed. Then kernel would invoke the destroy callback directly but qdisc codel doesn't define one. It causes one panic as a result. Now add one the check for destroy to avoid the possible panic. Fixes: 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation") Signed-off-by: Gao Feng Acked-by: Eric Dumazet --- v2: Add the Fixes and an example in changelog, Per Cong Wang & Eric v1: initial version net/sched/sch_api.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c index e88342f..cfdbfa1 100644 --- a/net/sched/sch_api.c +++ b/net/sched/sch_api.c @@ -1019,7 +1019,8 @@ static struct Qdisc *qdisc_create(struct net_device *dev, return sch; } /* ops->init() failed, we call ->destroy() like qdisc_create_dflt() */ - ops->destroy(sch); + if (ops->destroy) + ops->destroy(sch); err_out3: dev_put(dev); kfree((char *) sch - sch->padded);