Cloudanix VulnDB

CVE-2026-98525

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's MCTP networking code lets one program in the same network setup steal a reserved communication tag that belongs to another program, which can break their ability to send messages.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Privilege Gain
Component
OS kernel
Class
Authorization Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The mctp_lookup_prealloc_tag function iterates the network-namespace-wide keys list instead of a socket's private sklist, allowing any MCTP socket in the same namespace to match and consume another socket's manually preallocated tag when MCTP_TAG_PREALLOC is used.

Why it matters to the business

Sockets belonging to different applications or containers sharing a network namespace can interfere with each other's MCTP tag allocations, potentially disrupting management or control-plane traffic that relies on preallocated tags.

How an attack unfolds

An attacker opens a second MCTP socket in the same network namespace, allocates a tag on the victim socket via SIOCMCTPALLOCTAG, then transmits a packet using the victim's preallocated tag value; the lookup succeeds on the attacker socket and consumes the tag, causing subsequent legitimate sends from the victim to fail.

How to fix it

Apply the upstream kernel patch that changes mctp_lookup_prealloc_tag to walk &msk->keys via sklist instead of the namespace-wide list; rebuild and deploy the fixed kernel image to all affected hosts.

How to confirm the fix worked

Reproduce the QEMU test case: allocate a manual tag on socket A, attempt sendto from socket B using the same tag; confirm sendto fails with ENOENT on the unfixed kernel and that only the owning socket succeeds after the patch.

Typical attack path

  1. Create two MCTP sockets inside the same network namespace
  2. Use SIOCMCTPALLOCTAG on the first socket to reserve a tag for a specific peer
  3. From the second socket, call sendto with MCTP_TAG_PREALLOC set to the same tag value
  4. The lookup matches the namespace-wide list and returns the first socket's tag entry
  5. The tag is consumed, subsequent legitimate transmissions from the first socket fail with ENOENT

How to detect it

Inspect kernel logs and application logs for repeated ENOENT errors on MCTP sendto calls that previously succeeded; correlate with processes creating multiple MCTP sockets in the same network namespace.

What your security team should do

  • Prioritize kernel update on systems that use MCTP sockets with preallocated tags
  • Audit network-namespace configurations to reduce sharing of MCTP sockets between unrelated processes
  • Monitor for kernel updates containing the mctp route tag list fix

The record

In the Linux kernel, the following vulnerability has been resolved: mctp: route: iterate socket tag list in mctp_lookup_prealloc_tag() When a socket transmits a packet with MCTP_TAG_PREALLOC set, mctp_lookup_prealloc_tag() iterates over the per-netns &mns->keys list and matches netid, req_tag, peer_addr, and manual_alloc, without checking whether tmp->sk == &msk->sk. This allows any MCTP socket in the same network namespace to use and consume another socket's preallocated tag. Iterate the socket's own tag list (&msk->keys via sklist) instead of the namespace-wide &mns->keys list in mctp_lookup_prealloc_tag(), ensuring that only tags allocated by msk are matched. Tested in QEMU against Linux 7.3.0-rc3 by allocating a manual tag (0x18) on socket A via SIOCMCTPALLOCTAG for peer EID 9 and sending a 4-byte message with MCTP_TAG_PREALLOC from socket B in the same network namespace. On the unfixed kernel, sendto(sock_b) using socket A's preallocated tag succeeds (ret = 4); with this patch applied, sendto(sock_b) fails with -ENOENT (errno = 2) while sendto(sock_a) succeeds (ret = 4).

Affected packages

Ecosystem Package Introduced Fixed