From owner-freebsd-net@freebsd.org  Fri Jun 30 15:51:44 2017
Return-Path: <owner-freebsd-net@freebsd.org>
Delivered-To: freebsd-net@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E5F1D949DF
 for <freebsd-net@mailman.ysv.freebsd.org>;
 Fri, 30 Jun 2017 15:51:44 +0000 (UTC)
 (envelope-from kfodil-lemelin@xiplink.com)
Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com
 [173.203.187.73])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 7D31772F3F
 for <freebsd-net@freebsd.org>; Fri, 30 Jun 2017 15:51:44 +0000 (UTC)
 (envelope-from kfodil-lemelin@xiplink.com)
Received: from smtp34.relay.iad3a.emailsrvr.com (localhost [127.0.0.1])
 by smtp34.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5E35B24C86;
 Fri, 30 Jun 2017 11:42:06 -0400 (EDT)
X-Auth-ID: kfodil-lemelin@xiplink.com
Received: by smtp34.relay.iad3a.emailsrvr.com (Authenticated sender:
 kfodil-lemelin-AT-xiplink.com) with ESMTPSA id 3F67C24D8A; 
 Fri, 30 Jun 2017 11:42:06 -0400 (EDT)
X-Sender-Id: kfodil-lemelin@xiplink.com
Received: from [10.10.1.167] ([UNAVAILABLE]. [192.252.130.194])
 (using TLSv1.2 with cipher DHE-RSA-AES128-SHA)
 by 0.0.0.0:465 (trex/5.7.12); Fri, 30 Jun 2017 11:42:06 -0400
To: FreeBSD Net <freebsd-net@freebsd.org>
From: Karim Fodil-Lemelin <kfodil-lemelin@xiplink.com>
Subject: m_move_pkthdr leaves m_nextpkt 'dangling'
Message-ID: <59567148.1020902@xiplink.com>
Date: Fri, 30 Jun 2017 11:42:00 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>,
 <mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jun 2017 15:51:44 -0000

Hi,

As many of you know, when dealing with IP fragments the kernel will 
build a list of packets (fragments) chained together through the 
m_nextpkt pointer. This is all good until someone tries to do a 
M_PREPEND on one of the packet in the chain and the M_PREPEND has to 
create an extra mbuf to prepend at the beginning of the chain.

When doing so m_move_pkthdr is called to copy the current PKTHDR fields 
(tags and flags) to the mbuf that was prepended. The function also does:

to->m_pkthdr = from->m_pkthdr;

This, for the case I am interested in, essentially leaves the 'from' 
mbuf with a dangling pointer m_nextpkt pointing to the next fragment. 
While this is mostly harmless because only mbufs of pkthdr types are 
supposed to have m_nextpkt it triggers some panics when running with 
INVARIANTS in NetGraph (see ng_base.c :: CHECK_DATA_MBUF(m)):

...
                         if (n->m_nextpkt != NULL)                       \
                                 panic("%s: m_nextpkt", __func__);       \
                 }
...

So I would like to propose the following patch:

@@ -442,10 +442,11 @@ m_move_pkthdr(struct mbuf *to, struct mbuf *from)
         if ((to->m_flags & M_EXT) == 0)
                 to->m_data = to->m_pktdat;
         to->m_pkthdr = from->m_pkthdr;          /* especially tags */
         SLIST_INIT(&from->m_pkthdr.tags);       /* purge tags from src */
         from->m_flags &= ~M_PKTHDR;
+       from->m_nextpkt = NULL;
  }

It will reset the m_nextpkt so we don't have two mbufs pointing to the 
same next packet. This is fairly harmless and solves a problem for us 
here at XipLink.

Best regards,

Karim.