Date: Tue, 30 Apr 2002 18:38:33 -0700 (PDT) From: Kelly Yancey <kbyanc@posi.net> To: Bill Fenner <fenner@research.att.com> Cc: arch@FreeBSD.ORG, <net@FreeBSD.ORG> Subject: Re: Overflowing sockaddr_dl's sdl_data buffer Message-ID: <20020430181359.G11009-300000@gateway.posi.net> In-Reply-To: <200204211826.LAA05288@windsor.research.att.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--0-819770887-1020217113=:11009
Content-Type: TEXT/PLAIN; charset=US-ASCII
Attached are (very) simple patches which attempt to address the problem.
I've included -net in the CC to solicit a larger audience.
On Sun, 21 Apr 2002, Bill Fenner wrote:
>
> I think that sdl_data should go back to being a variable-length buffer,
> and the source routing stuff should be reimplemented somewhere else
> (perhaps at the end of the variable-length buffer).
>
> What uses the source-routing fields?
>
> Bill
>
Yeah, this is the route I favor, except that it would clearly break
compatibility with 3rd party binary-only drivers. Personally, I would really
like to see a solution implemented in the RELENG_4 branch. To that extent,
the attached patches keep the sockaddr_dl at it's current size but allots the
entire 34 bytes needed for token-ring source routing to the sdl_data field
(for a total of 46 bytes). The token-ring code just embeds it's source
routing information in the sdl_data field now. I also removed setting the
source routing control field to zero for non-iso88025 sockaddr_dl's since all
of the code which examines the field appears to contingent on the interface
being of the iso88025 persuasion.
That said, this leaves ample room in the sockaddr_dl structure for interface
name and MAC address in the sockaddr_dl (too much, but the overall size hasn't
changed). However, token ring interface names are still limited to 6
characters before they risk overflowing the sdl_data field with their source
routing information. This is no worse than the existing situation wherein a
token ring interface with more than 6 characters would cause the last byte(s)
of the hardware address to get clobbered by the source routing control field.
One point I am a little leary of is that in in_arpinput() the original code
appears to have made provision for receiving an ISO88025 frame on a non-token
ring interface and trusted the source routing information contained in such a
frame. First, is this a correct reading of the code? And second, is this
correct behavior? If so, I can easily restore it.
There are 2 sets of attached patches: one for -current and one for -stable
(the one suffixed with a 4). I've tested these pretty extensively on -stable
but haven't done any testing at all for -current (admittingly, not even a
build); furthermore all testing was just with ethernet...I do not have access
to any token ring hardware. I would appreciate any feedback regarding the
approach and anyone who can confirm that I haven't horribly borked token ring
source routing.
If all looks well, then ifconfig (and others?) will have to be updated to
not try and print source routing information unless the interface is token
ring.
Thanks,
Kelly
kbyanc@{posi.net,FreeBSD.org}
The original message for those subscribed to -net but not -arch:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020430181359.G11009-300000>