Date: Thu, 20 Jul 2017 15:16:11 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 220882] m_move_pkthdr leaves m_nextpkt 'dangling' Message-ID: <bug-220882-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220882 Bug ID: 220882 Summary: m_move_pkthdr leaves m_nextpkt 'dangling' Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: fodillemlinkarim@gmail.com 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 (ta= gs and flags) to the mbuf that was prepended. The function also does: to->m_pkthdr =3D from->m_pkthdr; This, for the case I am interested in, essentially leaves the 'from' mbuf w= ith 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 !=3D 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) =3D=3D 0) to->m_data =3D to->m_pktdat; to->m_pkthdr =3D from->m_pkthdr; /* especially tags */ SLIST_INIT(&from->m_pkthdr.tags); /* purge tags from src */ from->m_flags &=3D ~M_PKTHDR; + from->m_nextpkt =3D 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-220882-8>