netdev - Re: [PATCH] sctp: Honour SCTP_PARTIAL_DELIVERY

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] [day] [month] [year] [list]

Date:   Thu, 3 Sep 2020 14:18:47 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     Petr Malat <oss@...at.biz>
Cc:     linux-sctp@...r.kernel.org, vyasevich@...il.com,
        nhorman@...driver.com, davem@...emloft.net, kuba@...nel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH] sctp: Honour SCTP_PARTIAL_DELIVERY_POINT even under
 memory pressure

Hi!

On Thu, Sep 03, 2020 at 01:21:48PM +0200, Petr Malat wrote:
> Hi!
> On Wed, Sep 02, 2020 at 11:58:35AM -0300, Marcelo Ricardo Leitner wrote:
> > On Tue, Sep 01, 2020 at 11:00:07AM +0200, Petr Malat wrote:
> > > Command SCTP_CMD_PART_DELIVER issued under memory pressure calls
> > > sctp_ulpq_partial_delivery(), which tries to fetch and partially deliver
> > > the first message it finds without checking if the message is longer than
> > > SCTP_PARTIAL_DELIVERY_POINT. According to the RFC 6458 paragraph 8.1.21.
> > > such a behavior is invalid. Fix it by returning the first message only if
> > > its part currently available is longer than SCTP_PARTIAL_DELIVERY_POINT.
> > 
> > Okay but AFAICT this patch then violates the basic idea behind partial
> > delivery. It will cause such small message to just not be delivered
> > anymore, and keep using the receive buffer which it is trying to free
> > some bits at this moment.
> By default the pd_point is set to 0, so there will not be a change in the
> behavior, but if the user changes it to some other value, it should be
> respected by the stack - for example when the largest message the user
> exchanges is 1kB and the user sets it to 1kB, his application is not
> prepared to handle fragmented messages at all and it's not a good idea to
> pass such a message to the app.

Then, if it doesn't support fragmented messages at all, the app just
shouldn't be setting pd_point at all. :-) Anyhow, I see how the patch
works now.

The fix is also needed on sctp_intl_retrieve_first() and
sctp_intl_retrieve_first_uo(). Same issue is in there, but for stream
interleaving.

Thanks.