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: <20200311033552.GE2547@localhost.localdomain>
Date:   Wed, 11 Mar 2020 00:35:52 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     lucien.xin@...il.com, netdev@...r.kernel.org,
        linux-sctp@...r.kernel.org, nhorman@...driver.com,
        jere.leppanen@...ia.com, michael.tuexen@...chi.franken.de
Subject: Re: [PATCH net] sctp: return a one-to-one type socket when doing
 peeloff

On Mon, Mar 09, 2020 at 06:09:49PM -0700, David Miller wrote:
> From: Xin Long <lucien.xin@...il.com>
> Date: Mon,  2 Mar 2020 14:57:15 +0800
> 
> > As it says in rfc6458#section-9.2:
> > 
> >   The application uses the sctp_peeloff() call to branch off an
> >   association into a separate socket.  (Note that the semantics are
> >   somewhat changed from the traditional one-to-one style accept()
> >   call.)  Note also that the new socket is a one-to-one style socket.
> >   Thus, it will be confined to operations allowed for a one-to-one
> >   style socket.
> > 
> > Prior to this patch, sctp_peeloff() returned a one-to-many type socket,
> > on which some operations are not allowed, like shutdown, as Jere
> > reported.
> > 
> > This patch is to change it to return a one-to-one type socket instead.
> > 
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Reported-by: Leppanen, Jere (Nokia - FI/Espoo) <jere.leppanen@...ia.com>
> > Signed-off-by: Xin Long <lucien.xin@...il.com>
> 
> I don't know what to do with this patch.
> 
> There seems to be some discussion about a potential alternative approach
> to the fix, but there were problems with that suggestion.
> 
> Please advise, thank you.

Please drop it. As you noticed, we do need more discussions around
it. Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ