[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130725214749.GD29572@ws>
Date: Thu, 25 Jul 2013 18:47:49 -0300
From: Werner Almesberger <werner@...esberger.net>
To: netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: minimum ICMPv6 message size vs. RPL's DIS
Hannes Frederic Sowa wrote:
> I don't know how they could do this if they want to let other RFCs extend
> icmp types.
Oh, ICMPs can have padding. That's used to enforce "nice" alignment.
Even RFC 6550 (RPL) has that. For example, you could simply pad the
troublesome DIS, message which is
Offset Value Description
------ ----- ------------------------------------------------
0 0x9b ICMPv6 Type = RPL (155, section 6)
1 0x00 ICMPv6 Code = DODAG Information Solicitation (0)
2 0x?? Checksum
3 0x?? (continued)
4 0x00 Flags = 0 (section 6.2.1)
5 0x00 Reserved
to eight bytes (i.e., four bytes of body) by adding
6 0x01 Option Type = PadN (section 6.7.3)
7 0x00 Option Length = 0
But if nothing obliges the sender to do so, there's no excuse for
Linux to expect such padding.
> Yes, that could be an issue. I would be willing to accept this fallout. :)
I'm kinda curious what sort of policy we have on that. The worst
case would be that there's a bunch of 64 bit Linux machines out
there, doing critical infrastructure things in the Internet (not an
unlikely role, given the API in question), and their user space has
some vulnerability if the kernel lets a "short" ICMPv6 packet
through.
Of course, "The Almesberger-Sowa Internet Meltdown of 2013" does
have a nice ring to it, in an apocalyptic kind of way ...
- Werner
--
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
Powered by blists - more mailing lists