Description

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().

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.0",
  "pubDate": "2026-10-06T09:18:13.723Z",
  "pubdate": "2026-10-06T09:18:13.723Z",
  "executiveSummary": "This vulnerability is a race condition in the Linux kernel RDMA subsystem that leads to a reference count underflow or 'addition on zero' bug.\nThe issue exists within the iwpm_get_nlmsg_request() function, which handles Netlink message requests.\nThe vulnerability allows for potential use-after-free conditions or memory corruption, as the object is exposed to a global list before its reference counter is properly initialized.\nAn attacker capable of triggering concurrent Netlink operations could potentially exploit this race condition to induce kernel memory instability or escalate privileges.\nThe flaw affects the RDMA core infrastructure, specifically impacting the lifecycle management of nlmsg_request objects.\nThis is a high-severity concurrency flaw that requires precise timing, but it poses significant risks to system stability and security integrity in environments relying on RDMA network acceleration.",
  "technicalDetails": "The root cause of this vulnerability is an improper order of operations within the iwpm_get_nlmsg_request() function in the Linux kernel RDMA core. The function creates and initializes an nlmsg_request object to track Netlink message states.\nIn the vulnerable implementation, the object is added to a global tracking list via list_add_tail() before the kref (reference counter) structure is initialized. By performing the list insertion prior to kref_init(), the object becomes visible and reachable by other kernel threads and concurrent processes while its internal state is still indeterminate.\nThe attack flow occurs through a race condition: 1) Thread A enters iwpm_get_nlmsg_request(), allocates the object, and executes list_add_tail(). 2) Before Thread A executes kref_init(), Thread B triggers an operation that iterates over the global list and identifies the newly created, but uninitialized, nlmsg_request object. 3) Thread B attempts to increment the object's reference count using kref_get(). 4) Because the refcount has not yet been set to its initial value (effectively remaining at zero or undefined), the kref_get() operation triggers a refcount 'addition on 0' bug.\nThis behavior violates the kref API safety requirements, which dictate that an object must be fully constructed and have a non-zero reference count before being published to any shared structures or lists. Exploitation of this race condition can lead to kernel-level memory corruption, as the system may prematurely free the object while other threads still possess references, or conversely, leak memory if the counter never reaches zero due to the corrupted initial state.\nBecause the RDMA core handles specialized networking traffic, this flaw is particularly dangerous for systems leveraging iWARP (Internet Wide-area RDMA Protocol). The vulnerability resides strictly in the kernel memory management of Netlink requests, and while exploitation requires the ability to trigger RDMA-related Netlink traffic, it does not necessarily require highly elevated privileges depending on the system configuration and the exposure of the RDMA management interface to user-space applications."
}