netdev - Re: TCP using IPv4-mapped IPv6 address as source

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]

Date:   Wed, 11 Jan 2017 10:31:59 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     "Jonathan T. Leighton" <jtleight@...l.edu>
Cc:     netdev@...r.kernel.org, edumazet@...gle.com,
        Yuchung Cheng <ycheng@...gle.com>,
        Neal Cardwell <ncardwell@...gle.com>
Subject: Re: TCP using IPv4-mapped IPv6 address as source

On Wed, 2017-01-11 at 12:34 -0500, Jonathan T. Leighton wrote:
> On 1/11/17 11:20 AM, Eric Dumazet wrote:
> > On Thu, 2017-01-05 at 16:25 -0500, Jonathan T. Leighton wrote:
> >> I've observed TCP using an IPv4-mapped IPv6 address as the source
> >> address, which I believe contradicts
> >> https://tools.ietf.org/html/rfc6890#page-14 (BCP 153). This occurs when
> >> an IPv6 TCP socket, bound to a local IPv4-mapped IPv6 address, attempts
> >> to connect to a remote IPv6 address. Presumable connect() should return
> >> EAFNOSUPPORT in this case. Please advise me if this is not to
> >> appropriate list to report this.
> > Hi Jonathan
> >
> > I believe your concern makes sense.
> > Do you have a patch to address this issue ?
> 
> Thanks for responding Eric. I have limited experience with kernel 
> patches. Nevertheless, unless there's someone with the experience and 
> time to jump on this, I'm interested in taking a crack at it. I think 
> the issue certainly warrants attention: instead of returning immediately 
> with EAFNOSUPPPORT, connect() retransmits its SYN 6 times, ultimately 
> returning ETIMEDOUT after 127 sec (1+2+4+...+64).

I am not aware of an application trying to perform a bind() to an IPV4
address before a connect() to an IPv6 destination.

A kernel fix is certainly something that would detect application bugs
in a more friendly way.

Thanks !