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

Message-ID: <20200902145835.GC2444@localhost.localdomain>
Date:   Wed, 2 Sep 2020 11:58:35 -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
Subject: Re: [PATCH] sctp: Honour SCTP_PARTIAL_DELIVERY_POINT even under
 memory pressure

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.

Btw, you also need to Cc netdev@...r.kernel.org for patches to
actually get applied by DaveM.

  Marcelo