netdev - Re: [PATCH v2 0/4] Check size of packets before sending

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 for Android: free password hash cracker in your pocket

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

Message-ID: <87h8r5s63p.fsf@linkitivity.dja.id.au>
Date:   Mon, 29 Jan 2018 14:20:58 +1100
From:   Daniel Axtens <dja@...ens.net>
To:     Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Cc:     Jason Wang <jasowang@...hat.com>, Pravin Shelar <pshelar@....org>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Manish.Chopra@...ium.com, dev@...nvswitch.org
Subject: Re: [PATCH v2 0/4] Check size of packets before sending

Eric Dumazet <eric.dumazet@...il.com> writes:

> On Fri, 2018-01-26 at 00:44 +1100, Daniel Axtens wrote:
>> Hi Eric,
>> 
>> > May I ask which tree are you targeting ?
>> > 
>> > ( Documentation/networking/netdev-FAQ.txt )
>> 
>> I have been targeting net-next, but I haven't pulled for about two
>> weeks. I will rebase and if there are conflicts I will resend early next
>> week.
>> 
>> > Anything touching GSO is very risky and should target net-next,
>> > especially considering 4.15 is released this week end.
>> > 
>> > Are we really willing to backport this intrusive series in stable
>> > trees, or do we have a smaller fix for bnx2x ?
>> 
>> I do actually have a smaller fix for bnx2x, although it would need more work:
>> https://patchwork.ozlabs.org/patch/859410/
>> 
>> It leaves open the possibility of too-large packets causing issues on
>> other drivers. DaveM wasn't a fan: https://patchwork.ozlabs.org/patch/859410/#1839429
>
> Yes, I know he prefers a generic solution, but I am pragmatic here.
> Old kernels are very far from current GSO stack in net-next.
>
> Backporting all the dependencies is going to be very boring/risky.

OK, so how about:

 - first, a series that introduces skb_gso_validate_mac_len and uses it
   in bnx2x. This should be backportable without difficulty.

 - then, a series that wires skb_gso_validate_mac_len into the core -
   validate_xmit_skb for instance, and reverts the bnx2x fix. This would
   not need to be backported.

If that's an approach we can agree on, I am ready to send it when
net-next opens again.

Regards,
Daniel