Skip to main content

Linux Kernel EUVDEUVD-2026-48794

| CVE-2026-64450 CRITICAL
Out-of-bounds Read (CWE-125)
2026-07-25 Linux GHSA-j9hg-j7q4-chjv
Critical
Disputed · 9.1 Vendor: Linux
Share

Severity by source

Sources disagree (Medium–Critical)
Vendor (Linux) PRIMARY
9.1 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
vuln.today AI
6.5 MEDIUM

Trigger arrives from an established TIPC neighbour over the bearer (AV:A); no auth in TIPC (PR:N); over-read data is not returned to attacker (C:N) and the observed impact is a kernel crash (A:H).

3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0 AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
7.1 HIGH
AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H
Red Hat
5.5 MEDIUM
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 27, 2026 - 05:57 vuln.today
CVSS changed
Jul 27, 2026 - 05:22 NVD
9.1 (CRITICAL)
Patch available
Jul 25, 2026 - 11:18 EUVD
CVE Published
Jul 25, 2026 - 08:51 cve.org
CRITICAL 9.1
CVE Published
Jul 25, 2026 - 08:51 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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.

AnalysisAI

Out-of-bounds slab read in the Linux kernel TIPC (Transparent Inter-Process Communication) protocol lets a malicious TIPC neighbour trigger a heap over-read by sending a single crafted broadcast PROTOCOL/STATE_MSG carrying a Gap ACK blocks record. Affecting kernels 5.8 through the fixed stable releases, the broadcast path (tipc_bcast_sync_rcv → tipc_link_advance_transmq) fails to bound the Gap ACK record against the actual message data size, so kmemdup() copies up to 1024 bytes past a ~704-byte skb, corrupting/leaking adjacent slab memory and crashing the host (KASAN slab-out-of-bounds). No public exploit is identified at time of analysis and EPSS is low (0.22%), consistent with a niche, non-default kernel subsystem.

Technical ContextAI

TIPC is an optional Linux cluster/L2 messaging protocol. When two nodes negotiate the TIPC_GAP_ACK_BLOCK capability, STATE_MSG frames can carry a Gap ACK blocks record used for selective retransmission. tipc_get_gap_ack_blks() validates only internal self-consistency of the record - that its len equals struct_size(p, gacks, ugack_cnt + bgack_cnt) - but not that the record physically fits inside msg_data_sz() of the received skb. The unicast caller tipc_link_proto_rcv() enforces 'if (glen > dlen) break;', but the broadcast caller discarded the returned length, so tipc_link_advance_transmq() performed kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt), ...) with an attacker-chosen bgack_cnt (e.g. 0xff → 1024 bytes) against a much shorter buffer. This is a classic CWE-125 out-of-bounds read rooted in a missing length/bounds check on wire-controlled count fields (the 'Buffer Overflow' tag is loosely a read, not a write). CPE data identifies the affected component only generically as cpe:2.3:a:linux:linux:*.

RemediationAI

Vendor-released patch: upgrade to a fixed stable kernel - 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.96, 6.18.39, 7.1.4 or 7.2-rc2 (or your distribution's equivalent, e.g. the Ubuntu kernels in USN-8726-1 / USN-8727-1). The fix makes tipc_bcast_sync_rcv() bound the Gap ACK record against msg_data_sz() and drop the message (via tipc_node_bc_sync_rcv → tipc_rcv) when it does not fit, matching the unicast 'glen > dlen' behaviour. Where immediate patching is not possible and TIPC is not needed, the most effective compensating control is to prevent the TIPC module from loading (e.g. 'install tipc /bin/true' in modprobe.d and blacklisting it), which fully removes the attack surface with no side effect on systems that do not use TIPC clustering; if TIPC is required, restrict the TIPC bearer to trusted, isolated L2 segments/VLANs and trusted peer nodes to limit which neighbours can send STATE_MSGs. See https://git.kernel.org/stable/c/9a51115fcdc78687c8852bf93a1db3951dbb223b and https://nvd.nist.gov/vuln/detail/CVE-2026-64450.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

EUVD-2026-48794 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy