netdev - Re[3]: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header handling in IPVS

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: <Pine.GSO.4.63.1208271401140.17922@stinky-local.trash.net>
Date:	Mon, 27 Aug 2012 14:02:41 +0200 (MEST)
From:	Patrick McHardy <kaber@...sh.net>
To:	Hans Schillstrom <hans@...illstrom.com>
cc:	Jesper Dangaard Brouer <brouer@...hat.com>, netdev@...r.kernel.org,
	lvs-devel@...r.kernel.org, Julian Anastasov <ja@....bg>,
	Simon Horman <horms@...ge.net.au>,
	Wensong Zhang <wensong@...ux-vs.org>,
	netfilter-devel@...r.kernel.org
Subject: Re[3]: [PATCH 2/3] ipvs: Fix faulty IPv6 extension header  handling
 in IPVS

On Mon, 27 Aug 2012, Hans Schillstrom wrote:

>>>>
>>>> On Mon, 20 Aug 2012, Jesper Dangaard Brouer wrote:
>>>>
>>>>> Based on patch from: Hans Schillstrom
>>>>>
>>>>> IPv6 headers must be processed in order of appearance,
>>>>> neither can it be assumed that Upper layer headers is first.
>>>>> If anything else than L4 is the first header IPVS will throw it.
>>>>>
>>>>> IPVS will write SNAT & DNAT modifications at a fixed pos which
>>>>> will corrupt the message. Proper header position must be found
>>>>> before writing modifying packet.
>>>>>
>>>>> This patch contains a lot of API changes.  This is done, to avoid
>>>>> the costly scan of finding the IPv6 headers, via ipv6_find_hdr().
>>>>> Finding the IPv6 headers is done as early as possible, and passed
>>>>> on as a pointer "struct ip_vs_iphdr *" to the affected functions.
>>>>
>>>> How about we change netfilter to set up the skb's transport header
>>>> at an early time so we can avoid all (most of) these header scans
>>>> in netfilter?
>>>
>>> I think that would be great, maybe it should be global i.e. not only a netfilter issue.
>>
>> I think in most other cases the headers are supposed to be processed
>> sequentially. One problem though - to be useful for netfilter/IPVS
>> we'd also need to store the transport layer protocol somewhere.
>
> I guess that's the problem, adding it to the skb will not be popular ....
> Right now I don't have a good solution, maybe a more generic netfilter ptr in the skb ...

I guess inet6_skb_parm will be at least slightly more popular than
adding it to the skb itself. The netfilter pointers are all used for
optional things, so we can't really add it to any of those.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html