CVE-2026-23384 in Linux
Summary
by MITRE • 03/25/2026
In the Linux kernel, the following vulnerability has been resolved:
RDMA/ionic: Fix kernel stack leak in ionic_create_cq()
struct ionic_cq_resp resp {
__u32 cqid[2]; // offset 0 - PARTIALLY SET (see below)
__u8 udma_mask; // offset 8 - SET (resp.udma_mask = vcq->udma_mask) __u8 rsvd[7]; // offset 9 - NEVER SET <- LEAK
};
rsvd[7]: 7 bytes of stack memory leaked unconditionally.
cqid[2]: The loop at line 1256 iterates over udma_idx but skips indices
where !(vcq->udma_mask & BIT(udma_idx)). The array has 2 entries but udma_count could be 1, meaning cqid[1] might never be written via
ionic_create_cq_common(). If udma_mask only has bit 0 set, cqid[1] (4
bytes) is also leaked. So potentially 11 bytes leaked.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 03/31/2026
The vulnerability identified as CVE-2026-23384 resides within the Linux kernel's RDMA/ionic driver component, specifically in the ionic_create_cq() function where a kernel stack memory leak occurs due to improper handling of uninitialized memory regions. This issue represents a classic case of information disclosure through memory leakage, where sensitive data remnants from previous operations may persist in stack memory locations that are not properly initialized before use. The flaw manifests when processing completion queue responses where certain memory regions are allocated on the kernel stack but remain uninitialized, creating potential security implications for systems utilizing RDMA networking capabilities.
The technical implementation reveals a structured memory layout issue within the ionic_cq_resp data structure where the rsvd[7] array of seven bytes is never explicitly set during function execution, creating a consistent 7-byte leakage of kernel stack memory. Additionally, the cqid[2] array demonstrates conditional initialization problems where a loop iteration process only populates array elements based on specific bitmask conditions. When the udma_mask contains only bit 0 set, the second array element cqid[1] remains uninitialized, adding an additional 4 bytes of leakage to the total memory exposure. This dual-layer memory leak occurs because the ionic_create_cq_common() function does not guarantee initialization of all array elements, particularly when the udma_count parameter is less than the allocated array size.
The operational impact of this vulnerability extends beyond simple memory leakage to potentially expose sensitive kernel data to unauthorized access, particularly in environments where RDMA networking is actively utilized for high-performance computing or data center operations. The memory leakage could inadvertently reveal information about kernel memory layout, previous operations, or system state that might aid attackers in developing more sophisticated exploitation techniques. Systems running affected kernel versions with active RDMA operations are particularly vulnerable as the leakage occurs during normal operational procedures, making detection difficult and potentially enabling persistent reconnaissance activities. The vulnerability's presence in the kernel's core networking stack means that any process utilizing the ionic driver for completion queue creation could contribute to memory leakage, amplifying the potential impact across multiple system components.
Mitigation strategies should prioritize immediate kernel updates to versions containing the patched implementation, which addresses the uninitialized memory handling through proper initialization of all stack variables. System administrators should implement monitoring solutions to detect unusual memory access patterns or potential exploitation attempts targeting kernel memory structures. The vulnerability aligns with CWE-1230 which specifically addresses improper initialization of memory in kernel space, and its exploitation patterns correspond to ATT&CK techniques related to privilege escalation and information gathering through kernel memory reconnaissance. Organizations should also consider implementing kernel memory protection mechanisms such as stack canaries and memory randomization techniques to reduce the effectiveness of potential exploitation attempts. Additionally, regular security audits of kernel modules and driver implementations should be conducted to identify similar initialization issues that may not have been explicitly documented in public vulnerability databases.