CVE-2026-80647 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix warning in poll cq direct mode
CQs allocated by ib_alloc_cq() always have a comp_handler. Though in direct mode this handler is never expected to be called, it is still called when the driver is reset, triggering the following WARN_ONCE():
Call trace: ib_cq_completion_direct+0x38/0x60 hns_roce_cq_completion+0x54/0x90 (hns_roce_hw_v2] hns_roce_handle_device_err+Ox1c8/0x340 [hns_roce_hw_v2]
hns_roce_hw_v2_uninit_instance.constprop.0+0x34/0x70 [hns_roce_hw_v2]
hns_roce_hw_v2_reset_notify+0xc4/0xe0 [hns_roce_hw_v2]
hclge_notify_roce_client+0x60/0xbc [hclge]
hclge_reset_rebuild+0x48/0x34c [hclge]
hclge_reset_subtask+0xcc/0xec [hclge]
hclge_reset_service_task+0x80/0x160 [hclge]
hclge_service_task+0x50/0x80 (hclge] process_one_work+0x1cc/0x4d0 worker_thread+0x154/0x414 kthread+0x104/0x144 ret_from_fork+0x10/0x18
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel vulnerability identified in the RDMA/hns subsystem involves an improper handling of completion queue callbacks during device reset operations. Completion queues, or CQs, are fundamental components in Remote Direct Memory Access (RDMA) architectures that manage the delivery of work request completions to user space applications. When a CQ is allocated via ib_alloc_cq(), it is initialized with a mandatory comp_handler function pointer. In direct mode operation, this handler is designed not to be invoked under normal circumstances because completion events are processed differently than in interrupt-driven or polling modes. However, the current implementation fails to account for edge cases where the driver undergoes a reset sequence, leading to an unexpected invocation of this callback and triggering a WARN_ONCE diagnostic message within the kernel log.
The technical flaw resides in the hns_roce_hw_v2 driver logic which does not adequately guard against calling the completion handler when the device is being uninitialized or reset. The call trace indicates that during a hardware error handling routine, specifically within hns_roce_handle_device_err and subsequent uninitialization steps, the system proceeds to invoke ib_cq_completion_direct. This function expects valid context but encounters conditions where it should not execute due to the state of the device. Consequently, this triggers a kernel warning intended for debugging purposes, which can clutter logs and potentially indicate deeper stability issues if left unresolved. The vulnerability stems from insufficient checks on the operational state of the CQ before invoking its completion handler during critical lifecycle events such as reset or teardown.
From an operational impact perspective, while this specific issue primarily manifests as a kernel warning rather than a direct security exploit like privilege escalation or remote code execution, it contributes to system instability and noise in diagnostic outputs. Frequent WARN_ONCE messages can obscure other important warnings and may lead administrators to overlook genuine issues. Furthermore, improper handling of resources during reset sequences could theoretically lead to race conditions or use-after-free scenarios if the completion handler attempts to access freed memory structures associated with the resetting device. This aligns with CWE-479, which describes a signal handler that does not recover from an asynchronous event, although in this context it is more accurately mapped to improper resource management during state transitions.
To mitigate this vulnerability, developers must implement robust checks within the completion queue handling logic to ensure that callbacks are only invoked when the device and associated structures are in a valid operational state. Specifically, adding guards before calling ib_cq_completion_direct can prevent execution during reset phases where the handler is not expected or safe to run. Additionally, ensuring proper synchronization between the driver's reset notification mechanisms and CQ lifecycle management will help maintain consistency across subsystems like hclge and hns_roce_hw_v2. This fix reinforces best practices in kernel development by preventing unintended side effects from asynchronous events during critical maintenance operations, thereby enhancing overall system reliability and reducing false positive alerts in security monitoring tools that might flag such warnings as indicators of compromise or instability.