linux-kernel - RE: Strange problem with SCTP+IPv6

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:   Fri, 26 Jun 2020 16:13:51 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Xin Long' <lucien.xin@...il.com>,
        Michael Tuexen <Michael.Tuexen@...chi.franken.de>
CC:     Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        "minyard@....org" <minyard@....org>,
        Vlad Yasevich <vyasevich@...il.com>,
        Neil Horman <nhorman@...driver.com>,
        "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: RE: Strange problem with SCTP+IPv6

From: Xin Long
> Sent: 23 June 2020 11:14
> > > It looks like a bug to me. Testing with this test app here, I can see
> > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and
> > > that's unexpected for a v6only socket. As is, it's the server saying
> > > "I'm available at these other addresses too, but not."
> > I agree.
> Then we need a fix in sctp_bind_addrs_to_raw():
> 
> @@ -238,6 +240,9 @@ union sctp_params sctp_bind_addrs_to_raw(const
> struct sctp_bind_addr *bp,
>         addrparms = retval;
> 
>         list_for_each_entry(addr, &bp->address_list, list) {
> +               if ((PF_INET6 == sk->sk_family) && inet_v6_ipv6only(sk) &&
> +                   (AF_INET == addr->a.sa.sa_family))
> +                       continue;
>                 af = sctp_get_af_specific(addr->a.v4.sin_family);
>                 len = af->to_addr_param(&addr->a, &rawaddr);
>                 memcpy(addrparms.v, &rawaddr, len);

Thought.

Does it make any sense to offer addresses in the INIT_ACK that don't
have routes to those proposed in the received INIT?

'routes' probably isn't exactly the right word.
You probably only want the local address that will be used
as the source address for the probes.
Or, at least, sources addresses that could be used for the probes.

So if the INIT only contains IPv6 addresses should the INIT_ACK
ever contain IPv4 ones.

	David.

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)