Direct naar de inhoud
⚡ Kritieke cyberalerts voor jouw sector & systemen — direct in je inbox. Aanmelden →
cybernieuws.nl Cybersecurity en informatiebeveiling nieuws alerts live · 9 min 173 bronnen 2 kritiek 39 vandaag
CVE's Videos Dagbriefing

← Terug naar CVE-database

CVE-2024-35902

MEDIUM · 5.5 CVSS Gepubliceerd: CWE-476

Beschrijving NL

In the Linux kernel, the following vulnerability has been resolved:

net/rds: fix possible cp null dereference

cp might be null, calling cp->cp_conn would produce null dereference

[Simon Horman adds:]

Analysis:

* cp is a parameter of __rds_rdma_map and is not reassigned. * The following call-sites pass a NULL cp argument to __rds_rdma_map()

- rds_get_mr()
- rds_get_mr_for_dest

* Prior to the code above, the following assumes that cp may be NULL
(which is indicative, but could itself be unnecessary)

trans_private = rs->rs_transport->get_mr(
sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL,
args->vec.addr, args->vec.bytes,
need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);

* The code modified by this patch is guarded by IS_ERR(trans_private),
where trans_private is assigned as per the previous point in this analysis. The only implementation of get_mr that I could locate is rds_ib_get_mr()
which can return an ERR_PTR if the conn (4th) argument is NULL. * ret is set to PTR_ERR(trans_private). rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL. Thus ret may be -ENODEV in which case the code in question will execute. Conclusion:
* cp may be NULL at the point where this patch adds a check;
this patch does seem to address a possible bug

Origineel (Engels) tonen

In the Linux kernel, the following vulnerability has been resolved:

net/rds: fix possible cp null dereference

cp might be null, calling cp->cp_conn would produce null dereference

[Simon Horman adds:]

Analysis:

* cp is a parameter of __rds_rdma_map and is not reassigned.

* The following call-sites pass a NULL cp argument to __rds_rdma_map()

- rds_get_mr()
- rds_get_mr_for_dest

* Prior to the code above, the following assumes that cp may be NULL
(which is indicative, but could itself be unnecessary)

trans_private = rs->rs_transport->get_mr(
sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL,
args->vec.addr, args->vec.bytes,
need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);

* The code modified by this patch is guarded by IS_ERR(trans_private),
where trans_private is assigned as per the previous point in this analysis.

The only implementation of get_mr that I could locate is rds_ib_get_mr()
which can return an ERR_PTR if the conn (4th) argument is NULL.

* ret is set to PTR_ERR(trans_private).
rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.
Thus ret may be -ENODEV in which case the code in question will execute.

Conclusion:
* cp may be NULL at the point where this patch adds a check;
this patch does seem to address a possible bug

Vendors

Linux Debian

Affected products

Linux Kernel Debian Linux

References