From nobody Fri Jul 24 05:21:27 2026 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 57B4633A9E1 for ; Thu, 23 Jul 2026 02:29:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784773793; cv=none; b=QkqTEg2ex5kMbzdpFXi0zRb+Pk3gta+D6OhL15y5Kq+mjfKWtrBDxbzwyRzbNtkYzbATu3NLBnGjG8fN+/Z5Y0eTTyc6niLA51fQNQM6gaqQblZju+cuxvelyaDNsrKAihTYiGrDZo9Xo4w6EaH9hleZ47dFoOcXUJYmwGBClE4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784773793; c=relaxed/simple; bh=4vYiVVksyldn7swIpfllG1hkNNDW7P+IPr9Ajbx6HE4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=HDkmH5bXU1aSv3QeZPpTqaFcg2frYQlEJ8sn3fKMbCiRP2kqbu7MHTFjPT0lsQTgmp3uRWTTsq0ULaNUrteKE5G9qOeWur8JnQI7ZCgF74Yim6nh2eAwejGK1xQklbNHwVIVhOAam6nikVi02uEkkT3wMgfKbymL2WXOdhQ0yaw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Wtwz2ZVI; arc=none smtp.client-ip=209.85.210.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Wtwz2ZVI" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-8487214ad2bso185785b3a.1 for ; Wed, 22 Jul 2026 19:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784773791; x=1785378591; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=p8LvT3IJZd7EJrtc9YjjpZEfucaV4n9NX3Db71UzcA4=; b=Wtwz2ZVIQFRkBFEWLXJGG3ciDgy8i76mJmZMfVMFQN5acHvmXxy5Li8sHrzgtxKV+8 YDjUkIKsRwj7N2U3G6ccnsrhbn7KZR52kv4CHK1FusfukKWHNh1ubXUYZ+j5QK0QlEiH Tm/fAY6TXaye+NvvN5o+qQ7I7d9Qsbs374mF968saXKCJJX/wWS0l6oR6AsstfYCtVFN py0LYra0xfES1KQwgRHubqIAygeHXu8jGP0H9I7pjzyaRQ5TTZDQ7ccVYupWZ/uG4PtR 7xHofAnNo1XhLw5ncB05UlRIZaEr7H7FAjNmF9/I0CMqKPR8XjNXm7aoLiKE363BNvYh Y3ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784773791; x=1785378591; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=p8LvT3IJZd7EJrtc9YjjpZEfucaV4n9NX3Db71UzcA4=; b=fhNKEAvgVxcAJromc0D5KmOJxZmNQf1Hz13NdPHeoYMKfyOjiRnT0ZaI7cN/RSbzBz tJvCZZZzhRp15m2+Lib+n/KYP0DH1iEp3kNq6cKsoe0FTcs1Gh4D1wQ2z8PT/XhTFgKO US1q249H7t8m9PKGeTHCxawlIVIZFseAqrUPq8/s+Zcx+tkgq+f/IzVPgfpeEyKGIvNp 8MEV54N2yR0VOqeMx4I8nm5xsdmcbIgjT8nM29J0dAoqiWtsX5YIi5g5OTvsgHhyoxm/ m94a2IsO2FKkhTW9ZEBgNSIjVcbqOOvIgFadXtic6ZfpnIKcs3tQ44Tbo3jhTYEM+5qw 6qpA== X-Forwarded-Encrypted: i=1; AHgh+RobTJdnnc/BQlrdxsnJ6iHW2tm2/K5vdNX4p3nbhnDW3kAlCWFIMs0BUONOqzKujbcoAWn2HkTAToWKxlQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzS4CGJDCXm/vNnxAQKD7vg8uz4PT3jA4e4ce2q1hIY34uIftIF Gk8b70P1qK+se8i/Iy8k3tUIcWBjDNa4wYNU1veeM+azdB0BkaeeO9tm X-Gm-Gg: AR+sD10bcjf1gGsDOOY5iWsw8eUSwfiDxOX9/P0QnCPrRbyOeArAxIiaECECjLaxyT4 zwGg+XnWkpbctrYKfn6sB2DxvFGrkdIl/y/V073V/53odnDdVjGqcKcwh7X1zD77WcMgrh2VymM IrTlySvMPfGY3ejY1SSPgUb99heisqXHFqMaekfG4cTLOFa2H9qyM7QbDSzZCZEiaEjUrph1mde 0iEJvIsMTZxVwa/fAo/u7gggyHp5iP0lpcsfWRcnxwTpam4pLu+YrHrZHcKskY6ffZFyCua1qHT pkgLfmgJRMUw2dt+e+IQMlN/cFUDhgkoN/yy5XDB7ZlCKxdIqCk0CQnplsKmPM46yU2shmw0A7Y LBpa+SpAdrgrQpLcfcGhTRcvljkiHJu6TfLZV9hO7zwB7uRfX/t0E+xAvunD4IiZWHTdnXD3lD3 8Kvdq6UN/kwPuWwMx8WiWgZObeI2Bt75BmkfDAjyly12i07AMpNDeFd1Vo1ZdEgeU= X-Received: by 2002:a05:6a00:9501:b0:848:2f77:e2d7 with SMTP id d2e1a72fcca58-84e2c2208fbmr1505866b3a.64.1784773791358; Wed, 22 Jul 2026 19:29:51 -0700 (PDT) Received: from DESKTOP-L3Q0GIV.localdomain ([203.230.195.19]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84e17578345sm2129549b3a.39.2026.07.22.19.29.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jul 2026 19:29:50 -0700 (PDT) From: Sangho Lee To: Jon Maloy , 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 , stable@vger.kernel.org Subject: [PATCH net] tipc: validate Gap ACK blocks header before parsing Date: Thu, 23 Jul 2026 11:29:47 +0900 Message-ID: <20260723022947.1569915-1-kudo3228@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 --- 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 =3D 0; =20 /* 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) >=3D sizeof(*p)) { p =3D (struct tipc_gap_ack_blks *)msg_data(hdr); sz =3D ntohs(p->len); /* Sanity check */ --=20 2.43.0