CVE-2026-98252 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
RDMA/core: fix refcount bug in iwpm_get_nlmsg_request()
iwpm_get_nlmsg_request() initializes refcount _after_ list_add_tail() making it accessible to global list where another CPU can kref_get() on nlmsg_request causing a refcount "addition on 0" bug. Fix this by initializing kref _before_ list_add_tail() so refcount for nlmsg_request can be incremented/decremented normally. In addition, also initialize every field before list_add_tail().
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in the Linux kernel's RDMA core subsystem involves a critical race condition within the iwpm_get_nlmsg_request function, which is responsible for handling Netlink messages related to InfiniBand Verbs Protocol Manager operations. This flaw stems from an improper initialization sequence where the reference count of the nlmsg_request structure is initialized after it has already been added to a global list via list_add_tail. By placing the object into the shared data structure before establishing its internal state, specifically the kernel reference counting mechanism (kref), the code exposes the entry to concurrent access by other CPU cores that may attempt to increment or manage this reference count prematurely.
From a technical perspective, this ordering error results in what is classified as CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, specifically manifesting as a race condition during object lifecycle management. When another thread invokes kref_get on the nlmsg_request entry while it resides in the global list but before its refcount field has been properly initialized to one, the kernel attempts to perform an atomic addition operation on memory that contains uninitialized or zeroed data. This leads to a logical error where the reference count is effectively added to zero rather than incremented from its intended initial value of one, corrupting the internal accounting of object lifetime and potentially leading to premature deallocation or use-after-free scenarios if subsequent operations rely on this corrupted state.
The operational impact of this vulnerability extends beyond simple logic errors in refcounting. In a multi-core environment typical of modern server hardware processing high-throughput RDMA traffic, such race conditions can lead to kernel panics, system instability, or denial of service due to the corruption of critical memory management structures. Furthermore, if an attacker can influence the timing of these operations through crafted Netlink messages, they might exploit this window to manipulate object lifecycles in ways that could facilitate privilege escalation or arbitrary code execution, although the primary immediate risk is system stability and integrity. This aligns with ATT&CK techniques related to resource manipulation and potential exploitation of race conditions for persistence or impact.
To mitigate this vulnerability, it is imperative to enforce strict ordering during object initialization within kernel subsystems handling shared resources. The fix involves moving the kref_init call and the initialization of all other fields in nlmsg_request to occur before the list_add_tail operation that inserts the structure into the global list. This ensures that any concurrent access by other CPUs will interact with a fully initialized and valid object, preventing undefined behavior associated with uninitialized memory reads or incorrect arithmetic on reference counts. Developers should adopt defensive programming practices where resource acquisition and initialization are completed atomically relative to their exposure in shared data structures, thereby eliminating the race window entirely.