2020-05-06 06:36:50

by Ashwin H

[permalink] [raw]
Subject: [PATCH 0/2] Backport to 4.19 - sctp: fully support memory accounting

Backport below upstream commits to 4.19 to address CVE-2019-3874.
1033990ac5b2ab6cee93734cb6d301aa3a35bcaa
sctp: implement memory accounting on tx path

9dde27de3e5efa0d032f3c891a0ca833a0d31911
sctp: implement memory accounting on rx path

Xin Long (2):
sctp: implement memory accounting on tx path
sctp: implement memory accounting on rx path

include/net/sctp/sctp.h | 2 +-
net/sctp/sm_statefuns.c | 6 ++++--
net/sctp/socket.c | 10 ++++++++--
net/sctp/ulpevent.c | 19 ++++++++-----------
net/sctp/ulpqueue.c | 3 ++-
5 files changed, 23 insertions(+), 17 deletions(-)

--
2.7.4


2020-05-06 06:49:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 0/2] Backport to 4.19 - sctp: fully support memory accounting

On Wed, May 06, 2020 at 07:50:52PM +0530, ashwin-h wrote:
> Backport below upstream commits to 4.19 to address CVE-2019-3874.
> 1033990ac5b2ab6cee93734cb6d301aa3a35bcaa
> sctp: implement memory accounting on tx path
>
> 9dde27de3e5efa0d032f3c891a0ca833a0d31911
> sctp: implement memory accounting on rx path
>
> Xin Long (2):
> sctp: implement memory accounting on tx path
> sctp: implement memory accounting on rx path
>
> include/net/sctp/sctp.h | 2 +-
> net/sctp/sm_statefuns.c | 6 ++++--
> net/sctp/socket.c | 10 ++++++++--
> net/sctp/ulpevent.c | 19 ++++++++-----------
> net/sctp/ulpqueue.c | 3 ++-
> 5 files changed, 23 insertions(+), 17 deletions(-)
>
> --
> 2.7.4
>

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

2020-05-06 18:57:13

by Ashwin H

[permalink] [raw]
Subject: [PATCH 1/2] sctp: implement memory accounting on tx path

From: Xin Long <[email protected]>

commit 1033990ac5b2ab6cee93734cb6d301aa3a35bcaa upstream.

Now when sending packets, sk_mem_charge() and sk_mem_uncharge() have been
used to set sk_forward_alloc. We just need to call sk_wmem_schedule() to
check if the allocated should be raised, and call sk_mem_reclaim() to
check if the allocated should be reduced when it's under memory pressure.

If sk_wmem_schedule() returns false, which means no memory is allowed to
allocate, it will block and wait for memory to become available.

Note different from tcp, sctp wait_for_buf happens before allocating any
skb, so memory accounting check is done with the whole msg_len before it
too.

Reported-by: Matteo Croce <[email protected]>
Tested-by: Matteo Croce <[email protected]>
Acked-by: Neil Horman <[email protected]>
Acked-by: Marcelo Ricardo Leitner <[email protected]>
Signed-off-by: Xin Long <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ashwin H <[email protected]>
---
net/sctp/socket.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index c93be3b..df4a7d7 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1931,7 +1931,10 @@ static int sctp_sendmsg_to_asoc(struct sctp_association *asoc,
if (sctp_wspace(asoc) < (int)msg_len)
sctp_prsctp_prune(asoc, sinfo, msg_len - sctp_wspace(asoc));

- if (sctp_wspace(asoc) <= 0) {
+ if (sk_under_memory_pressure(sk))
+ sk_mem_reclaim(sk);
+
+ if (sctp_wspace(asoc) <= 0 || !sk_wmem_schedule(sk, msg_len)) {
timeo = sock_sndtimeo(sk, msg->msg_flags & MSG_DONTWAIT);
err = sctp_wait_for_sndbuf(asoc, &timeo, msg_len);
if (err)
@@ -8515,7 +8518,10 @@ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p,
goto do_error;
if (signal_pending(current))
goto do_interrupted;
- if ((int)msg_len <= sctp_wspace(asoc))
+ if (sk_under_memory_pressure(sk))
+ sk_mem_reclaim(sk);
+ if ((int)msg_len <= sctp_wspace(asoc) &&
+ sk_wmem_schedule(sk, msg_len))
break;

/* Let another process have a go. Since we are going
--
2.7.4