CVE-2023-53286
published 2025-09-16CVE-2023-53286: In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Return the firmware result upon destroying QP/RQ Previously when destroying a…
PriorityP340high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.14%
3.9th percentile
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Return the firmware result upon destroying QP/RQ
Previously when destroying a QP/RQ, the result of the firmware
destruction function was ignored and upper layers weren't informed
about the failure.
Which in turn could lead to various problems since when upper layer
isn't aware of the failure it continues its operation thinking that the
related QP/RQ was successfully destroyed while it actually wasn't,
which could lead to the below kernel WARN.
Currently, we return the correct firmware destruction status to upper
layers which in case of the RQ would be mlx5_ib_destroy_wq() which
was already capable of handling RQ destruction failure or in case of
a QP to destroy_qp_common(), which now would actually warn upon qp
destruction failure.
WARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]
Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse
CPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]
Code: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f
RSP: 0018:ffff8881533e3e78 EFLAGS: 00010287
RAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000
RDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0
RBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009
R10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780
R13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000
FS:
Affected
15 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.52-1 (bookworm) | linux 6.1.52-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 333fbaa0255b8d471fc7ae767ef3a1766c732d6d < 73311dd831858d797cf8ebe140654ed519b41c36 | 73311dd831858d797cf8ebe140654ed519b41c36 |
| linux | linux | >= 333fbaa0255b8d471fc7ae767ef3a1766c732d6d < 1a650d3ccd79cdd5796edd864683a6b8dd0bf576 | 1a650d3ccd79cdd5796edd864683a6b8dd0bf576 |
| linux | linux | >= 333fbaa0255b8d471fc7ae767ef3a1766c732d6d < 5fe7815e784bf21061885f8112a7108aef5c45bd | 5fe7815e784bf21061885f8112a7108aef5c45bd |
| linux | linux | >= 333fbaa0255b8d471fc7ae767ef3a1766c732d6d < 04704c201bb08efaf96d7b1396c6864f8984e244 | 04704c201bb08efaf96d7b1396c6864f8984e244 |
| linux | linux | >= 333fbaa0255b8d471fc7ae767ef3a1766c732d6d < 22664c06e997087fe37f9ba208008c948571214a | 22664c06e997087fe37f9ba208008c948571214a |
| linux | linux_kernel | < 5.10.192 | 5.10.192 |
| linux | linux_kernel | >= 0 < 5.10.197-1 | 5.10.197-1 |
| linux | linux_kernel | >= 0 < 6.1.52-1 | 6.1.52-1 |
| linux | linux_kernel | >= 0 < 6.4.13-1 | 6.4.13-1 |
| linux | linux_kernel | >= 0 < 6.4.13-1 | 6.4.13-1 |
| linux | linux_kernel | >= 5.11 < 5.15.128 | 5.15.128 |
| linux | linux_kernel | >= 5.16 < 6.1.47 | 6.1.47 |
| linux | linux_kernel | >= 6.2 < 6.4.12 | 6.4.12 |
CVSS provenance
nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.8HIGH
vendor_debian7.8HIGH
vendor_redhat7.8HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
CVE-2023-53286: In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Return the firmware result upon destroying QP/RQ Previously when destro
osv·2025-09-16·CVSS 7.8
CVE-2023-53286 [HIGH] CVE-2023-53286: In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Return the firmware result upon destroying QP/RQ Previously when destro
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Return the firmware result upon destroying QP/RQ Previously when destroying a QP/RQ, the result of the firmware destruction function was ignored and upper layers weren't informed about the failure. Which in turn could lead to various problems since when upper layer isn't aware of the failure it continues its operation thinking that the related QP/RQ was successfully destroyed while it actually wasn't, which could lead to the below kernel WARN. Currently, we return the correct firmware destruction status to upper layers which in case of the RQ would be mlx5_ib_destroy_wq() which was already capable of handling RQ destruction failure or in case of a QP to destroy_qp_common(), which now would actually warn upon qp
GHSA
GHSA-fvfh-cc4q-w5cr: In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Return the firmware result upon destroying QP/RQ
Previously when dest
ghsa_unreviewed·2025-09-16
CVE-2023-53286 [HIGH] GHSA-fvfh-cc4q-w5cr: In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Return the firmware result upon destroying QP/RQ
Previously when dest
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Return the firmware result upon destroying QP/RQ
Previously when destroying a QP/RQ, the result of the firmware
destruction function was ignored and upper layers weren't informed
about the failure.
Which in turn could lead to various problems since when upper layer
isn't aware of the failure it continues its operation thinking that the
related QP/RQ was successfully destroyed while it actually wasn't,
which could lead to the below kernel WARN.
Currently, we return the correct firmware destruction status to upper
layers which in case of the RQ would be mlx5_ib_destroy_wq() which
was already capable of handling RQ destruction failure or in case of
a QP to destroy_qp_common(), which now would actually warn upon
Red Hat
kernel: RDMA/mlx5: Return the firmware result upon destroying QP/RQ
vendor_redhat·2025-09-16·CVSS 7.8
CVE-2023-53286 [HIGH] CWE-703 kernel: RDMA/mlx5: Return the firmware result upon destroying QP/RQ
kernel: RDMA/mlx5: Return the firmware result upon destroying QP/RQ
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Return the firmware result upon destroying QP/RQ
Previously when destroying a QP/RQ, the result of the firmware
destruction function was ignored and upper layers weren't informed
about the failure.
Which in turn could lead to various problems since when upper layer
isn't aware of the failure it continues its operation thinking that the
related QP/RQ was successfully destroyed while it actually wasn't,
which could lead to the below kernel WARN.
Currently, we return the correct firmware destruction status to upper
layers which in case of the RQ would be mlx5_ib_destroy_wq() which
was already capable of handling RQ destruction failure or in case o
Debian
CVE-2023-53286: linux - In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: ...
vendor_debian·2023·CVSS 7.8
CVE-2023-53286 [HIGH] CVE-2023-53286: linux - In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: ...
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Return the firmware result upon destroying QP/RQ Previously when destroying a QP/RQ, the result of the firmware destruction function was ignored and upper layers weren't informed about the failure. Which in turn could lead to various problems since when upper layer isn't aware of the failure it continues its operation thinking that the related QP/RQ was successfully destroyed while it actually wasn't, which could lead to the below kernel WARN. Currently, we return the correct firmware destruction status to upper layers which in case of the RQ would be mlx5_ib_destroy_wq() which was already capable of handling RQ destruction failure or in case of a QP to destroy_qp_common(), which now would actually warn upon qp
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/04704c201bb08efaf96d7b1396c6864f8984e244https://git.kernel.org/stable/c/1a650d3ccd79cdd5796edd864683a6b8dd0bf576https://git.kernel.org/stable/c/22664c06e997087fe37f9ba208008c948571214ahttps://git.kernel.org/stable/c/5fe7815e784bf21061885f8112a7108aef5c45bdhttps://git.kernel.org/stable/c/73311dd831858d797cf8ebe140654ed519b41c36
2025-09-16
Published