linux-kernel - Re: [PATCH] SCTP: IPv4 mapped addr not returned in SCTPv6 accept()

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <46A8F926.1070606@hp.com>
Date:	Thu, 26 Jul 2007 15:42:30 -0400
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Dave Johnson <djohnson+linux-kernel@...starentnetworks.com>
Cc:	lksctp-developers@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org,
	Srinivas Akkipeddi <sakkiped@...rentnetworks.com>
Subject: Re: [PATCH] SCTP: IPv4 mapped addr not returned in SCTPv6 accept()

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:
> 
>  [<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.

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

View attachment "connect_bug.txt" of type "text/plain" (2545 bytes)