CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-39480 – kdb: Fix buffer overflow during tab-complete
https://notcve.org/view.php?id=CVE-2024-39480
In the Linux kernel, the following vulnerability has been resolved: kdb: Fix buffer overflow during tab-complete Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. ... En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kdb: corrige el desbordamiento del búfer durante la finalización de tabulación Actualmente, cuando el usuario intenta completar el símbolo con la tecla Tab, kdb usará strncpy() para insertar el símbolo completado en el búfer de comando. • https://git.kernel.org/stable/c/fb824a99e148ff272a53d71d84122728b5f00992 https://git.kernel.org/stable/c/ddd2972d8e2dee3b33e8121669d55def59f0be8a https://git.kernel.org/stable/c/cfdc2fa4db57503bc6d3817240547c8ddc55fa96 https://git.kernel.org/stable/c/f636a40834d22e5e3fc748f060211879c056cd33 https://git.kernel.org/stable/c/33d9c814652b971461d1e30bead6792851c209e7 https://git.kernel.org/stable/c/107e825cc448b7834b31e8b1b3cf0f57426d46d5 https://git.kernel.org/stable/c/f694da720dcf795dc3eb97bf76d220213f76aaa7 https://git.kernel.org/stable/c/e9730744bf3af04cda23799029342aa3c • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-121: Stack-based Buffer Overflow •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2024-39479 – drm/i915/hwmon: Get rid of devm
https://notcve.org/view.php?id=CVE-2024-39479
In the Linux kernel, the following vulnerability has been resolved: drm/i915/hwmon: Get rid of devm When both hwmon and hwmon drvdata (on which hwmon depends) are device managed resources, the expectation, on device unbind, is that hwmon will be released before drvdata. ... Which means that we have a uaf if hwmon sysfs is accessed when drvdata has been released but hwmon hasn't. The only way out of this seems to be do get rid of devm_ and release/free everything explicitly during device unbind. v2: Change commit message and other minor code changes v3: Cleanup from i915_hwmon_register on error (Armin Wolf) v4: Eliminate potential static analyzer warning (Rodrigo) Eliminate fetch_and_zero (Jani) v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/hwmon: deshacerse de devm Cuando tanto hwmon como hwmon drvdata (del cual depende hwmon) son recursos administrados por el dispositivo, la expectativa, al desvincular el dispositivo, es que hwmon publicarse antes que drvdata. • https://git.kernel.org/stable/c/cfa73607eb21a4ce1d6294a2c5733628897b48a2 https://git.kernel.org/stable/c/ce5a22d22db691d14516c3b8fdbf69139eb2ea8f https://git.kernel.org/stable/c/5bc9de065b8bb9b8dd8799ecb4592d0403b54281 https://access.redhat.com/security/cve/CVE-2024-39479 https://bugzilla.redhat.com/show_bug.cgi?id=2296059 • CWE-400: Uncontrolled Resource Consumption CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-39478 – crypto: starfive - Do not free stack buffer
https://notcve.org/view.php?id=CVE-2024-39478
In the Linux kernel, the following vulnerability has been resolved: crypto: starfive - Do not free stack buffer RSA text data uses variable length buffer allocated in software stack. Calling kfree on it causes undefined behaviour in subsequent operations. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: starfive: no liberar el búfer de pila Los datos de texto RSA utilizan un búfer de longitud variable asignado en la pila de software. • https://git.kernel.org/stable/c/445a4aaf5842073e4130b1d6dbe3785284d9615f https://git.kernel.org/stable/c/5944de192663f272033501dcd322b008fca72006 https://git.kernel.org/stable/c/d7f01649f4eaf1878472d3d3f480ae1e50d98f6c • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-39477 – mm/hugetlb: do not call vma_add_reservation upon ENOMEM
https://notcve.org/view.php?id=CVE-2024-39477
In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: do not call vma_add_reservation upon ENOMEM sysbot reported a splat [1] on __unmap_hugepage_range(). This is because vma_needs_reservation() can return -ENOMEM if allocate_file_region_entries() fails to allocate the file_region struct for the reservation. Check for that and do not call vma_add_reservation() if that is the case, otherwise region_abort() and region_del() will see that we do not have any file_regions. If we detect that vma_needs_reservation() returned -ENOMEM, we clear the hugetlb_restore_reserve flag as if this reservation was still consumed, so free_huge_folio() will not increment the resv count. [1] https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/T/#ma5983bc1ab18a54910da83416b3f89f3c7ee43aa En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/hugetlb: no llame a vma_add_reservation cuando ENOMEM sysbot informó un splat [1] en __unmap_hugepage_range(). ... Si detectamos que vma_needs_reservation() devolvió -ENOMEM, borramos el indicador hugetlb_restore_reserve como si esta reserva todavía estuviera consumida, por lo que free_huge_folio() no incrementará el recuento de resv. [1] https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/T/#ma5983bc1ab18a54910da83416b3f89f3c7ee43aa • https://git.kernel.org/stable/c/df7a6d1f64056aec572162c5d35ed9ff86ece6f3 https://git.kernel.org/stable/c/aa998f9dcb34c28448f86e8f5490f20d5eb0eac7 https://git.kernel.org/stable/c/8daf9c702ee7f825f0de8600abff764acfedea13 • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 5.5EPSS: 0%CPEs: 16EXPL: 0CVE-2024-39476 – md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
https://notcve.org/view.php?id=CVE-2024-39476
In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"") However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d(). Current implementation in raid5d() has a weird dependence: 1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared; This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfig_mutex', and md_check_recovery() can't update super_block, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released. Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' is released. ... En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid5: corrige el punto muerto que raid5d() espera a que se borre MD_SB_CHANGE_PENDING Xiao informó que la prueba lvm2 lvconvert-raid-takeover.sh puede bloquearse con una pequeña posibilidad, la causa principal es exactamente lo mismo que el commit bed9e27baf52 ("Revertir "md/raid5: Espere MD_SB_CHANGE_PENDING en raid5d") Sin embargo, Dan informó otro bloqueo después de eso, y Junxiao investigó el problema y descubrió que esto se debe a que la biografía conectada no puede emitir de raid5d(). ... A vulnerability was found in the Linux kernel's md/raid5 implementation within the raid5d() function. • https://git.kernel.org/stable/c/f3d55bd5b7b928ad82f8075d89c908702f3593ab https://git.kernel.org/stable/c/1c00bb624cd084e2006520ad0edacaff0fb941c4 https://git.kernel.org/stable/c/782b3e71c957991ac8ae53318bc369049d49bb53 https://git.kernel.org/stable/c/9e86dffd0b02594d2e7c60c6db9e889c0395414b https://git.kernel.org/stable/c/5e2cf333b7bd5d3e62595a44d598a254c697cd74 https://git.kernel.org/stable/c/7d808fe6af8409cf9f46ed2b10840e5788985e9b https://git.kernel.org/stable/c/1e8c1c2a92692881ac7ec92dcf1c8a846584251b https://git.kernel.org/stable/c/7f71d9817cea3582daa2e903596461f5f • CWE-667: Improper Locking CWE-833: Deadlock •