CVE-2026-98252

What it actually does

Race condition in RDMA core where refcount for nlmsg_request is initialized after list_add_tail(), allowing concurrent kref_get() on a zero-initialized object and causing refcount underflow or kernel panic.

Why it matters to the business

Local attackers on affected Linux systems can trigger kernel crashes or memory corruption in RDMA/iWARP workloads, leading to denial of service or potential privilege escalation on servers handling high-performance networking.

How an attack unfolds

An attacker with local access crafts a sequence of RDMA operations that invokes iwpm_get_nlmsg_request() concurrently across CPUs. Because initialization occurs after the object is visible on a global list, a second CPU performs kref_get() before the refcount is set, triggering the addition-on-zero bug and destabilizing the kernel.

How to fix it

Upgrade to a Linux kernel version containing the fix that moves kref initialization and full field setup before list_add_tail() in iwpm_get_nlmsg_request(). Apply the patch from the RDMA subsystem or the next stable kernel release after 2026-10-06.

How to confirm the fix worked

Confirm the source change moves kref_init() and all field initialization ahead of list_add_tail() in iwpm_get_nlmsg_request(); verify the updated kernel boots and RDMA workloads no longer trigger refcount warnings under concurrent load.

Typical attack path

1. Obtain local user access on a Linux host using RDMA/iWARP
2. Trigger concurrent calls to iwpm_get_nlmsg_request() via crafted RDMA netlink or socket operations
3. Exploit the window between list_add_tail() and kref initialization to cause refcount corruption
4. Escalate to kernel panic, memory corruption, or code execution

How to detect it

Review kernel logs for refcount underflow warnings or oops traces mentioning iwpm_get_nlmsg_request or nlmsg_request; inspect RDMA netlink traffic and process activity around the time of any crash.

What your security team should do

• Prioritize kernel updates on systems exposing RDMA/iWARP interfaces
• Restrict local access and RDMA capabilities to trusted users until patched
• Monitor for kernel oops or refcount warnings in RDMA paths
• Test updated kernels in staging environments with RDMA workloads before broad deployment