Thread (8 messages) 8 messages, 4 authors, 2021-02-03

Re: [PATCH net-next] net: fix up truesize of cloned skb in skb_prepare_for_shift()

flat view

From: Christoph Paasch <hidden>
Date: 2021-02-01 16:51:42
Also in: lkml

On Mon, Feb 1, 2021 at 8:09 AM Marco Elver [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Avoid the assumption that ksize(kmalloc(S)) == ksize(kmalloc(S)): when
cloning an skb, save and restore truesize after pskb_expand_head(). This
can occur if the allocator decides to service an allocation of the same
size differently (e.g. use a different size class, or pass the
allocation on to KFENCE).

Because truesize is used for bookkeeping (such as sk_wmem_queued), a
modified truesize of a cloned skb may result in corrupt bookkeeping and
relevant warnings (such as in sk_stream_kill_queues()).

Link: https://lkml.kernel.org/r/X9JR/J6dMMOy1obu@elver.google.com
Reported-by: syzbot+7b99aafdcc2eedea6178@syzkaller.appspotmail.com
Suggested-by: Eric Dumazet <redacted>
Signed-off-by: Marco Elver <elver@google.com>
---
 net/core/skbuff.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 2af12f7e170c..3787093239f5 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3289,7 +3289,19 @@ EXPORT_SYMBOL(skb_split);
  */
 static int skb_prepare_for_shift(struct sk_buff *skb)
 {
-       return skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
+       int ret = 0;
+
+       if (skb_cloned(skb)) {
+               /* Save and restore truesize: pskb_expand_head() may reallocate
+                * memory where ksize(kmalloc(S)) != ksize(kmalloc(S)), but we
+                * cannot change truesize at this point.
+                */
+               unsigned int save_truesize = skb->truesize;
+
+               ret = pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
+               skb->truesize = save_truesize;
+       }
+       return ret;
just a few days ago we found out that this also fixes a syzkaller
issue on MPTCP (https://github.com/multipath-tcp/mptcp_net-next/issues/136).
I confirmed that this patch fixes the issue for us as well:

Tested-by: Christoph Paasch <redacted>




 }

 /**

base-commit: 14e8e0f6008865d823a8184a276702a6c3cbef3d
--
2.30.0.365.g02bc693789-goog
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help