All of lore.kernel.org
 help / color / mirror / Atom feed
From: xiaoshoukui@gmail.com
To: netdev@vger.kernel.org
Cc: jmaloy@redhat.com, tung.quang.nguyen@est.tech,
	edumazet@google.com, w@1wt.eu,
	xiaoshoukui <xiaoshoukui@gmail.com>
Subject: [PATCH net v2] tipc: fix memory leaks in bundle and fragment paths
Date: Sat,  3 Oct 2026 14:16:35 +0000	[thread overview]
Message-ID: <20261003141635.33711-1-xiaoshoukui@gmail.com> (raw)

From: xiaoshoukui <xiaoshoukui@gmail.com>

In tipc_data_input(), recognized internal control message users (such
as MSG_BUNDLER, TUNNEL_PROTOCOL, MSG_FRAGMENTER, and BCAST_PROTOCOL)
return false WITHOUT releasing the skb via kfree_skb().

However, callers in the bundle extraction and fragment reassembly
receive paths currently ignore the return value of tipc_data_input().
This leads to memory leaks in the following scenarios:

1. Nested Bundle Path:
   When an outer MSG_BUNDLER message contains a structurally valid
   inner MSG_BUNDLER payload, tipc_msg_extract() allocates and
   extracts the inner skb. tipc_data_input() inspects the inner
   header, sees MSG_BUNDLER, and returns false without consuming or
   freeing the skb. Because the extraction loop ignores the return
   value, the inner skb is leaked.

2. Fragment Reassembly Path:
   When reassembly completes in tipc_buf_append(), the reassembled
   skb may carry msg_user == MSG_FRAGMENTER. tipc_data_input()
   inspects the reassembled skb, sees MSG_FRAGMENTER, and returns
   false without consuming or freeing it. The fragment completion path
   ignores the return value, leaking the reassembled skb.

Fix this by checking the return value of tipc_data_input() with
unlikely() in both receive paths and dropping unhandled skbs via
kfree_skb().

Hot-path disassembly verification confirms that adding unlikely()
preserves ideal branch layout. Benchmark evaluations under strict CPU
core isolation show no statistically significant throughput variation.

Fixes: c637c1035534 ("tipc: resolve race problem at unicast message reception")
Signed-off-by: xiaoshoukui <xiaoshoukui@gmail.com>
---
v1 -> v2:
 - Added unlikely() annotations to low-probability error paths.
 - Reverted to kfree_skb() to align with existing TIPC module conventions
   and avoid 80-column line wrapping / checkpatch warnings.
 - Re-evaluated benchmarks with strict CPU affinity (taskset).

Link: https://lore.kernel.org/netdev/20260916061220.798324-1-xiaoshoukui@gmail.com/

 net/tipc/link.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/tipc/link.c b/net/tipc/link.c
index 49dfc098d89b..dec72a2b113e 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1306,15 +1306,18 @@ static int tipc_link_input(struct tipc_link *l, struct sk_buff *skb,
 		skb_queue_head_init(&tmpq);
 		l->stats.recv_bundles++;
 		l->stats.recv_bundled += msg_msgcnt(hdr);
-		while (tipc_msg_extract(skb, &iskb, &pos))
-			tipc_data_input(l, iskb, &tmpq);
+		while (tipc_msg_extract(skb, &iskb, &pos)) {
+			if (unlikely(!tipc_data_input(l, iskb, &tmpq)))
+				kfree_skb(iskb);
+		}
 		tipc_skb_queue_splice_tail(&tmpq, inputq);
 		return 0;
 	} else if (usr == MSG_FRAGMENTER) {
 		l->stats.recv_fragments++;
 		if (tipc_buf_append(reasm_skb, &skb)) {
 			l->stats.recv_fragmented++;
-			tipc_data_input(l, skb, inputq);
+			if (unlikely(!tipc_data_input(l, skb, inputq)))
+				kfree_skb(skb);
 		} else if (!*reasm_skb && !link_is_bc_rcvlink(l)) {
 			pr_warn_ratelimited("Unable to build fragment list\n");
 			return tipc_link_fsm_evt(l, LINK_FAILURE_EVT);
-- 
2.34.1


             reply	other threads:[~2026-10-03 14:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-03 14:16 xiaoshoukui [this message]
2026-10-03 14:23 ` [PATCH net v2] tipc: fix memory leaks in bundle and fragment paths netdev-bot+sinfo
2026-10-05  1:49 ` Tung Quang Nguyen
2026-10-05 13:07   ` xiaoshoukui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261003141635.33711-1-xiaoshoukui@gmail.com \
    --to=xiaoshoukui@gmail.com \
    --cc=edumazet@google.com \
    --cc=jmaloy@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=tung.quang.nguyen@est.tech \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.