netdev - Re: [PATCH net] ipv6: un-do: defrag: drop non-last frags smaller than min mtu

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 8 Apr 2019 07:54:18 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     Captain Wiggum <captwiggum@...il.com>
Cc:     Sasha Levin <sashal@...nel.org>,
        David Miller <davem@...emloft.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Florian Westphal <fw@...len.de>,
        Peter Oskolkov <posk@...gle.com>,
        netdev <netdev@...r.kernel.org>, stable@...r.kernel.org
Subject: Re: [PATCH net] ipv6: un-do: defrag: drop non-last frags smaller than
 min mtu

On Mon, Apr 8, 2019 at 7:50 AM Captain Wiggum <captwiggum@...il.com> wrote:
>
> Hi Sasha,
>
> This patch cannot be applied to upstream, the code is significantly different.
> Therefore, this un-do patch would not be seen in the upstream git log.
> It was solved there by coding a better solution, not by the un-do patch.
>
> Please consider this:
> Upstream passes the TAHI IPv6 protocol tests. All the LTS kernels do NOT.
> This is the patch that causes the failure in 4.9, 4.14, 4.19 LTS kernels.
>
> And this patch has been in place with 4.9.134, a long time.
> It is not right that "Linux" can not pass the IPv6 protocol test.
> My executive are asking me why "Linux" is not fit for IPv6 deployments.
>

Security comes first. Your managers should be able to understand this
very simple fact.

Please provide a proper list of patches to backport instead of complaining.

Upstream has been fixed, this is now a matter of helping stable teams,
instead of ranting.

Thanks.


> --John Masinter
>
> On Sat, Apr 6, 2019 at 8:15 AM Sasha Levin <sashal@...nel.org> wrote:
> >
> > On Fri, Apr 05, 2019 at 10:22:51AM -0600, Captain Wiggum wrote:
> > >I know it affects 4.9, 4.14, 4.19.
> > >I have not tested the older LTS kernels.
> > >But any LTS kernel that previously received this commit is affected:
> > >...  commit a8444b1ccb20339774af58e40ad42296074fb484
> > >...  ipv6: defrag: drop non-last frags smaller than min mtu
> > >
> > >
> > >
> > >On Thu, Apr 4, 2019 at 10:50 PM Greg Kroah-Hartman
> > ><gregkh@...uxfoundation.org> wrote:
> > >>
> > >> On Thu, Apr 04, 2019 at 06:18:30PM -0600, Captain Wiggum wrote:
> > >> > Hi Greg,
> > >> >
> > >> > A previous bad patch breaks 18 test cases for IPv6 fragment headers.
> > >> > This has already been un-done in upstream, but not in any of the LTS.
> > >> > However two upstream patches are first needed to cover a DoS vulnerability.
> > >> >
> > >> > For background, there are two mail threads in [netdev] on this subject:
> > >> > 1) Subject: TAHI testing fails for IPv6 Fragments in Kernel 4.9 (from
> > >> > captwiggum)
> > >> > 2) Subject: Please merge IPv6 fix for drop fragment smaller than MTU
> > >> > (from captwiggum)
> > >> >
> > >> > Two patches from upstream needed first to cover the DoS:
> > >> >
> > >> > commit d4289fcc9b16b89619ee1c54f829e05e56de8b9a
> > >> > net: IP6 defrag: use rbtrees for IPv6 defrag
> > >> >
> > >> > commit 997dd96471641e147cb2c33ad54284000d0f5e35
> > >> > net: IP6 defrag: use rbtrees in nf_conntrack_reasm.c
> > >> >
> > >> > One undo-patch to fix the IPv6 fragment headers:
> > >> >
> > >> > ipv6: defrag: drop non-last frags smaller than min mtu
> > >> > UN-DO: commit a8444b1ccb20339774af58e40ad42296074fb484
> > >>
> > >> For what kernel version(s) do these patches need to be applied?
> > >>
> > >> thanks,
> > >>
> > >> greg k-h
> >
> > I see that 0ed4229b08c1 ("ipv6: defrag: drop non-last frags smaller than
> > min mtu") wasn't reverted upstream, why is a revert needed on the stable
> > trees?
> >
> > David, could you ack these requests?
> >
> > --
> > Thanks,
> > Sasha