* Re: [PATCH 0/2] Backport to 4.19 - sctp: fully support memory accounting
2020-05-06 14:20 [PATCH 0/2] Backport to 4.19 - sctp: fully support memory accounting ashwin-h
@ 2020-05-06 6:47 ` Greg KH
2020-05-06 14:20 ` [PATCH 1/2] sctp: implement memory accounting on tx path ashwin-h
2020-05-06 14:20 ` [PATCH 2/2] sctp: implement memory accounting on rx path ashwin-h
2 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2020-05-06 6:47 UTC (permalink / raw)
To: ashwin-h
Cc: vyasevich, nhorman, davem, linux-sctp, netdev, linux-kernel,
srivatsab, srivatsa, rostedt, srostedt, ashwin.hiranniah
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] sctp: implement memory accounting on rx path
2020-05-06 14:20 ` [PATCH 2/2] sctp: implement memory accounting on rx path ashwin-h
@ 2020-05-06 6:47 ` Greg KH
0 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2020-05-06 6:47 UTC (permalink / raw)
To: ashwin-h
Cc: vyasevich, nhorman, davem, linux-sctp, netdev, linux-kernel,
srivatsab, srivatsa, rostedt, srostedt, ashwin.hiranniah,
Xin Long
On Wed, May 06, 2020 at 07:50:54PM +0530, ashwin-h wrote:
> From: Xin Long <lucien.xin@gmail.com>
>
> commit 9dde27de3e5efa0d032f3c891a0ca833a0d31911 upstream.
>
> sk_forward_alloc's updating is also done on rx path, but to be consistent
> we change to use sk_mem_charge() in sctp_skb_set_owner_r().
>
> In sctp_eat_data(), it's not enough to check sctp_memory_pressure only,
> which doesn't work for mem_cgroup_sockets_enabled, so we change to use
> sk_under_memory_pressure().
>
> When it's under memory pressure, sk_mem_reclaim() and sk_rmem_schedule()
> should be called on both RENEGE or CHUNK DELIVERY path exit the memory
> pressure status as soon as possible.
>
> Note that sk_rmem_schedule() is using datalen to make things easy there.
>
> Reported-by: Matteo Croce <mcroce@redhat.com>
> Tested-by: Matteo Croce <mcroce@redhat.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Ashwin H <ashwinh@vmware.com>
> ---
> include/net/sctp/sctp.h | 2 +-
> net/sctp/sm_statefuns.c | 6 ++++--
> net/sctp/ulpevent.c | 19 ++++++++-----------
> net/sctp/ulpqueue.c | 3 ++-
> 4 files changed, 15 insertions(+), 15 deletions(-)
<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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/2] sctp: implement memory accounting on tx path
2020-05-06 14:20 ` [PATCH 1/2] sctp: implement memory accounting on tx path ashwin-h
@ 2020-05-06 6:47 ` Greg KH
0 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2020-05-06 6:47 UTC (permalink / raw)
To: ashwin-h
Cc: vyasevich, nhorman, davem, linux-sctp, netdev, linux-kernel,
srivatsab, srivatsa, rostedt, srostedt, ashwin.hiranniah,
Xin Long
On Wed, May 06, 2020 at 07:50:53PM +0530, ashwin-h wrote:
> From: Xin Long <lucien.xin@gmail.com>
>
> 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 <mcroce@redhat.com>
> Tested-by: Matteo Croce <mcroce@redhat.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Ashwin H <ashwinh@vmware.com>
> ---
> net/sctp/socket.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
<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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 0/2] Backport to 4.19 - sctp: fully support memory accounting
@ 2020-05-06 14:20 ashwin-h
2020-05-06 6:47 ` Greg KH
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: ashwin-h @ 2020-05-06 14:20 UTC (permalink / raw)
To: vyasevich, nhorman
Cc: davem, linux-sctp, netdev, linux-kernel, srivatsab, srivatsa,
rostedt, srostedt, gregkh, ashwin.hiranniah, ashwin-h
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 1/2] sctp: implement memory accounting on tx path
2020-05-06 14:20 [PATCH 0/2] Backport to 4.19 - sctp: fully support memory accounting ashwin-h
2020-05-06 6:47 ` Greg KH
@ 2020-05-06 14:20 ` ashwin-h
2020-05-06 6:47 ` Greg KH
2020-05-06 14:20 ` [PATCH 2/2] sctp: implement memory accounting on rx path ashwin-h
2 siblings, 1 reply; 6+ messages in thread
From: ashwin-h @ 2020-05-06 14:20 UTC (permalink / raw)
To: vyasevich, nhorman
Cc: davem, linux-sctp, netdev, linux-kernel, srivatsab, srivatsa,
rostedt, srostedt, gregkh, ashwin.hiranniah, Xin Long, Ashwin H
From: Xin Long <lucien.xin@gmail.com>
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 <mcroce@redhat.com>
Tested-by: Matteo Croce <mcroce@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ashwin H <ashwinh@vmware.com>
---
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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH 2/2] sctp: implement memory accounting on rx path
2020-05-06 14:20 [PATCH 0/2] Backport to 4.19 - sctp: fully support memory accounting ashwin-h
2020-05-06 6:47 ` Greg KH
2020-05-06 14:20 ` [PATCH 1/2] sctp: implement memory accounting on tx path ashwin-h
@ 2020-05-06 14:20 ` ashwin-h
2020-05-06 6:47 ` Greg KH
2 siblings, 1 reply; 6+ messages in thread
From: ashwin-h @ 2020-05-06 14:20 UTC (permalink / raw)
To: vyasevich, nhorman
Cc: davem, linux-sctp, netdev, linux-kernel, srivatsab, srivatsa,
rostedt, srostedt, gregkh, ashwin.hiranniah, Xin Long, Ashwin H
From: Xin Long <lucien.xin@gmail.com>
commit 9dde27de3e5efa0d032f3c891a0ca833a0d31911 upstream.
sk_forward_alloc's updating is also done on rx path, but to be consistent
we change to use sk_mem_charge() in sctp_skb_set_owner_r().
In sctp_eat_data(), it's not enough to check sctp_memory_pressure only,
which doesn't work for mem_cgroup_sockets_enabled, so we change to use
sk_under_memory_pressure().
When it's under memory pressure, sk_mem_reclaim() and sk_rmem_schedule()
should be called on both RENEGE or CHUNK DELIVERY path exit the memory
pressure status as soon as possible.
Note that sk_rmem_schedule() is using datalen to make things easy there.
Reported-by: Matteo Croce <mcroce@redhat.com>
Tested-by: Matteo Croce <mcroce@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ashwin H <ashwinh@vmware.com>
---
include/net/sctp/sctp.h | 2 +-
net/sctp/sm_statefuns.c | 6 ++++--
net/sctp/ulpevent.c | 19 ++++++++-----------
net/sctp/ulpqueue.c | 3 ++-
4 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index 2c6570e..fef8c33 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -421,7 +421,7 @@ static inline void sctp_skb_set_owner_r(struct sk_buff *skb, struct sock *sk)
/*
* This mimics the behavior of skb_set_owner_r
*/
- sk->sk_forward_alloc -= event->rmem_len;
+ sk_mem_charge(sk, event->rmem_len);
}
/* Tests if the list has one and only one entry. */
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index 9f4d325..93cbf88 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -6444,13 +6444,15 @@ static int sctp_eat_data(const struct sctp_association *asoc,
* in sctp_ulpevent_make_rcvmsg will drop the frame if we grow our
* memory usage too much
*/
- if (*sk->sk_prot_creator->memory_pressure) {
+ if (sk_under_memory_pressure(sk)) {
if (sctp_tsnmap_has_gap(map) &&
(sctp_tsnmap_get_ctsn(map) + 1) == tsn) {
pr_debug("%s: under pressure, reneging for tsn:%u\n",
__func__, tsn);
deliver = SCTP_CMD_RENEGE;
- }
+ } else {
+ sk_mem_reclaim(sk);
+ }
}
/*
diff --git a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c
index 8cb7d98..c2a7478 100644
--- a/net/sctp/ulpevent.c
+++ b/net/sctp/ulpevent.c
@@ -634,8 +634,9 @@ struct sctp_ulpevent *sctp_ulpevent_make_rcvmsg(struct sctp_association *asoc,
gfp_t gfp)
{
struct sctp_ulpevent *event = NULL;
- struct sk_buff *skb;
- size_t padding, len;
+ struct sk_buff *skb = chunk->skb;
+ struct sock *sk = asoc->base.sk;
+ size_t padding, datalen;
int rx_count;
/*
@@ -646,15 +647,12 @@ struct sctp_ulpevent *sctp_ulpevent_make_rcvmsg(struct sctp_association *asoc,
if (asoc->ep->rcvbuf_policy)
rx_count = atomic_read(&asoc->rmem_alloc);
else
- rx_count = atomic_read(&asoc->base.sk->sk_rmem_alloc);
+ rx_count = atomic_read(&sk->sk_rmem_alloc);
- if (rx_count >= asoc->base.sk->sk_rcvbuf) {
+ datalen = ntohs(chunk->chunk_hdr->length);
- if ((asoc->base.sk->sk_userlocks & SOCK_RCVBUF_LOCK) ||
- (!sk_rmem_schedule(asoc->base.sk, chunk->skb,
- chunk->skb->truesize)))
- goto fail;
- }
+ if (rx_count >= sk->sk_rcvbuf || !sk_rmem_schedule(sk, skb, datalen))
+ goto fail;
/* Clone the original skb, sharing the data. */
skb = skb_clone(chunk->skb, gfp);
@@ -681,8 +679,7 @@ struct sctp_ulpevent *sctp_ulpevent_make_rcvmsg(struct sctp_association *asoc,
* The sender should never pad with more than 3 bytes. The receiver
* MUST ignore the padding bytes.
*/
- len = ntohs(chunk->chunk_hdr->length);
- padding = SCTP_PAD4(len) - len;
+ padding = SCTP_PAD4(datalen) - datalen;
/* Fixup cloned skb with just this chunks data. */
skb_trim(skb, chunk->chunk_end - padding - skb->data);
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index 0b42710..7de9be3 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -1106,7 +1106,8 @@ void sctp_ulpq_renege(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk,
freed += sctp_ulpq_renege_frags(ulpq, needed - freed);
}
/* If able to free enough room, accept this chunk. */
- if (freed >= needed) {
+ if (sk_rmem_schedule(asoc->base.sk, chunk->skb, needed) &&
+ freed >= needed) {
int retval = sctp_ulpq_tail_data(ulpq, chunk, gfp);
/*
* Enter partial delivery if chunk has not been
--
2.7.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-05-06 6:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-06 14:20 [PATCH 0/2] Backport to 4.19 - sctp: fully support memory accounting ashwin-h
2020-05-06 6:47 ` Greg KH
2020-05-06 14:20 ` [PATCH 1/2] sctp: implement memory accounting on tx path ashwin-h
2020-05-06 6:47 ` Greg KH
2020-05-06 14:20 ` [PATCH 2/2] sctp: implement memory accounting on rx path ashwin-h
2020-05-06 6:47 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).