IPv6 fragment reassembly regression following FreeBSD-SA-18:10.ip

Don Lewis truckman at FreeBSD.org
Mon Sep 24 20:54:04 UTC 2018


On 24 Sep, John W. O'Brien wrote:
> On 9/23/18 17:50, Don Lewis wrote:
>> On 23 Sep, John W. O'Brien wrote:
>>> I'd like to check my understanding and then ask a procedural question.
>>>
>>> FreeBSD-SA-18:10.ip [0], released on 08/14, was resolved by r337828 [1].
>>> That changeset, resulting in 11.1R-p13 and 11.2R-p2, included a patch to
>>> the way IPv6 fragment reassembly is handled [2] that was part of the
>>> merge to releng. In an ensuing thread [3] two weeks later, an
>>> implementation defect was identified, but not before that defect had
>>> shipped. The defect is now being tracked as a bug [4], as of 09/03 has
>>> been fixed in head and stable/11, and is registered as a blocker for 12.0.
>>>
>>> I believe this defect is the cause of a problem I detected recently
>>> where postfix would query BIND on ::1 for the DNSSEC-signed AAAA of an
>>> MX, and never receive a response. I'm a little puzzled that lo0 is
>>> affected in spite of having a 16k MTU, but the other signs are there:
>>> the symptoms appeared after upgrading from 11.2R-p1 to -p3, and I can
>>> perform that query successfully on UDPv4 or TCPv6.
>>>
>>> What I have been unable so far to determine is, will another 11.2R patch
>>> be forthcoming to resolve this regression, and if so, when? I can limp
>>> along without UDPv6 for a little while, but not until 11.3. The only
>>> clear alternative is to downgrade to -p1.
>>>
>>> [0] https://www.freebsd.org/security/advisories/FreeBSD-SA-18:10.ip.asc
>>> [1] https://svnweb.freebsd.org/changeset/base/337828
>>> [2] https://svnweb.freebsd.org/changeset/base/337776
>>> [3] https://lists.freebsd.org/pipermail/svn-src-head/2018-August/117514.html
>>> [4] https://bugs.freebsd.org/231045
>>>
>> 
>> It looks to me like r337776 is a further performance improvement, only
>> present in head, which also introduced a new bug that was fixed by
>> r338406. I don't know why r338406 was merged to stable/11 since r337776
>> was not.  Stable/11 only has the original fix (r337787 in head, r337803
>> in stable/11).
> 
> Hi Don,
> 
> I'm looking at this line of code [5] in releng/11.2. It looks to me like
> that's what r338406 fixed in head [6]. Am I being obtuse here?
> 
> [5]
> https://svnweb.freebsd.org/base/releng/11.2/sys/netinet6/frag6.c?annotate=337828#l219
> [6]
> https://svnweb.freebsd.org/base/head/sys/netinet6/frag6.c?r1=338406&r2=338405&pathrev=338406
> 

The change history here was complicated enough to confuse me.

I think you are correct that r338406 should be merged to 11.1 and 11.2
and new patches released.




More information about the freebsd-net mailing list