PT-2026-64671 · Linux · Linux
CVE-2026-64450
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix out-of-bounds read in broadcast Gap ACK blocks
A broadcast PROTOCOL/STATE MSG can carry a Gap ACK blocks record in its
data area. tipc get gap ack blks() only verifies that the record's len
field is self-consistent with its ugack cnt/bgack cnt counts
(sz == struct size(p, gacks, ugack cnt + bgack cnt)); it does not check
that the record actually fits in the message data area, msg data sz().
The unicast caller tipc link proto rcv() bounds it ("if (glen > dlen)
break;"), but the broadcast caller tipc bcast sync rcv() discards the
returned size, so tipc link advance transmq() copies the record off the
receive skb with an attacker-controlled count:
this ga = kmemdup(ga, struct size(ga, gacks, ga->bgack cnt),
GFP ATOMIC);A TIPC neighbour that negotiated TIPC GAP ACK BLOCK triggers it with one
ordinary broadcast STATE MSG (msg bc ack invalid() clear), sized so its
data area is short, carrying a Gap ACK record with len = 0x400,
bgack cnt = 0xff and ugack cnt = 0. len then equals
struct size(p, gacks, 255), so the consistency check passes and ga is
non-NULL; kmemdup() reads struct size(ga, gacks, 255) = 1024 bytes out
of the much smaller skb:
BUG: KASAN: slab-out-of-bounds in kmemdup noprof+0x48/0x60
Read of size 1024 at addr ffff0000c7030d38 by task poc864/69
Call trace:
kmemdup noprof+0x48/0x60
tipc link advance transmq+0x86c/0xb80
tipc link bc ack rcv+0x19c/0x1e0
tipc bcast sync rcv+0x1c4/0x2c4
tipc rcv+0x85c/0x1340
tipc l2 rcv msg+0xac/0x104
The buggy address belongs to the object at ffff0000c7030d00
which belongs to the cache skbuff small head of size 704
The buggy address is located 56 bytes inside of
allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0)
The copied-out bytes are subsequently consumed as gap/ack values, but
the read is already out of bounds at the kmemdup() regardless of how
they are used.
The unicast STATE path drops such a message: "if (glen > dlen) break;"
skips the rest of STATE MSG handling and the skb is freed. Make the
broadcast path drop it too. tipc bcast sync rcv() now bounds the record
against msg data sz() and, when it does not fit, reports it back through
tipc node bc sync rcv() to tipc rcv() so the skb is discarded rather than
processed. ga is not cleared on this path: ga == NULL already means
"legacy peer without Selective ACK", a distinct legitimate state.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux