| Message ID | 20230801064318.34408-1-yuehaibing@huawei.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a59:918b:0:b0:3e4:2afc:c1 with SMTP id s11csp2491526vqg;
Tue, 1 Aug 2023 00:06:04 -0700 (PDT)
X-Google-Smtp-Source:
APBJJlGoTl0G3+GNpKHAF7jUtU7mLcAKWeoO40L6inpPQJaMIDYGueE3pi7SEMu8lmA/GXihrOgW
X-Received: by 2002:a17:906:1001:b0:99b:d440:bf0b with SMTP id
1-20020a170906100100b0099bd440bf0bmr1347439ejm.67.1690873564481;
Tue, 01 Aug 2023 00:06:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1690873564; cv=none;
d=google.com; s=arc-20160816;
b=xnNmLPVeAXcZTF0qfMSgMdQ7Yd9LwTR8xmnugQg9DJ0XwSSTWag1IJPq3kxGFryTqC
LqMBWKi1iiddZEYMBIasTeE3JznmhmaZkmmyXFaObc1UOrHUjMyVxv3cvWuC+qP2msWH
k3Zm6pQW/3WWP7bW3zxZzQfqd+SUIKNBMtnBXrUGDkRtvVRckYPvJ2a8VsqO2H+OL3Bw
soxHu6GsyfUGAfBz5+jLy/OXRwxOzMedjQLx7fCMKicb3VQ5tsyIKKpoPKEH195RxOTG
szIgDGSSDKzv8YHt2j8ypsNpzd0a3pyWoejluvIOSmKT7n8XBwAGzSCgay+DhYeStHUe
ksWQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from;
bh=tF6RpIT/Kgx5Pre6iVXl1i4Q+H2Tsk4938z2AwJm12o=;
fh=5H+D1F5PWhZJ9I3cHmKgb9Pe0NqVof9fpkQDUXhpMOU=;
b=mscWszDcLqmIkwPZzg0TV/7qDGCLbxQw31b5oM+pzLi78a4zcZTbMmfrG9FZv9acfo
oJkeE0JpjBcO2aVzIgeEtehcs7pQmhIFM1/zY17u7jytBGH8brRjJrstrjUmCEQ6mEdA
NioNvaaNFdGPPVdq4P3w9eeqwSzpxOu9oPDnQIlWT1bgUAlUVo+cxRp3JG9nIgQjDV6S
C1myC9ZB3sWXnLM9PsCjGF2FpgE7+UuA30hJxli8/phH2fcoH/fPIHFaraIovwWgPlSb
hORXR2uCwiRmX8o0ZJWXBJHuGO8BG5h7Ogpp7aMcrqZx6mn4c1QykqcnmIrtVp3s9xFr
kG5g==
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com
Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20])
by mx.google.com with ESMTP id
dv22-20020a170906b81600b00992bd86ece6si7862140ejb.725.2023.08.01.00.05.39;
Tue, 01 Aug 2023 00:06:04 -0700 (PDT)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
client-ip=2620:137:e000::1:20;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::1:20 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org;
dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S231846AbjHAGpp (ORCPT <rfc822;maxi.paulin@gmail.com>
+ 99 others); Tue, 1 Aug 2023 02:45:45 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55210 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S230477AbjHAGpn (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Tue, 1 Aug 2023 02:45:43 -0400
Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8EC698;
Mon, 31 Jul 2023 23:45:42 -0700 (PDT)
Received: from canpemm500007.china.huawei.com (unknown [172.30.72.54])
by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4RFQYn3Z8vzVjw6;
Tue, 1 Aug 2023 14:43:57 +0800 (CST)
Received: from localhost (10.174.179.215) by canpemm500007.china.huawei.com
(7.192.104.62) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Tue, 1 Aug
2023 14:45:40 +0800
From: Yue Haibing <yuehaibing@huawei.com>
To: <davem@davemloft.net>, <dsahern@kernel.org>, <edumazet@google.com>,
<kuba@kernel.org>, <pabeni@redhat.com>, <yoshfuji@linux-ipv6.org>
CC: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<simon.horman@corigine.com>, Yue Haibing <yuehaibing@huawei.com>
Subject: [PATCH v3] ip6mr: Fix skb_under_panic in ip6mr_cache_report()
Date: Tue, 1 Aug 2023 14:43:18 +0800
Message-ID: <20230801064318.34408-1-yuehaibing@huawei.com>
X-Mailer: git-send-email 2.10.2.windows.1
MIME-Version: 1.0
Content-Type: text/plain
X-Originating-IP: [10.174.179.215]
X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To
canpemm500007.china.huawei.com (7.192.104.62)
X-CFilter-Loop: Reflected
X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,
RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,
SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: 1772659987193186569
X-GMAIL-MSGID: 1773009438829388629
|
| Series |
[v3] ip6mr: Fix skb_under_panic in ip6mr_cache_report()
|
|
Commit Message
Yue Haibing
Aug. 1, 2023, 6:43 a.m. UTC
skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4
head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:192!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:skb_panic+0x152/0x1d0
Call Trace:
<TASK>
skb_push+0xc4/0xe0
ip6mr_cache_report+0xd69/0x19b0
reg_vif_xmit+0x406/0x690
dev_hard_start_xmit+0x17e/0x6e0
__dev_queue_xmit+0x2d6a/0x3d20
vlan_dev_hard_start_xmit+0x3ab/0x5c0
dev_hard_start_xmit+0x17e/0x6e0
__dev_queue_xmit+0x2d6a/0x3d20
neigh_connected_output+0x3ed/0x570
ip6_finish_output2+0x5b5/0x1950
ip6_finish_output+0x693/0x11c0
ip6_output+0x24b/0x880
NF_HOOK.constprop.0+0xfd/0x530
ndisc_send_skb+0x9db/0x1400
ndisc_send_rs+0x12a/0x6c0
addrconf_dad_completed+0x3c9/0xea0
addrconf_dad_work+0x849/0x1420
process_one_work+0xa22/0x16e0
worker_thread+0x679/0x10c0
ret_from_fork+0x28/0x60
ret_from_fork_asm+0x11/0x20
When setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit().
reg_vif_xmit()
ip6mr_cache_report()
skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4
And skb_push declared as:
void *skb_push(struct sk_buff *skb, unsigned int len);
skb->data -= len;
//0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850
skb->data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails.
Fixes: 14fb64e1f449 ("[IPV6] MROUTE: Support PIM-SM (SSM).")
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
---
v3: drop unnecessary nhoff change
v2: Use __skb_pull() and fix commit log.
---
net/ipv6/ip6mr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Tue, Aug 1, 2023 at 8:45 AM Yue Haibing <yuehaibing@huawei.com> wrote: > > skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4 > head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg > > When setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit(). > reg_vif_xmit() > ip6mr_cache_report() > skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4 > And skb_push declared as: > void *skb_push(struct sk_buff *skb, unsigned int len); > skb->data -= len; > //0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850 > skb->data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails. > > Fixes: 14fb64e1f449 ("[IPV6] MROUTE: Support PIM-SM (SSM).") > Signed-off-by: Yue Haibing <yuehaibing@huawei.com> > --- > v3: drop unnecessary nhoff change > v2: Use __skb_pull() and fix commit log. > --- > net/ipv6/ip6mr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c > index cc3d5ad17257..67a3b8f6e72b 100644 > --- a/net/ipv6/ip6mr.c > +++ b/net/ipv6/ip6mr.c > @@ -1073,7 +1073,7 @@ static int ip6mr_cache_report(const struct mr_table *mrt, struct sk_buff *pkt, > And all this only to mangle msg->im6_msgtype and > to set msg->im6_mbz to "mbz" :-) > */ > - skb_push(skb, -skb_network_offset(pkt)); > + __skb_pull(skb, skb_network_offset(pkt)); > > skb_push(skb, sizeof(*msg)); > skb_reset_transport_header(skb); Presumably this code has never been tested :/ Reviewed-by: Eric Dumazet <edumazet@google.com>
On Tue, 1 Aug 2023 09:51:29 +0200 Eric Dumazet wrote: > > - skb_push(skb, -skb_network_offset(pkt)); > > + __skb_pull(skb, skb_network_offset(pkt)); > > > > skb_push(skb, sizeof(*msg)); > > skb_reset_transport_header(skb); > > Presumably this code has never been tested :/ Could have been tested on 32bit, I wonder if there is more such bugs :S
On 8/1/23 2:11 PM, Jakub Kicinski wrote: > On Tue, 1 Aug 2023 09:51:29 +0200 Eric Dumazet wrote: >>> - skb_push(skb, -skb_network_offset(pkt)); >>> + __skb_pull(skb, skb_network_offset(pkt)); >>> >>> skb_push(skb, sizeof(*msg)); >>> skb_reset_transport_header(skb); >> >> Presumably this code has never been tested :/ > > Could have been tested on 32bit, I wonder if there is more such bugs :S that pattern shows up a few times: net/ipv4/ah4.c: skb_push(skb, -skb_network_offset(skb)); net/ipv4/esp4.c: skb_push(skb, -skb_network_offset(skb)); net/ipv4/esp4_offload.c: skb_push(skb, -skb_network_offset(skb)); net/ipv4/esp4_offload.c: skb_push(skb, -skb_network_offset(skb)); net/ipv4/xfrm4_tunnel.c: skb_push(skb, -skb_network_offset(skb)); net/ipv6/ah6.c: skb_push(skb, -skb_network_offset(skb)); net/ipv6/esp6.c: skb_push(skb, -skb_network_offset(skb)); net/ipv6/esp6_offload.c: skb_push(skb, -skb_network_offset(skb)); net/ipv6/esp6_offload.c: skb_push(skb, -skb_network_offset(skb)); net/ipv6/ip6mr.c: skb_push(skb, -skb_network_offset(pkt)); net/ipv6/mip6.c: skb_push(skb, -skb_network_offset(skb)); net/ipv6/mip6.c: skb_push(skb, -skb_network_offset(skb)); net/ipv6/xfrm6_tunnel.c: skb_push(skb, -skb_network_offset(skb)); net/xfrm/xfrm_ipcomp.c: skb_push(skb, -skb_network_offset(skb));
On 2023/8/2 8:52, David Ahern wrote: > On 8/1/23 2:11 PM, Jakub Kicinski wrote: >> On Tue, 1 Aug 2023 09:51:29 +0200 Eric Dumazet wrote: >>>> - skb_push(skb, -skb_network_offset(pkt)); >>>> + __skb_pull(skb, skb_network_offset(pkt)); >>>> >>>> skb_push(skb, sizeof(*msg)); >>>> skb_reset_transport_header(skb); >>> >>> Presumably this code has never been tested :/ >> >> Could have been tested on 32bit, I wonder if there is more such bugs :S > > that pattern shows up a few times: Ok, I will test and fix these if any. > > net/ipv4/ah4.c: skb_push(skb, -skb_network_offset(skb)); > net/ipv4/esp4.c: skb_push(skb, -skb_network_offset(skb)); > net/ipv4/esp4_offload.c: skb_push(skb, -skb_network_offset(skb)); > net/ipv4/esp4_offload.c: skb_push(skb, -skb_network_offset(skb)); > net/ipv4/xfrm4_tunnel.c: skb_push(skb, -skb_network_offset(skb)); > net/ipv6/ah6.c: skb_push(skb, -skb_network_offset(skb)); > net/ipv6/esp6.c: skb_push(skb, -skb_network_offset(skb)); > net/ipv6/esp6_offload.c: skb_push(skb, -skb_network_offset(skb)); > net/ipv6/esp6_offload.c: skb_push(skb, -skb_network_offset(skb)); > net/ipv6/ip6mr.c: skb_push(skb, -skb_network_offset(pkt)); > net/ipv6/mip6.c: skb_push(skb, -skb_network_offset(skb)); > net/ipv6/mip6.c: skb_push(skb, -skb_network_offset(skb)); > net/ipv6/xfrm6_tunnel.c: skb_push(skb, -skb_network_offset(skb)); > net/xfrm/xfrm_ipcomp.c: skb_push(skb, -skb_network_offset(skb)); > . >
On Wed, 2 Aug 2023 09:28:31 +0800 YueHaibing wrote: > > that pattern shows up a few times: > > Ok, I will test and fix these if any. Thanks, we may also want to add a DEBUG_NET_WARN_ON_ONCE(len > INT_MAX) in skb_push() but perhaps that's an overkill. Most of those cases are probably legit (skb_.*_offset() can well be negative if headers were already pulled).
On 8/1/23 8:10 PM, Jakub Kicinski wrote: > On Wed, 2 Aug 2023 09:28:31 +0800 YueHaibing wrote: >>> that pattern shows up a few times: >> >> Ok, I will test and fix these if any. > > Thanks, we may also want to add a > DEBUG_NET_WARN_ON_ONCE(len > INT_MAX) > in skb_push() but perhaps that's an overkill. > Most of those cases are probably legit (skb_.*_offset() > can well be negative if headers were already pulled). Yea, a lot of those could be legit, so it would be best to have a test case that shows it can be triggered and then any patch fixes it.
Hello: This patch was applied to netdev/net.git (main) by David S. Miller <davem@davemloft.net>: On Tue, 1 Aug 2023 14:43:18 +0800 you wrote: > skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4 > head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg > ------------[ cut here ]------------ > kernel BUG at net/core/skbuff.c:192! > invalid opcode: 0000 [#1] PREEMPT SMP KASAN > CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 > Workqueue: ipv6_addrconf addrconf_dad_work > RIP: 0010:skb_panic+0x152/0x1d0 > Call Trace: > <TASK> > skb_push+0xc4/0xe0 > ip6mr_cache_report+0xd69/0x19b0 > reg_vif_xmit+0x406/0x690 > dev_hard_start_xmit+0x17e/0x6e0 > __dev_queue_xmit+0x2d6a/0x3d20 > vlan_dev_hard_start_xmit+0x3ab/0x5c0 > dev_hard_start_xmit+0x17e/0x6e0 > __dev_queue_xmit+0x2d6a/0x3d20 > neigh_connected_output+0x3ed/0x570 > ip6_finish_output2+0x5b5/0x1950 > ip6_finish_output+0x693/0x11c0 > ip6_output+0x24b/0x880 > NF_HOOK.constprop.0+0xfd/0x530 > ndisc_send_skb+0x9db/0x1400 > ndisc_send_rs+0x12a/0x6c0 > addrconf_dad_completed+0x3c9/0xea0 > addrconf_dad_work+0x849/0x1420 > process_one_work+0xa22/0x16e0 > worker_thread+0x679/0x10c0 > ret_from_fork+0x28/0x60 > ret_from_fork_asm+0x11/0x20 > > [...] Here is the summary with links: - [v3] ip6mr: Fix skb_under_panic in ip6mr_cache_report() https://git.kernel.org/netdev/net/c/30e0191b16e8 You are awesome, thank you!
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c index cc3d5ad17257..67a3b8f6e72b 100644 --- a/net/ipv6/ip6mr.c +++ b/net/ipv6/ip6mr.c @@ -1073,7 +1073,7 @@ static int ip6mr_cache_report(const struct mr_table *mrt, struct sk_buff *pkt, And all this only to mangle msg->im6_msgtype and to set msg->im6_mbz to "mbz" :-) */ - skb_push(skb, -skb_network_offset(pkt)); + __skb_pull(skb, skb_network_offset(pkt)); skb_push(skb, sizeof(*msg)); skb_reset_transport_header(skb);