Bug analyzed - how to fix it?

Jung-uk Kim jkim at FreeBSD.org
Fri Jan 4 19:43:02 UTC 2013

Hash: SHA1

On 2013-01-04 12:40:18 -0500, Martin Laabs wrote:
> Hi,
> I'm (hopefully) done with the bug analyses of 
> "http://www.freebsd.org/cgi/query-pr.cgi?pr=174933". The bug in one
> sentences: if_nameindex (resided in the libc) fails if called out
> of a linux binary.
> The cause is that the if_nameindex calls a function named
> __opensock that return a socket. This socket is used to call an
> ioctl(SIOCGIFCONF ...). This ioctl call is actually implemented in
> the linuxulator. Unfortunately the __opensock function tries to
> create the following socket:
> socket(PF_NETLINK, SOCK_RAW, 0) in decimal: socket(16,3,0)

It seems "0" is actually NETLINK_ROUTE:


> This type of socket type however is not supported by the
> linuxulator and IMHO in freebsd at all. However - maybe it just has
> another name in FreeBSD.

It is one of those Linux-only things that we cannot be easily add to
Linuxulator, I'm afraid:


> So - for me there seem to be two solutions:
> 1. Write a dirty patch that returns a PF_INET instead of the
> PF_NETLINK socket if called with the arguments above. This should
> be OK since I assume that SIOCGIFCONF ioctl works also fine with
> PF_INET sockets. (I'll test this to verify whether this is true) 
> This however would be somewhat dirty since PF_NETLINK sockets are
> not really supported and if another application tries to open a
> real PF_NETLINK socket it will get a false positive result.
> 2. Patch the glibc to not create a PF_NETLINK socket in __opensock
> but create a PF_INET socket instead. The problem is that I do not
> know about the side effects since the __opensock function is used
> elsewhere in the libc also. The second drawback is that this would
> lead to a customized libc for the linuxulator. As far as I know the
> current libc(s) are just bare copies out of linux systems. So this
> solution would also increase maintenance effort.
> Do you have an other idea how to fix the problem?

I just glanced at the GNU libc sources.  I found they had backward
shims for pre-netlink kernels.

sysdeps/unix/sysv/linux/kernel-features.h [*]:

/* With kernel 2.4.17 we always have netlink support.  */
#if __LINUX_KERNEL_VERSION >= (132096+17)
# define __ASSUME_NETLINK_SUPPORT      1

In other words, if the GNU libc was compiled for Linux 2.4.17 and
later, it assumes the netlink is always available and it won't bother
compiling in fallback functions.

Jung-uk Kim

* Note: the fallback methods was completely removed in recent glibc.

Version: GnuPG v2.0.19 (FreeBSD)


More information about the freebsd-emulation mailing list