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:
[<f8c539de>] sctp_v4_to_sk_daddr+0x3e/0x80 [sctp]
[<f8c5f6c4>] __sctp_connect+0x2a4/0x520 [sctp]
[<f8c61810>] sctp_connect+0x60/0x70 [sctp]
[<c02c4b2c>] inet_dgram_connect+0x4c/0x80
[<c026dbab>] sys_connect+0x8b/0xd0
[<c026e711>] sys_socketcall+0xb1/0x260
[<c0103013>] 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.
--
Dave Johnson
Starent Networks
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
