CVE-2024-38592
published 2024-06-19CVE-2024-38592: In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Init `ddp_comp` with devm_kcalloc() In the case where `conn_routes` is true…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.23%
14.3th percentile
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Init `ddp_comp` with devm_kcalloc()
In the case where `conn_routes` is true we allocate an extra slot in
the `ddp_comp` array but mtk_drm_crtc_create() never seemed to
initialize it in the test case I ran. For me, this caused a later
crash when we looped through the array in mtk_drm_crtc_mode_valid().
This showed up for me when I booted with `slub_debug=FZPUA` which
poisons the memory initially. Without `slub_debug` I couldn't
reproduce, presumably because the later code handles the value being
NULL and in most cases (not guaranteed in all cases) the memory the
allocator returned started out as 0.
It really doesn't hurt to initialize the array with devm_kcalloc()
since the array is small and the overhead of initting a handful of
elements to 0 is small. In general initting memory to zero is a safer
practice and usually it's suggested to only use the non-initting alloc
functions if you really need to.
Let's switch the function to use an allocation function that zeros the
memory. For me, this avoids the crash.
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.8.12-1 (forky) | linux 6.8.12-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= 01389b324c97ff8f04e9c33b9ee246084f9f6dd2 < cf69d0af7db917b82aceaa44b7b1b9376609da22 | cf69d0af7db917b82aceaa44b7b1b9376609da22 |
| linux | linux | >= 01389b324c97ff8f04e9c33b9ee246084f9f6dd2 < 9fe2cc3fa44f7ad7ba5f29c1a68b2b924c17b9b1 | 9fe2cc3fa44f7ad7ba5f29c1a68b2b924c17b9b1 |
| linux | linux | >= 01389b324c97ff8f04e9c33b9ee246084f9f6dd2 < 01a2c5123e27b3c4685bf2fc4c2e879f6e0c7b33 | 01a2c5123e27b3c4685bf2fc4c2e879f6e0c7b33 |
| linux | linux_kernel | >= 0 < 6.8.12-1 | 6.8.12-1 |
| linux | linux_kernel | >= 0 < 6.8.12-1 | 6.8.12-1 |
| linux | linux_kernel | >= 0 < 6.8.0-40.40 | 6.8.0-40.40 |
| linux | linux_kernel | >= 6.7 < 6.8.12 | 6.8.12 |
| linux | linux_kernel | >= 6.9 < 6.9.3 | 6.9.3 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv6.5MEDIUM
vendor_ubuntu6.5MEDIUM
vendor_debian5.5LOW
vendor_redhat5.5MEDIUM
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
linux-lowlatency, linux-raspi vulnerabilities
osv·2024-08-13
linux-lowlatency, linux-raspi vulnerabilities
linux-lowlatency, linux-raspi vulnerabilities
Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
- ARM32 architecture;
- ARM64 architecture;
- M68K architecture;
- OpenRISC architecture;
- PowerPC architecture;
- RISC-V architecture;
- x86 architecture;
- Block layer subsystem;
- Accessibility subsystem;
- Bluetooth drivers;
- Clock framework and drivers;
- CPU frequency scaling framework;
- Hardware crypto device drivers;
- DMA engine subsystem;
- DPLL subsystem;
- FireWire subsystem;
- EFI core;
- Qualcomm firmware drivers;
- GPIO subsystem;
- GPU drivers;
- Microsoft Hyper-V drivers;
- InfiniBand drivers;
- IOMMU subsystem;
- IRQ chip drivers;
- Macintosh dev
OSV
linux-azure vulnerabilities
osv·2024-08-13·CVSS 6.5
CVE-2024-25742 [MEDIUM] linux-azure vulnerabilities
linux-azure vulnerabilities
Benedict Schlüter, Supraja Sridhara, Andrin Bertschi, and Shweta Shinde
discovered that an untrusted hypervisor could inject malicious #VC
interrupts and compromise the security guarantees of AMD SEV-SNP. This flaw
is known as WeSee. A local attacker in control of the hypervisor could use
this to expose sensitive information or possibly execute arbitrary code in
the trusted execution environment. (CVE-2024-25742)
Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
- ARM32 architecture;
- ARM64 architecture;
- M68K architecture;
- OpenRISC architecture;
- PowerPC architecture;
- RISC-V architecture;
- x86 architecture;
- Block layer su
OSV
linux-oem-6.8 vulnerabilities
osv·2024-08-12
linux-oem-6.8 vulnerabilities
linux-oem-6.8 vulnerabilities
Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
- ARM32 architecture;
- ARM64 architecture;
- M68K architecture;
- OpenRISC architecture;
- PowerPC architecture;
- RISC-V architecture;
- x86 architecture;
- Block layer subsystem;
- Accessibility subsystem;
- Bluetooth drivers;
- Clock framework and drivers;
- CPU frequency scaling framework;
- Hardware crypto device drivers;
- DMA engine subsystem;
- DPLL subsystem;
- FireWire subsystem;
- EFI core;
- Qualcomm firmware drivers;
- GPIO subsystem;
- GPU drivers;
- Microsoft Hyper-V drivers;
- InfiniBand drivers;
- IOMMU subsystem;
- IRQ chip drivers;
- Macintosh device drivers;
- M
OSV
linux-nvidia-lowlatency, linux-oracle vulnerabilities
osv·2024-08-09·CVSS 6.5
CVE-2024-25742 [MEDIUM] linux-nvidia-lowlatency, linux-oracle vulnerabilities
linux-nvidia-lowlatency, linux-oracle vulnerabilities
Benedict Schlüter, Supraja Sridhara, Andrin Bertschi, and Shweta Shinde
discovered that an untrusted hypervisor could inject malicious #VC
interrupts and compromise the security guarantees of AMD SEV-SNP. This flaw
is known as WeSee. A local attacker in control of the hypervisor could use
this to expose sensitive information or possibly execute arbitrary code in
the trusted execution environment. (CVE-2024-25742)
Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
- ARM32 architecture;
- ARM64 architecture;
- M68K architecture;
- OpenRISC architecture;
- PowerPC architecture;
- RISC-V architecture;
- x86 arch
OSV
linux, linux-aws, linux-gcp, linux-gke, linux-ibm, linux-nvidia, linux-nvidia-6.8 vulnerabilities
osv·2024-08-08
linux, linux-aws, linux-gcp, linux-gke, linux-ibm, linux-nvidia, linux-nvidia-6.8 vulnerabilities
linux, linux-aws, linux-gcp, linux-gke, linux-ibm, linux-nvidia, linux-nvidia-6.8 vulnerabilities
Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
- ARM32 architecture;
- ARM64 architecture;
- M68K architecture;
- OpenRISC architecture;
- PowerPC architecture;
- RISC-V architecture;
- x86 architecture;
- Block layer subsystem;
- Accessibility subsystem;
- Bluetooth drivers;
- Clock framework and drivers;
- CPU frequency scaling framework;
- Hardware crypto device drivers;
- DMA engine subsystem;
- DPLL subsystem;
- FireWire subsystem;
- EFI core;
- Qualcomm firmware drivers;
- GPIO subsystem;
- GPU drivers;
- Microsoft Hyper-V drivers;
- InfiniBand drivers;
-
OSV
CVE-2024-38592: In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Init `ddp_comp` with devm_kcalloc() In the case where `conn_routes`
osv·2024-06-19·CVSS 5.5
CVE-2024-38592 [MEDIUM] CVE-2024-38592: In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Init `ddp_comp` with devm_kcalloc() In the case where `conn_routes`
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Init `ddp_comp` with devm_kcalloc() In the case where `conn_routes` is true we allocate an extra slot in the `ddp_comp` array but mtk_drm_crtc_create() never seemed to initialize it in the test case I ran. For me, this caused a later crash when we looped through the array in mtk_drm_crtc_mode_valid(). This showed up for me when I booted with `slub_debug=FZPUA` which poisons the memory initially. Without `slub_debug` I couldn't reproduce, presumably because the later code handles the value being NULL and in most cases (not guaranteed in all cases) the memory the allocator returned started out as 0. It really doesn't hurt to initialize the array with devm_kcalloc() since the array is small and the overhead of i
GHSA
GHSA-9mq7-fm24-r296: In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Init `ddp_comp` with devm_kcalloc()
In the case where `conn_routes
ghsa_unreviewed·2024-06-19
CVE-2024-38592 [MEDIUM] CWE-908 GHSA-9mq7-fm24-r296: In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Init `ddp_comp` with devm_kcalloc()
In the case where `conn_routes
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Init `ddp_comp` with devm_kcalloc()
In the case where `conn_routes` is true we allocate an extra slot in
the `ddp_comp` array but mtk_drm_crtc_create() never seemed to
initialize it in the test case I ran. For me, this caused a later
crash when we looped through the array in mtk_drm_crtc_mode_valid().
This showed up for me when I booted with `slub_debug=FZPUA` which
poisons the memory initially. Without `slub_debug` I couldn't
reproduce, presumably because the later code handles the value being
NULL and in most cases (not guaranteed in all cases) the memory the
allocator returned started out as 0.
It really doesn't hurt to initialize the array with devm_kcalloc()
since the array is small and the overhead o
Ubuntu
Linux kernel vulnerabilities
vendor_ubuntu·2024-08-13
CVE-2024-36905 Linux kernel vulnerabilities
Title: Linux kernel vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
- ARM32 architecture;
- ARM64 architecture;
- M68K architecture;
- OpenRISC architecture;
- PowerPC architecture;
- RISC-V architecture;
- x86 architecture;
- Block layer subsystem;
- Accessibility subsystem;
- Bluetooth drivers;
- Clock framework and drivers;
- CPU frequency scaling framework;
- Hardware crypto device drivers;
- DMA engine subsystem;
- DPLL subsystem;
- FireWire subsystem;
- EFI core;
- Qualcomm firmware drivers;
- GPIO subsystem;
- GPU drivers;
- Microsoft Hyper-V drivers;
- InfiniBand drivers
Ubuntu
Linux kernel (OEM) vulnerabilities
vendor_ubuntu·2024-08-12
CVE-2024-38548 Linux kernel (OEM) vulnerabilities
Title: Linux kernel (OEM) vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
- ARM32 architecture;
- ARM64 architecture;
- M68K architecture;
- OpenRISC architecture;
- PowerPC architecture;
- RISC-V architecture;
- x86 architecture;
- Block layer subsystem;
- Accessibility subsystem;
- Bluetooth drivers;
- Clock framework and drivers;
- CPU frequency scaling framework;
- Hardware crypto device drivers;
- DMA engine subsystem;
- DPLL subsystem;
- FireWire subsystem;
- EFI core;
- Qualcomm firmware drivers;
- GPIO subsystem;
- GPU drivers;
- Microsoft Hyper-V drivers;
- InfiniBand d
Ubuntu
Linux kernel vulnerabilities
vendor_ubuntu·2024-08-09·CVSS 6.5
CVE-2024-36029 [MEDIUM] Linux kernel vulnerabilities
Title: Linux kernel vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
Benedict Schlüter, Supraja Sridhara, Andrin Bertschi, and Shweta Shinde
discovered that an untrusted hypervisor could inject malicious #VC
interrupts and compromise the security guarantees of AMD SEV-SNP. This flaw
is known as WeSee. A local attacker in control of the hypervisor could use
this to expose sensitive information or possibly execute arbitrary code in
the trusted execution environment. (CVE-2024-25742)
Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
- ARM32 architecture;
- ARM64 architecture;
- M68K architecture;
- OpenRISC architecture;
- PowerPC
Ubuntu
Linux kernel vulnerabilities
vendor_ubuntu·2024-08-08
CVE-2024-36952 Linux kernel vulnerabilities
Title: Linux kernel vulnerabilities
Summary: Several security issues were fixed in the Linux kernel.
Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
- ARM32 architecture;
- ARM64 architecture;
- M68K architecture;
- OpenRISC architecture;
- PowerPC architecture;
- RISC-V architecture;
- x86 architecture;
- Block layer subsystem;
- Accessibility subsystem;
- Bluetooth drivers;
- Clock framework and drivers;
- CPU frequency scaling framework;
- Hardware crypto device drivers;
- DMA engine subsystem;
- DPLL subsystem;
- FireWire subsystem;
- EFI core;
- Qualcomm firmware drivers;
- GPIO subsystem;
- GPU drivers;
- Microsoft Hyper-V drivers;
- InfiniBand drivers
Red Hat
kernel: drm/mediatek: Init `ddp_comp` with devm_kcalloc()
vendor_redhat·2024-06-19·CVSS 5.5
CVE-2024-38592 [MEDIUM] CWE-476 kernel: drm/mediatek: Init `ddp_comp` with devm_kcalloc()
kernel: drm/mediatek: Init `ddp_comp` with devm_kcalloc()
In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Init `ddp_comp` with devm_kcalloc()
In the case where `conn_routes` is true we allocate an extra slot in
the `ddp_comp` array but mtk_drm_crtc_create() never seemed to
initialize it in the test case I ran. For me, this caused a later
crash when we looped through the array in mtk_drm_crtc_mode_valid().
This showed up for me when I booted with `slub_debug=FZPUA` which
poisons the memory initially. Without `slub_debug` I couldn't
reproduce, presumably because the later code handles the value being
NULL and in most cases (not guaranteed in all cases) the memory the
allocator returned started out as 0.
It really doesn't hurt to initialize the array with de
Debian
CVE-2024-38592: linux - In the Linux kernel, the following vulnerability has been resolved: drm/mediate...
vendor_debian·2024·CVSS 5.5
CVE-2024-38592 [MEDIUM] CVE-2024-38592: linux - In the Linux kernel, the following vulnerability has been resolved: drm/mediate...
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Init `ddp_comp` with devm_kcalloc() In the case where `conn_routes` is true we allocate an extra slot in the `ddp_comp` array but mtk_drm_crtc_create() never seemed to initialize it in the test case I ran. For me, this caused a later crash when we looped through the array in mtk_drm_crtc_mode_valid(). This showed up for me when I booted with `slub_debug=FZPUA` which poisons the memory initially. Without `slub_debug` I couldn't reproduce, presumably because the later code handles the value being NULL and in most cases (not guaranteed in all cases) the memory the allocator returned started out as 0. It really doesn't hurt to initialize the array with devm_kcalloc() since the array is small and the overhead of i
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://git.kernel.org/stable/c/01a2c5123e27b3c4685bf2fc4c2e879f6e0c7b33https://git.kernel.org/stable/c/9fe2cc3fa44f7ad7ba5f29c1a68b2b924c17b9b1https://git.kernel.org/stable/c/cf69d0af7db917b82aceaa44b7b1b9376609da22https://git.kernel.org/stable/c/01a2c5123e27b3c4685bf2fc4c2e879f6e0c7b33https://git.kernel.org/stable/c/9fe2cc3fa44f7ad7ba5f29c1a68b2b924c17b9b1https://git.kernel.org/stable/c/cf69d0af7db917b82aceaa44b7b1b9376609da22
2024-06-19
Published