CVE-2026-23335

What it actually does

The irdma_create_user_ah function returns an uninitialized 4-byte reserved field from the stack in the irdma_create_ah_resp structure to userspace, unconditionally leaking kernel stack memory.

Why it matters to the business

Local users on affected Linux systems may obtain small fragments of kernel memory contents, raising the risk of sensitive data exposure that could aid further attacks; widespread use of the Linux kernel increases organizational exposure until patches are applied.

How an attack unfolds

A local attacker invokes the RDMA user-space API to create an address handle, triggering irdma_create_user_ah which copies the partially uninitialized response structure back to the caller, allowing the leaked stack bytes to be read from the returned data buffer.

How to fix it

Update to a Linux kernel version containing the fix for the stack leak in irdma_create_user_ah; rebuild and deploy the patched kernel across all affected systems; disable RDMA/irdma interfaces where the functionality is not required.

How to confirm the fix worked

Confirm the presence of the zero-initialization of the rsvd array in irdma_create_user_ah before the call to ib_respond_udata; run kernel regression tests exercising RDMA address handle creation and verify no uninitialized bytes appear in the user response.

Typical attack path

1. Obtain local user access on a Linux system with RDMA/irdma support enabled
2. Load or ensure the irdma driver is present
3. Call ibv_create_ah or equivalent RDMA user verbs that reach irdma_create_user_ah
4. Inspect the ah_id response buffer to extract the four leaked stack bytes

How to detect it

Review kernel source or running binary for the uninitialized rsvd field copy in RDMA address handle creation paths; inspect user-space RDMA response buffers for unexpected non-zero values beyond the documented ah_id field; no reliable post-exploitation artifacts exist because the leak is passive.

What your security team should do

• Prioritize kernel updates on systems exposing RDMA interfaces
• Apply vendor-supplied patches as soon as they become available
• Restrict RDMA access to trusted processes via capabilities or cgroups
• Monitor for future CVEs in the irdma driver given its history of similar issues