netdev - Re: [patch net/stable] ipv6/exthdrs: accept tlv which includes only padding

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: <alpine.LNX.2.00.1309071819310.24145@heraclitus>
Date:	Sat, 7 Sep 2013 18:46:12 +0200 (CEST)
From:	Eldad Zack <eldad@...refinery.com>
To:	Jiri Pirko <jiri@...nulli.us>
cc:	netdev@...r.kernel.org, davem@...emloft.net, kuznet@....inr.ac.ru,
	jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net
Subject: Re: [patch net/stable] ipv6/exthdrs: accept tlv which includes only
 padding



On Sat, 7 Sep 2013, Jiri Pirko wrote:

> Sat, Sep 07, 2013 at 02:31:36PM CEST, eldad@...refinery.com wrote:
> >
> >Hi Jiri,
> >
> >On Fri, 6 Sep 2013, Jiri Pirko wrote:
> >
> >> In rfc4942 and rfc2460 I cannot find anything which would implicate to
> >> drop packets which have only padding in tlv.
> >
> >NAK from my side.
> >Please read RFC4942 2.1.9.5 "Misuse of Pad1 and PadN Options".
> 
> I did.
> 
> >
> >While it doesn't specifically discusses this corner case, you can 
> >understand from "There is no legitimate reason for padding beyond the 
> >next eight octet..." that there's also no legitimate reason for an 
> >option header containing only padding.
> 
> Okay. I'm glad you agree with me and that we both understand the rfc the
> same way. And since the rfc does not say that "here's no legitimate
> reason for an option header containing only padding", this should be
> possible. I say we respect rfc and do not add stronger restrictions than
> it dictates. No need for them.

Strictly speaking, this RFC is informational, so it is doesn't dictate 
per se. I hope you don't suggest removing the other checks as well...

> >I can't imagine a sane use-case for this.
> 
> rfcs are not about sanity...

Great, we're in agreement again :) But I think the networking code is 
or should be.
What IPv6 stack would generate such a packet, given that the only usage 
of the padding options is to align other options?
Why should I accept a packet which is most likely an artificially 
crafted packet (RFC 3514)?

Cheers,
Eldad

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