linux-kernel - 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]

Message-ID: <20160113233628.GA10507@breakpoint.cc>
Date:	Thu, 14 Jan 2016 00:36:28 +0100
From:	Florian Westphal <fw@...len.de>
To:	David Miller <davem@...emloft.net>
Cc:	koct9i@...il.com, netdev@...r.kernel.org, dev@...nvswitch.org,
	cascardo@...hat.com, edumazet@...gle.com, fw@...len.de,
	linux-kernel@...r.kernel.org, pshelar@...ira.com,
	xiyou.wangcong@...il.com
Subject: Re: [PATCH v2] net: preserve IP control block during GSO segmentation

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 :-/

Anyway Konstantins approach is safe since we only need this in
ovs/ip forward + nfnetlink_queue cases and in all of these there is
enough room at the cb end (for now at least).