Re: 2.2.15 + IPv6: serious bug when removing aliased interfaces

From: Peter T. Breuer (ptb@it.uc3m.es)
Date: Mon May 22 2000 - 06:38:38 EST


"A month of sundays ago Pekka Savola wrote:"
> > > 1.432 (1.29 (1997-09-23)) good
> > > 1.46 (1.35 (1998-08-29)) good, but doesn't show lo:1 when it's up
> > > 1.47 (1.36 (1998-10-31)) bad
> > > 1.51 (1.39 (1999-03-18)) bad
> >
> > Can you look at the diff between ifconfig 1.35 and 1.36 and tell us if
> > there's anything that looks like a loop across detected aliases? I
> > noticed the strace showed two ioctl calls where I expected one.
>
> I'm not sure if you already got a look at the source, but I made some
> available at:
>
> http://gap.tky.hut.fi/linux/

Thanks .. the story so far is that Kurt has identified a change
in a loop ordering in ifconfig that apparently results in an IPV6
tainted socket being used to down the interface. Reverting the
loop ordering works around the issue. I believe the current proposed
patch to socket.c (funcion sockets_open()) in ifconfig is:

(about line 81)

         for (sk = &sockets[0]; sk->varp; sk++) {
                 if (family && family != sk->family)
                         continue;
 - if (*(sk->varp) != -1) {
 + if (*(sk->varp) != -1 && sfd < 0) {
                         sfd = *(sk->varp);
                         continue;

(about line 90)
                         if (access(sk->flag_file, R_OK))
                                 continue;
                 }
 - sfd = socket(sk->family, SOCK_DGRAM, 0);
 - *(sk->varp) = sfd;
 + *(sk->varp) = socket(sk->family, SOCK_DGRAM, 0);
 + if (sfd < 0)
 + sfd = *(sk->varp);
         }
         if (sfd < 0)

But it really is probable that this is a kernel bug wrt sockets when the
address family != AF_INET. The above usually avoids triggering it.

> Then, I did a little experimentation with latest ifconfig.c source code,
> uncommenting some things out I thought could cause the problems.
> I think, the problem might be here, in the bottom
> memcpy. Rationale? Interesting FIXME line; also, when I tried printing
> (char *) &sa just before memcpy, it'd show different things on my IPv6
> enabled and IPv6 disabled box.

There are various strange things. What we observed was that the same
ioctl was applied to different sockets in the good and bad codes, with
different results. Hence the workaround: apply the ioctl to the socket
for which it works right.

The debian netbase maintainer (at least) is being cc: ed.

Peter

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:21 EST