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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 14 Sep 2007 15:11:39 -0700 From: Ben Greear <greearb@...delatech.com> To: David Miller <davem@...emloft.net> CC: netdev@...r.kernel.org, kaber@...sh.net Subject: Re: SO_BINDTODEVICE mismatch with man page & comments. David Miller wrote: > From: Ben Greear <greearb@...delatech.com> > Date: Tue, 04 Sep 2007 15:45:14 -0700 > >> According to the comment in the net/core/sock.c code (in 2.6.20), I should be able to pass a zero >> optlen to the setsockopt method for SO_BINDTODEVICE: > ... >> However, earlier in that method it returns -EINVAL if optlen is < sizeof(int). >> >> The man page has comments similar to that in the code above. >> >> Also, even when I get the un-bind call working with code similar to: >> >> int z = 0; >> setsockopt(s, SOL_SOCKET, SO_BINDTODEVICE, &z, sizeof(z)); >> >> The app I'm working on (Xorp) does not appear to work. Perhaps because >> the kernel does not clean up the cached route when you un-bind >> as it does in the (re)bind logic? >> >> /* Remove any cached route for this socket. */ >> sk_dst_reset(sk); >> > > Ok, the patch below is how I'm dealing with this. > > Let me know if things work better now, and also I would appreciate > it if you could contact the man page maintainers to remove the > optlen==0 language. > > Thanks. > >>>From 136f55cf4ad0a3b0185bfc97c68f9e4d74ddcfe7 Mon Sep 17 00:00:00 2001 > From: David S. Miller <davem@...set.davemloft.net> > Date: Fri, 14 Sep 2007 13:10:17 -0700 > Subject: [PATCH] [NET]: Fix two issues wrt. SO_BINDTODEVICE. > > 1) Comments suggest that setting optlen to zero will unbind > the socket from whatever device it might be attached to. This > hasn't been the case since at least 2.2.x because the first thing > this function does is return -EINVAL if 'optlen' is less than > sizeof(int). > > Furthermore, there are not "optlen == 0" tests in the > SO_BINDTODEVICE code either. > > This also means we can toss the "!valbool" code block because if > that is true we'll also see the first byte of the passed in name > buffer as '\0' and this will also unbind the socket. From user-space, does this imply that the 'empty string' we use to unbind must be at least 4 bytes long, but with the first byte /0? If so, I think it might be confusing for the comments to say use "" to unbind, since that would not be a long enough chunk of memory. Maybe something like "Use a character array of at least 4 bytes in length with the first byte set to '/0'." This brings up another issue as well: What if the device name is "tr1", to bind to it we'd have to pass in "tr1/0" and optlen of 4. Not that this is difficult to do, but it does seem like a weird thing to have to do. Thanks, Ben -- Ben Greear <greearb@...delatech.com> Candela Technologies Inc http://www.candelatech.com - 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