CVE-2025-38467
BaseFortify
Publication date: 2025-07-25
Last updated on: 2025-12-22
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | From 4.0 (inc) to 5.4.296 (exc) |
| linux | linux_kernel | From 5.5 (inc) to 5.10.240 (exc) |
| linux | linux_kernel | From 5.11 (inc) to 5.15.189 (exc) |
| linux | linux_kernel | From 5.16 (inc) to 6.1.146 (exc) |
| linux | linux_kernel | From 6.2 (inc) to 6.6.99 (exc) |
| linux | linux_kernel | From 6.7 (inc) to 6.12.39 (exc) |
| linux | linux_kernel | From 6.13 (inc) to 6.15.7 (exc) |
| linux | linux_kernel | 6.16 |
| linux | linux_kernel | 6.16 |
| linux | linux_kernel | 6.16 |
| linux | linux_kernel | 6.16 |
| debian | debian_linux | 11.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-476 | The product dereferences a pointer that it expects to be valid but is NULL. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a race condition in the Linux kernel's drm/exynos driver, specifically in the exynos7_drm_decon component. When there is support for another console device like a TTY serial, the kernel may panic during boot due to a NULL pointer dereference in the vblank interrupt handling code. The issue occurs because the code calls drm_crtc_handle_vblank() without checking if the drm device can handle vblanks, leading to a kernel panic. The fix adds a check to ensure the drm device can handle vblanks before calling this function.
How can this vulnerability impact me? :
This vulnerability can cause the Linux kernel to panic during system boot if another console device is present, leading to system instability or failure to boot properly. This can disrupt normal operation and availability of the system.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for kernel panic messages during boot that include a NULL pointer dereference at virtual address 0x0 and a call trace involving drm_crtc_handle_vblank and decon_irq_handler. Checking system logs (e.g., using 'dmesg' or 'journalctl') for such panic messages can help identify the issue. Example commands: 'dmesg | grep -i panic', 'journalctl -k | grep drm_crtc_handle_vblank'.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, update the Linux kernel to a version that includes the fix which adds a vblank check in IRQ handling for the exynos7_drm_decon driver. This prevents kernel panics caused by the race condition. Until the update is applied, avoid using configurations that enable multiple console devices that trigger the issue.