From patchwork Wed Jan 6 21:05:32 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thadeu Lima de Souza Cascardo X-Patchwork-Id: 564097 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 6B7C51402C9 for ; Thu, 7 Jan 2016 08:06:31 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752335AbcAFVFl (ORCPT ); Wed, 6 Jan 2016 16:05:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54510 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752040AbcAFVFk (ORCPT ); Wed, 6 Jan 2016 16:05:40 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id EC191A0E74; Wed, 6 Jan 2016 21:05:37 +0000 (UTC) Received: from indiana.gru.redhat.com (ovpn-113-48.phx2.redhat.com [10.3.113.48]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u06L5Xdu029548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Jan 2016 16:05:36 -0500 Date: Wed, 6 Jan 2016 19:05:32 -0200 From: Thadeu Lima de Souza Cascardo To: Konstantin Khlebnikov Cc: Cong Wang , Linux Kernel Network Developers , David Miller , Eric Dumazet , Linux Kernel Mailing List Subject: Re: [BUG] skb corruption and kernel panic at forwarding with fragmentation Message-ID: <20160106210532.GE27290@indiana.gru.redhat.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Jan 06, 2016 at 11:11:41PM +0300, Konstantin Khlebnikov wrote: > On Wed, Jan 6, 2016 at 10:59 PM, Cong Wang wrote: > > On Wed, Jan 6, 2016 at 11:15 AM, Konstantin Khlebnikov wrote: > >> Looks like this happens because ip_options_fragment() relies on > >> correct ip options length in ip control block in skb. But in > >> ip_finish_output_gso() control block in segments is reused by > >> skb_gso_segment(). following ip_fragment() sees some garbage. > >> > >> In my case there was no ip options but length becomes non-zero and > >> ip_options_fragment() picked some bytes from payload and decides to > >> fill huge range with IPOPT_NOOP (1). One of that ones flipped nr_frags > >> in skb_shared_info at the end of data =) > >> > > > > Hmm, it looks like SKB_GSO_CB should be cleared after skb_gso_segment() > > since all the gso information should be saved in shared_info after it finishes. > > > > Does a memset(0) on SKB_GSO_CB after skb_gso_segment() work as well? > > This will break present logic around ip_options_fragment() - it clears > options from > second and following fragments. With zeroed cb it will do nothing. > > ip_options_fragment() can get required information directly from ip header but > it also resets fields in IPCB -- probably it should stay valid here > and somebody else will use it later. > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html I have hit this as well, this fixes it for me on an older kernel. Can you try it on latest kernel? --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index d8a1745..f44bc91 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -216,6 +216,7 @@ static int ip_finish_output_gso(struct sk_buff *skb) netdev_features_t features; struct sk_buff *segs; int ret = 0; + struct inet_skb_parm ipcb; if (skb_gso_network_seglen(skb) <= ip_skb_dst_mtu(skb)) return ip_finish_output2(skb); @@ -227,6 +228,10 @@ static int ip_finish_output_gso(struct sk_buff *skb) * 2) skb arrived via virtio-net, we thus get TSO/GSO skbs directly * from host network stack. */ + /* We need to save IPCB here because skb_gso_segment will use + * SKB_GSO_CB. + */ + ipcb = *IPCB(skb); features = netif_skb_features(skb); segs = skb_gso_segment(skb, features & ~NETIF_F_GSO_MASK); if (IS_ERR_OR_NULL(segs)) { @@ -241,6 +246,7 @@ static int ip_finish_output_gso(struct sk_buff *skb) int err; segs->next = NULL; + *IPCB(segs) = ipcb; err = ip_fragment(segs, ip_finish_output2); if (err && ret == 0)