DEBIAN-CVE-2026-64450

In the Linux kernel, the following vulnerability has been resolved:  tipc: fix out-of-bounds read in broadcast Gap ACK blocks  A broadcast PROTOCOL/STATEMSG can carry a Gap ACK blocks record in its data area. tipcgetgapackblks() only verifies that the record's len field is self-consistent with its ugackcnt/bgackcnt counts (sz == structsize(p, gacks, ugackcnt + bgackcnt)); it does not check that the record actually fits in the message data area, msgdatasz().  The unicast caller tipclinkprotorcv() bounds it ("if (glen > dlen) break;"), but the broadcast caller tipcbcastsyncrcv() discards the returned size, so tipclinkadvancetransmq() copies the record off the receive skb with an attacker-controlled count:   thisga = kmemdup(ga, structsize(ga, gacks, ga->bgackcnt),   GFPATOMIC);  A TIPC neighbour that negotiated TIPCGAPACKBLOCK triggers it with one ordinary broadcast STATEMSG (msgbcackinvalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgackcnt = 0xff and ugackcnt = 0. len then equals structsize(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads structsize(ga, gacks, 255) = 1024 bytes out of the much smaller skb:    BUG: KASAN: slab-out-of-bounds in kmemdupnoprof+0x48/0x60   Read of size 1024 at addr ffff0000c7030d38 by task poc864/69   Call trace:    kmemdupnoprof+0x48/0x60    tipclinkadvancetransmq+0x86c/0xb80    tipclinkbcackrcv+0x19c/0x1e0    tipcbcastsyncrcv+0x1c4/0x2c4    tipcrcv+0x85c/0x1340    tipcl2rcvmsg+0xac/0x104   The buggy address belongs to the object at ffff0000c7030d00    which belongs to the cache skbuffsmallhead 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 STATEMSG handling and the skb is freed. Make the broadcast path drop it too. tipcbcastsyncrcv() now bounds the record against msgdatasz() and, when it does not fit, reports it back through tipcnodebcsyncrcv() 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.