RE: [PATCH net] tipc: fix memory leaks in bundle and fragment paths
From: Tung Quang Nguyen <tung.quang.nguyen@est.tech>
Date: 2026-09-17 03:51:20
Subject: [PATCH net] tipc: fix memory leaks in bundle and fragment paths From: xiaoshoukui <redacted> tipc_data_input() returns false when an extracted inner skb or reassembled fragment is not consumed (e.g. unhandled protocol user types). The bundle extraction loop and fragment reassembly path in tipc_link_input() both ignore this return value, leaving unconsumed skbs unreachable and leaking SLUB memory.
This cannot occur because the sending side already does sanity check to make sure that no invalid protocol type exists in bundled and fragmented messages. This only occurs when you create fake TIPC messages or tampering with existing messages. This is an invalid use case because TIPC is being used in an insecure environment. In such environment, IPSec or TIPC encryption must be used as mentioned here https://datatracker.ietf.org/doc/html/draft-maloy-tipc-01.txt#section-6
Fix this by freeing unconsumed skbs with kfree_skb_reason() and setting the
This approach can break user applications as explained below.
quoted hunk ↗ jump to hunk
drop reason to SKB_DROP_REASON_UNHANDLED_PROTO. Fixes: c637c1035534 ("tipc: resolve race problem at unicast message reception") Signed-off-by: xiaoshoukui <redacted> --- 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..3278a559347b100644--- a/net/tipc/link.c +++ b/net/tipc/link.c@@ -1306,15 +1306,18 @@ static int tipc_link_input(struct tipc_link *l, structsk_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 (!tipc_data_input(l, iskb, &tmpq))
This check is redundant because bundled messages do not contain message types that can make tipc_data_input() return false. The only exception is tampering with TIPC messages. If that is the case, a fake valid message type can be inserted into the bundle message and tipc_data_input() returns true but user applications are broken by corrupt messages.
+ kfree_skb_reason(iskb, SKB_DROP_REASON_UNHANDLED_PROTO);
Compiling warnings: https://netdev-ctrl.bots.linux.dev/logview.html?f=/logs/build/1166117/14820384/checkpatch/stdout
+ }
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 (!tipc_data_input(l, skb, inputq))This check is redundant because fragmented messages do not contain message types that can make tipc_data_input() return false. The only exception is tampering with TIPC messages. If that is the case: - dropping the invalid fragmented message will cause the reassembled message corrupt (For example: sending a 65KB message but dropping/truncating 1500 bytes). As a result, user applications receive corrupt messages. - a fake fragmented message can ben sent and tipc_data_input() returns true but user applications are broken by corrupt messages.
+ kfree_skb_reason(skb,
SKB_DROP_REASON_UNHANDLED_PROTO);
} 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