CVE-2026-98812 in Linux
Summary
by MITRE • 10/18/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel vulnerability identified in the MCTP (Management Component Transport Protocol) subsystem represents a classic race condition arising from improper synchronization during device initialization. Specifically, within the net/mctp module, the function mctp_add_dev() exhibits a critical ordering flaw where it links the newly created mctp_dev structure into dev->mctp_ptr before ensuring that the internal member mdev->dev is fully assigned and initialized. This sequence error creates a narrow but exploitable window of time during which concurrent readers can access the device structure via RCU (Read-Copy-Update) mechanisms while the object remains in an inconsistent state. Because the reader logic assumes that once it retrieves the pointer from dev->mctp_ptr, the entire mctp_dev structure is valid and ready for use, this premature publication leads to a null-pointer dereference when code attempts to access members of the partially constructed object.
The operational impact of this flaw manifests as a kernel crash or denial of service, triggered by a local user space process attempting to send messages over an MCTP interface during its initialization phase. The provided Kernel Address Sanitizer trace confirms that the fault occurs in range 0x00000000000000b0-0x00000000000000b7, which corresponds to an offset within a struct where mdev->dev is expected but remains NULL. The call trace indicates that the crash occurs during socket send operations, specifically through selinux_socket_sendmsg and subsequent routing logic in net/mctp/route.c. This implies that any user with permission to open MCTP sockets can potentially trigger this condition if they time their requests correctly relative to device registration events, leading to system instability or a complete kernel panic depending on the specific memory layout and security modules active at the time of execution.
From a vulnerability classification perspective, this issue aligns closely with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'). The root cause is not merely a lack of locking but rather an incorrect ordering of operations that violates the atomicity requirements for publishing shared data structures to concurrent readers. In terms of the MITRE ATT&CK framework, this vulnerability facilitates Local Privilege Escalation or Denial of Service by allowing unprivileged users to crash the kernel through carefully timed network socket interactions. The flaw highlights a common pitfall in Linux kernel development where RCU read-side critical sections are used for performance but require strict adherence to initialization protocols to prevent accessing uninitialized memory regions.
The resolution involves correcting the publication logic within the MCTP device management code by ensuring that __mctp_dev_get() only hands the object to readers after mdev->dev has been fully initialized and assigned. By publishing the pointer only once the entire structure is valid, the race window is eliminated because any reader acquiring a reference under rcu_read_lock will guarantee that all fields within the struct are populated correctly. To mitigate this vulnerability in environments where kernel updates may be delayed, administrators should ensure that MCTP interfaces are not actively used or monitored during system boot sequences when network device drivers are registering and initializing. Furthermore, deploying runtime security tools such as SELinux with strict policies can help contain potential exploitation attempts by restricting socket operations for unprivileged processes until the relevant subsystems are confirmed to be fully operational.