netdev - Re: [IPv6] "sendmsg: invalid argument" to multicast group after some time

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48BD604F.6010008@hp.com>
Date:	Tue, 02 Sep 2008 11:48:31 -0400
From:	Brian Haley <brian.haley@...com>
To:	Bernhard Schmidt <berni@...kenwald.de>
CC:	David Stevens <dlstevens@...ibm.com>, netdev@...r.kernel.org
Subject: Re: [IPv6] "sendmsg: invalid argument" to multicast group after	some
 time

Bernhard Schmidt wrote:
> Hello Brian,
> 
>>> So the flags look different, but why?
>> Well, at least in the ping6 sources I have, msg_flags is never  
>> initialized before the sendmsg() call, and since it's allocated on the  
>> stack it can have random bits set.  Can you rebuild your ping6 with the  
>> attached patch and retry?
> 
> Done, no change.
> 
> sendmsg(3, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(58), inet_pton(AF_INET6, "ff02::2", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, msg_iov(1)=[{"\200\0\0\0\3252\0\0010T\275H\274\314\7\0\10\t\n\v\f\r\16\17\20\21\22\23\24\25\26\27\30"..., 64}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_IPV6, cmsg_type=, ...}, msg_flags=0}, 0) = 64
> 
> vs. 
> 
> sendmsg(3, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(58), inet_pton(AF_INET6, "ff02::9", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, msg_iov(1)=[{"\200\0\0\0\3162\0\1+T\275H\255K\16\0\10\t\n\v\f\r\16\17\20\21\22\23\24\25\26\27\30"..., 64}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_IPV6, cmsg_type=, ...}, msg_flags=0}, 0) = -1 EINVAL (Invalid argument)
> 
> don't push too hard on ping6, I just included it to show that all
> processes are affected sending to this particular group.

That was just the obvious answer to why the flags were different.  Since 
EINVAL is too generic to point at one place in the kernel code path, I'd 
second David Stevens' suggestion of finding where in the sendmsg() code 
this is coming from.

Maybe you can trace the miredo daemon to see what it's doing that might 
fix the problem if you don't want to start hacking in the kernel.

-Brian
--
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