netdev - Re: ipv6 UNH-IOL Intact test cases failure on kernel 4.4.178

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20191011091148.GB1124173@kroah.com>
Date:   Fri, 11 Oct 2019 11:11:48 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Lei Chen <chenl.lei@...il.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: ipv6 UNH-IOL Intact test cases failure on kernel 4.4.178

On Fri, Oct 11, 2019 at 05:00:32PM +0800, Lei Chen wrote:
> Hi David,
> Thanks in advance for reading my message.
> 
> We are running UNH-IOL test on our product which is based on kernel
> 4.4.178. The INTACT test cases failed on ipv6 verification. The same test
> cases just got pass on 4.4.153. (Sorry, the INTACT suite does not look to
> be open sourced. Hence I don't really know what the cases were indeed
> doing.)
> 
> Our verification engineer also mentioned: "The pattern of failures look
> eerily similar to a regression we recently discovered in SLES 12. I.e.,
> Failures related to “Parameter Problems”, as well as “Fragmentation“." We
> have tried to back out the defragment related patch:
> 
> commit 5f2d68b6b5a439c3223d8fa6ba20736f91fc58d8
> Author: Florian Westphal
> Date:   Wed Oct 10 12:30:10 2018 -0700
> 
>     ipv6: defrag: drop non-last frags smaller than min mtu
> 
>     commit 0ed4229b08c13c84a3c301a08defdc9e7f4467e6 upstream.
> 
>     don't bother with pathological cases, they only waste cycles.
>     IPv6 requires a minimum MTU of 1280 so we should never see fragments
>     smaller than this (except last frag).
> 
> 
> But it doesn't help. Could you please shed a light on which patch between
> 4.4.153 and 4.4.178 could have caused such a regression? Thanks again.

As you can run the test, why can't you run 'git bisect' to find the
offending patch?

thanks,

greg k-h