In the Linux kernel, the following vulnerability has been resolved:
RDMA/ionic: Embed counter driver data in rdma_counter allocation
Commit 7e53b31acc7f ("RDMA/core: Create and destroy rdma_counter using
rdma_zalloc_drv_obj()") requires drivers implementing counter ops to
embed struct rdma_counter in a driver-specific struct, register its size
via INIT_RDMA_OBJ_SIZE, and provide a counter_init callback.
The ionic driver was merged without this adaptation, causing a NULL
pointer dereference in alloc_and_bind() since rdma_zalloc_drv_obj()
allocates zero bytes when size_rdma_counter is unset.
Consolidate struct ionic_counter into a new struct ionic_rdma_counter
that embeds struct rdma_counter, replace the xarray with a lightweight
ida for ID allocation, and add the required counter_init and
INIT_RDMA_OBJ_SIZE declarations.
BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.
In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it