From: Sangho Lee <kudo3228@gmail.com>
To: Jon Maloy <jmaloy@redhat.com>, netdev@vger.kernel.org
Cc: tipc-discussion@lists.sourceforge.net, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, ying.xue@windriver.com,
tuong.t.lien@dektech.com.au, linux-kernel@vger.kernel.org,
Sangho Lee <kudo3228@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH net] tipc: validate Gap ACK blocks header before parsing
Date: Thu, 23 Jul 2026 11:29:47 +0900 [thread overview]
Message-ID: <20260723022947.1569915-1-kudo3228@gmail.com> (raw)
An established TIPC peer that negotiated TIPC_GAP_ACK_BLOCK can send a
STATE_MSG with fewer than the four bytes required for struct
tipc_gap_ack_blks. Basic TIPC message validation accepts such a message,
including one with an empty data area, because its declared size still
contains a complete protocol header.
tipc_get_gap_ack_blks() then dereferences the record to read len,
ugack_cnt, and bgack_cnt. Both callers compare the returned record size
with the declared message data length, but only after these fields have
already been read. The late checks therefore cannot protect the fixed
record header access.
This was reproduced on current net-next with two live TIPC nodes over a
veth bearer. Replaying an established peer's STATE_MSG with its message
size reduced from 44 to 40 bytes produced:
BUG: KMSAN: uninit-value in tipc_get_gap_ack_blks
tipc_get_gap_ack_blks
tipc_bcast_sync_rcv
tipc_node_bc_sync_rcv
tipc_rcv
tipc_l2_rcv_msg
Uninit was created at:
__alloc_skb
alloc_skb_with_frags
sock_alloc_send_pskb
packet_sendmsg
The uninitialized record length then reached tipc_bcast_sync_rcv(), where
it was used to decide whether the STATE_MSG should be dropped. Supplying
four initialized bytes after the declared end of otherwise identical
messages also changed that decision: a trailing len of zero continued
processing, while a trailing len of four dropped the message. Protocol
processing therefore depends on bytes that are not part of the declared
TIPC message.
The KMSAN finding was reproduced for declared data lengths zero through
three. After adding the minimum-length check, none of those four inputs
reported an uninitialized value in tipc_get_gap_ack_blks() or its caller,
and bytes after the declared message no longer affected the decision.
Check that the fixed record header is present before parsing it. The
callers' existing size checks continue to validate the complete
variable-length record.
Fixes: d7626b5acff9 ("tipc: introduce Gap ACK blocks for broadcast link")
Cc: stable@vger.kernel.org
Signed-off-by: Sangho Lee <kudo3228@gmail.com>
---
net/tipc/link.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 49dfc098d89b..8cc30ebdf575 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1418,7 +1418,8 @@ u16 tipc_get_gap_ack_blks(struct tipc_gap_ack_blks **ga, struct tipc_link *l,
u16 sz = 0;
/* Does peer support the Gap ACK blocks feature? */
- if (l->peer_caps & TIPC_GAP_ACK_BLOCK) {
+ if ((l->peer_caps & TIPC_GAP_ACK_BLOCK) &&
+ msg_data_sz(hdr) >= sizeof(*p)) {
p = (struct tipc_gap_ack_blks *)msg_data(hdr);
sz = ntohs(p->len);
/* Sanity check */
--
2.43.0
reply other threads:[~2026-07-23 2:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260723022947.1569915-1-kudo3228@gmail.com \
--to=kudo3228@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jmaloy@redhat.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=tipc-discussion@lists.sourceforge.net \
--cc=tuong.t.lien@dektech.com.au \
--cc=ying.xue@windriver.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox