netdev - Re: [PATCHv3 net-next 2/5] sctp: add pf_expose per netns and sock and asoc

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: <20191025132151.GF4326@localhost.localdomain>
Date:   Fri, 25 Oct 2019 10:21:51 -0300
From:   'Marcelo Ricardo Leitner' <marcelo.leitner@...il.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Xin Long <lucien.xin@...il.com>,
        network dev <netdev@...r.kernel.org>,
        "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
        Neil Horman <nhorman@...driver.com>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCHv3 net-next 2/5] sctp: add pf_expose per netns and sock
 and asoc

On Fri, Oct 25, 2019 at 09:00:45AM +0000, David Laight wrote:
> From: Marcelo Ricardo Leitner
> > Sent: 25 October 2019 04:24
> ...
> > > @@ -5521,8 +5522,16 @@ static int sctp_getsockopt_peer_addr_info(struct sock *sk, int len,
> > >
> > >  	transport = sctp_addr_id2transport(sk, &pinfo.spinfo_address,
> > >  					   pinfo.spinfo_assoc_id);
> > > -	if (!transport)
> > > -		return -EINVAL;
> > > +	if (!transport) {
> > > +		retval = -EINVAL;
> > > +		goto out;
> > > +	}
> > > +
> > > +	if (transport->state == SCTP_PF &&
> > > +	    transport->asoc->pf_expose == SCTP_PF_EXPOSE_DISABLE) {
> > > +		retval = -EACCES;
> > > +		goto out;
> > > +	}
> > 
> > As is on v3, this is NOT an UAPI violation. The user has to explicitly
> > set the system or the socket into the disabled state in order to
> > trigger this new check.
> 
> Only because the default isn't to be backwards compatible with the
                           ^^^^^

You meant "is", right? Then we're agreeing.

> old kernel and old applications.
> 
> An old application running on a system that has the protocol parts of
> PF enabled mustn't see any PF events, states or obscure error returns.

Yes. With the patchset, the application will only see the new error
return if it (the app or the sysadmin) explicitly choose to be more
compliant to the RFC. There's no harm in that.