CVE-2023-52486

MEDIUM
Published Mar 11, 2024 Modified Jan 14, 2025 CWE-667

Description

In the Linux kernel, the following vulnerability has been resolved: drm: Don't unref the same fb many times by mistake due to deadlock handling If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit.

Is your site exposed to CVE-2023-52486?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

5.5
MEDIUM
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Weakness Type (CWE)

CWE-667 CWE-667

Affected Products

Vendor Product
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel
linux linux_kernel

References

Advisories & Patches

https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229 https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0 https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7 https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551 https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105 https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229 https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0 https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7 https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551 https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105

Frequently Asked Questions

What is CVE-2023-52486? +
In the Linux kernel, the following vulnerability has been resolved: drm: Don't unref the same fb many times by mistake due to deadlock handling If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit. It has a CVSS v3.1 base score of 5.5 (MEDIUM).
How severe is CVE-2023-52486? +
CVE-2023-52486 has a CVSS v3.1 score of 5.5 out of 10, rated MEDIUM. This is a medium-severity vulnerability that should be remediated as part of regular maintenance.
What products are affected by CVE-2023-52486? +
CVE-2023-52486 affects products from linux, specifically: linux_kernel. Check the affected products table above for specific version ranges.
How do I check if I'm vulnerable to CVE-2023-52486? +
You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2025-1221

A Zigbee Radio Co-Processor (RCP), which is using SiLabs EmberZNet Zigbee stack, was unable to send messages to the host …
CVE-2025-10151

Improper locking vulnerability in Softing Industrial Automation GmbH gateways allows infected memory and/or resource leak exposure.This issue affects smartLink HW-PN: …
CVE-2026-54906 9.8

concurrent-ruby is a modern concurrency tools for Ruby. Prior to 1.3.7, Concurrent::ReadWriteLock#release_write_lock does not verify that the calling thread acquired …
CVE-2026-43215 8.8

In the Linux kernel, the following vulnerability has been resolved: cifs: Fix locking usage for tcon fields We used to …
CVE-2026-31629 8.8

In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED checks In nfc_llcp_recv_hdlc() …
CVE-2026-62426 8.8

[This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] To manage the …

Don't wait for an exploit

Scan your website for vulnerabilities like CVE-2023-52486 — free, no signup required.