Dave Johnson wrote: > Vlad Yasevich writes: >> Can you explain why the sctp_v4 changes are need for the this case? >> I don't see how the code in sctp/protocol.c comes into play for this >> particular bug. > > connect() on v6 socket to v4 mapped address will trigger > sctp_v4_to_sk_daddr: > > strace: > > socket(PF_INET6, SOCK_STREAM, 0x84 /* IPPROTO_??? */) = 3 > bind(3, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 128) = 0 > connect(3, {sa_family=AF_INET6, sin6_port=htons(33333), inet_pton(AF_INET6, "::ffff:192.168.207.231", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 128) = 0 > getsockname(3, {sa_family=AF_INET6, sin6_port=htons(32771), inet_pton(AF_INET6, "::ffff:192.168.207.234", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 > getpeername(3, {sa_family=AF_INET6, sin6_port=htons(33333), inet_pton(AF_INET6, "::ffff:192.168.207.231", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 > > stack dump: > > [] sctp_v4_to_sk_daddr+0x3e/0x80 [sctp] > [] __sctp_connect+0x2a4/0x520 [sctp] > [] sctp_connect+0x60/0x70 [sctp] > [] inet_dgram_connect+0x4c/0x80 > [] sys_connect+0x8b/0xd0 > [] sys_socketcall+0xb1/0x260 > [] syscall_call+0x7/0xb > > I'm unsure if there is a path to call sctp_v4_to_sk_saddr() but it was > added just to be complete. > > v4mapped in sctp_v4_create_accept_sk() probably isn't needed, but > since v4mapped is in sctp_sock not sctp6_sock copying it seems like a > good idea. Ok. First, this is a different bug, so I would prefer a separate patch. Also, I see the problem and it's ugly, but this solution is not really correct, both conceptually and code wise. Conceptually, the v4 code should never worry about V4-mapped addresses and shouldn't muck with them. They are IPv6 addresses and there should be a clean separation. Code wise, the code in the __sctp_connect() is terrible. Does the attached patch work for you in this case. Thanks -vlad