CVE-2024-35902

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: fix possible cp null dereference<br /> <br /> cp might be null, calling cp-&gt;cp_conn would produce null dereference<br /> <br /> [Simon Horman adds:]<br /> <br /> Analysis:<br /> <br /> * cp is a parameter of __rds_rdma_map and is not reassigned.<br /> <br /> * The following call-sites pass a NULL cp argument to __rds_rdma_map()<br /> <br /> - rds_get_mr()<br /> - rds_get_mr_for_dest<br /> <br /> * Prior to the code above, the following assumes that cp may be NULL<br /> (which is indicative, but could itself be unnecessary)<br /> <br /> trans_private = rs-&gt;rs_transport-&gt;get_mr(<br /> sg, nents, rs, &amp;mr-&gt;r_key, cp ? cp-&gt;cp_conn : NULL,<br /> args-&gt;vec.addr, args-&gt;vec.bytes,<br /> need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);<br /> <br /> * The code modified by this patch is guarded by IS_ERR(trans_private),<br /> where trans_private is assigned as per the previous point in this analysis.<br /> <br /> The only implementation of get_mr that I could locate is rds_ib_get_mr()<br /> which can return an ERR_PTR if the conn (4th) argument is NULL.<br /> <br /> * ret is set to PTR_ERR(trans_private).<br /> rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.<br /> Thus ret may be -ENODEV in which case the code in question will execute.<br /> <br /> Conclusion:<br /> * cp may be NULL at the point where this patch adds a check;<br /> this patch does seem to address a possible bug