---
id: "CVE-2026-98812"
kind: "vulnerability"
aliases: ["CVE-2026-98812"]
title: "Linux kernel: MCTP device publication race causes null-pointer dereference"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["infrastructure", "kernel", "linux", "mctp", "networking"]
not_affected_if: ["mctp-not-loaded"]
published_at: "2026-10-18T16:17:35+00:00"
first_seen_at: "2026-10-23T21:57:17+00:00"
updated_at: "2026-10-25T05:14:52+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98812", "first_seen_at": "2026-10-23T21:57:17+00:00"}]
---

# Linux kernel: MCTP device publication race causes null-pointer dereference

In the Linux kernel's MCTP networking code, a new MCTP device can be made visible to readers before its net_device pointer is set, so a concurrent sender dereferences NULL and crashes the kernel. The sources do not state a confirmed code-execution or privilege-escalation path.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `uname -r` and compare against the fixed kernel versions listed in the NVD entry (unknown in the sources).
- Check whether the MCTP protocol is in use with `lsmod | grep mctp` or `ls /proc/net/mctp` (unknown in the sources whether this is the exact check).

## Fix

- Update the Linux kernel to a release containing the upstream commit that publishes the mctp_dev only after initialisation; the fixed version numbers are unknown in the sources.

## Timeline

- 2026-10-23T21:57:17+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98812

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_