CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38622 – drm/msm/dpu: Add callback function pointer check before its call
https://notcve.org/view.php?id=CVE-2024-38622
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: Add callback function pointer check before its call In dpu_core_irq_callback_handler() callback function pointer is compared to NULL, but then callback function is unconditionally called by this pointer. Fix this bug by adding conditional return. Found by Linux Verification Center (linuxtesting.org) with SVACE. Patchwork: https://patchwork.freedesktop.org/patch/588237/ • https://git.kernel.org/stable/c/c929ac60b3ed34accd25a052a4833e418900f466 https://git.kernel.org/stable/c/873f67699114452c2a996c4e10faac8ff860c241 https://git.kernel.org/stable/c/9078630ed7f8f25d65d11823e7f2b11a8e2f4f0f https://git.kernel.org/stable/c/530f272053a5e72243a9cb07bb1296af6c346002 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38621 – media: stk1160: fix bounds checking in stk1160_copy_video()
https://notcve.org/view.php?id=CVE-2024-38621
In the Linux kernel, the following vulnerability has been resolved: media: stk1160: fix bounds checking in stk1160_copy_video() The subtract in this condition is reversed. The ->length is the length of the buffer. The ->bytesused is how many bytes we have copied thus far. When the condition is reversed that means the result of the subtraction is always negative but since it's unsigned then the result is a very high positive value. That means the overflow check is never true. Additionally, the ->bytesused doesn't actually work for this purpose because we're not writing to "buf->mem + buf->bytesused". • https://git.kernel.org/stable/c/9cb2173e6ea8f2948bd1367c93083a2500fcf08f https://git.kernel.org/stable/c/f6a392266276730bea893b55d12940e32a25f56a https://git.kernel.org/stable/c/ecf4ddc3aee8ade504c4d36b7b4053ce6093e200 https://git.kernel.org/stable/c/a16775828aaed1c54ff4e6fe83e8e4d5c6a50cb7 https://git.kernel.org/stable/c/7532bcec0797adfa08791301c3bcae14141db3bd https://git.kernel.org/stable/c/b504518a397059e1d55c521ba0ea2b545a6c4b52 https://git.kernel.org/stable/c/d410017a7181cb55e4a5c810b32b75e4416c6808 https://git.kernel.org/stable/c/a08492832cc4cacc24e0612f483c86ca8 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-38390 – drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails
https://notcve.org/view.php?id=CVE-2024-38390
In the Linux kernel, the following vulnerability has been resolved: drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer dereference on: msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); as gpu->pdev is only assigned in: a6xx_gpu_init() |_ adreno_gpu_init |_ msm_gpu_init() Instead of relying on handwavy null checks down the cleanup chain, explicitly de-allocate the LLC data and free a6xx_gpu instead. Patchwork: https://patchwork.freedesktop.org/patch/588919/ • https://git.kernel.org/stable/c/76efc2453d0e8e5d6692ef69981b183ad674edea https://git.kernel.org/stable/c/5fea4202b5faccfc6449381a299e8ce4b994d666 https://git.kernel.org/stable/c/247849eeb3fd88f8990ed73e33af70d5c10f9aec https://git.kernel.org/stable/c/a1955a6df91355fef72a3a254700acd3cc1fec0d https://git.kernel.org/stable/c/617e3d1680504a3f9d88e1582892c68be155498f https://git.kernel.org/stable/c/46d4efcccc688cbacdd70a238bedca510acaa8e4 •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38388 – ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup
https://notcve.org/view.php?id=CVE-2024-38388
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup Use the control private_free callback to free the associated data block. This ensures that the memory won't leak, whatever way the control gets destroyed. The original implementation didn't actually remove the ALSA controls in hda_cs_dsp_control_remove(). It only freed the internal tracking structure. This meant it was possible to remove/unload the amp driver while leaving its ALSA controls still present in the soundcard. Obviously attempting to access them could cause segfaults or at least dereferencing stale pointers. • https://git.kernel.org/stable/c/3233b978af23f11b4ad4f7f11a9a64bd05702b1f https://git.kernel.org/stable/c/191dc1b2ff0fb35e7aff15a53224837637df8bff https://git.kernel.org/stable/c/6e359be4975006ff72818e79dad8fe48293f2eb2 https://git.kernel.org/stable/c/3291486af5636540980ea55bae985f3eaa5b0740 https://git.kernel.org/stable/c/172811e3a557d8681a5e2d0f871dc04a2d17eb13 https://access.redhat.com/security/cve/CVE-2024-38388 https://bugzilla.redhat.com/show_bug.cgi?id=2293656 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38381 – nfc: nci: Fix uninit-value in nci_rx_work
https://notcve.org/view.php?id=CVE-2024-38381
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix uninit-value in nci_rx_work syzbot reported the following uninit-value access issue [1] nci_rx_work() parses received packet from ndev->rx_q. It should be validated header size, payload size and total packet size before processing the packet. If an invalid packet is detected, it should be silently discarded. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfc: nci: corrigió el valor uninit en nci_rx_work syzbot informó el siguiente problema de acceso al valor uninit [1] nci_rx_work() analiza el paquete recibido de ndev->rx_q. Se debe validar el tamaño del encabezado, el tamaño del payload y el tamaño total del paquete antes de procesar el paquete. • https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240 https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16 https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7 https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f600 •