Cloudanix VulnDB

CVE-2026-98812

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in the Linux kernel's network device setup can make the whole computer crash when certain network messages are handled at the wrong moment.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race in mctp_add_dev leaves dev->mctp_ptr pointing to a partially-initialised mctp_dev whose ->dev field is still NULL; any concurrent reader under RCU (such as mctp_sendmsg path) performs a NULL pointer dereference.

Why it matters to the business

Kernel panic or denial-of-service on systems using MCTP networking; low exploitability and no observed campaigns mean operational impact is limited to availability of affected kernels until patched.

How an attack unfolds

An attacker with local or network access that can trigger MCTP socket operations while an mctp device is being registered causes the kernel to dereference the uninitialised pointer, crashing the system.

How to fix it

Apply the upstream fix that moves publication of the mctp_dev until after mdev->dev is assigned; rebuild and boot a patched kernel.

How to confirm the fix worked

Confirm the mctp_add_dev change that assigns mdev->dev before linking into dev->mctp_ptr is present in the running kernel source or binary; test that KASAN no longer reports the null dereference on device registration.

Typical attack path

  1. Create or open an MCTP socket
  2. Trigger concurrent mctp device registration (e.g., via netlink or hotplug)
  3. Perform sendmsg on the socket during the initialisation window
  4. Kernel follows NULL mdev->dev pointer and panics

How to detect it

Search kernel logs and crash dumps for KASAN null-ptr-deref traces containing mctp_sendmsg, mctp_dst_output or mctp_add_dev; correlate with recent MCTP device registration events.

What your security team should do

  • Prioritise kernel update on any system exposing MCTP sockets
  • Monitor for KASAN null-ptr-deref reports involving mctp_sendmsg or mctp_dst_output
  • Reassess after 30 days; low EPSS and absence from KEV indicate limited external threat

The record

In the Linux kernel, the following vulnerability has been resolved: net/mctp: publish the mctp_dev only after it is initialised mctp_add_dev() links the new mctp_dev into dev->mctp_ptr before mdev->dev is assigned, so a reader that picks the device up in that window dereferences a net_device pointer that is still NULL: KASAN: null-ptr-deref in range [0x00000000000000b0-0x00000000000000b7] Call Trace: <TASK> ? __pfx_mctp_sendmsg (./include/linux/sockptr.h:49) ? __pfx_mctp_dst_output (net/mctp/route.c:41) ? selinux_socket_sendmsg (security/selinux/hooks.c:5278) ____sys_sendmsg (net/socket.c:775 (discriminator 1) net/socket.c:790 (discriminator 1) net/socket.c:2684 (discriminator 1)) ? __pfx_____sys_sendmsg (net/socket.c:1131) ? __pfx_copy_msghdr_from_user (net/socket.c:2590) ? update_cfs_rq_load_avg (kernel/sched/fair.c:5478) ___sys_sendmsg (net/socket.c:2738) ? __pfx____sys_sendmsg (net/socket.c:2625) ? perf_event_task_tick (./include/linux/rcupdate.h:838) ? sched_tick (kernel/sched/core.c:5818) ? clockevents_program_event (kernel/time/clockevents.c:372) ? fdget (./include/linux/rcupdate.h:873 fs/file.c:1100) __sys_sendmsg (net/socket.c:2770) ? __pfx___sys_sendmsg (net/socket.c:2751) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) </TASK> Fix by publishing only once the object is fully initialised: __mctp_dev_get() runs under rcu_read_lock() only and hands this object to readers as soon as mctp_ptr is assigned, so they must never observe mdev->dev == NULL.

Affected packages

Ecosystem Package Introduced Fixed