netdev - Re: [PATCH v2] net: preserve IP control block during GSO segmentation

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:	Fri, 15 Jan 2016 00:22:25 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Florian Westphal <fw@...len.de>, David Miller <davem@...emloft.net>
Cc:	koct9i@...il.com, netdev@...r.kernel.org, dev@...nvswitch.org,
	cascardo@...hat.com, edumazet@...gle.com,
	linux-kernel@...r.kernel.org, pshelar@...ira.com,
	xiyou.wangcong@...il.com
Subject: Re: [PATCH v2] net: preserve IP control block during GSO segmentation

On 14.01.2016 00:36, Florian Westphal wrote:
> David Miller <davem@...emloft.net> wrote:
>> From: Konstantin Khlebnikov <koct9i@...il.com>
>> Date: Fri, 08 Jan 2016 15:21:46 +0300
>>
>>> Skb_gso_segment() uses skb control block during segmentation.
>>> This patch adds 32-bytes room for previous control block which
>>> will be copied into all resulting segments.
>>>
>>> This patch fixes kernel crash during fragmenting forwarded packets.
>>> Fragmentation requires valid IP CB in skb for clearing ip options.
>>> Also patch removes custom save/restore in ovs code, now it's redundant.
>>>
>>> Signed-off-by: Konstantin Khlebnikov <koct9i@...il.com>
>>> Link: http://lkml.kernel.org/r/CALYGNiP-0MZ-FExV2HutTvE9U-QQtkKSoE--KN=JQE5STYsjAA@mail.gmail.com
>>
>> If this works I definitely prefer this approach to the other patch
>> where the CB is copied back and forth.
>
> I quite frankly don't care and just like you to apply one or the other;
> use coin toss if needed :-}
>
> I would prefer to use a on-stack state since there is no need to
> use skb->cb (no queueing) but when I gave it a try it got out of hand
> rather quick :-/

Be careful with the encap counter within SKB_GSO_CB when trying to put 
it on the stack.

Bye,
Hannes