CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-39482 – bcache: fix variable length array abuse in btree_iter
https://notcve.org/view.php?id=CVE-2024-39482
In the Linux kernel, the following vulnerability has been resolved: bcache: fix variable length array abuse in btree_iter btree_iter is used in two ways: either allocated on the stack with a fixed size MAX_BSETS, or from a mempool with a dynamic size based on the specific cache set. Previously, the struct had a fixed-length array of size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized iterators, which causes UBSAN to complain. This patch uses the same approach as in bcachefs's sort_iter and splits the iterator into a btree_iter with a flexible array member and a btree_iter_stack which embeds a btree_iter as well as a fixed-length data array. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: corrige el abuso de matriz de longitud variable en btree_iter btree_iter se usa de dos maneras: ya sea asignado en la pila con un tamaño fijo MAX_BSETS, o desde un mempool con un tamaño dinámico basado en el conjunto de caché específico. Anteriormente, la estructura tenía una matriz de longitud fija de tamaño MAX_BSETS que estaba indexada fuera de los límites para los iteradores de tamaño dinámico, lo que provoca que UBSAN se queje. Este parche utiliza el mismo enfoque que en sort_iter de bcachefs y divide el iterador en un btree_iter con un miembro de matriz flexible y un btree_iter_stack que incorpora un btree_iter así como una matriz de datos de longitud fija. • https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b https://git.kernel.org/stable/c/5a1922adc5798b7ec894cd3f197afb6f9591b023 https://git.kernel.org/stable/c/934e1e4331859183a861f396d7dfaf33cb5afb02 https://git.kernel.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148 https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671 https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31 • CWE-770: Allocation of Resources Without Limits or Throttling •
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. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer. Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around. 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. Desafortunadamente, pasa el tamaño del búfer de origen en lugar del destino a strncpy() con resultados predeciblemente horribles. Lo más obvio es que si el búfer de comando ya está lleno pero cp, la posición del cursor, está en el medio del búfer, entonces escribiremos más allá del final del búfer proporcionado. • 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. However, in i915 there are two separate code paths, which both release either drvdata or hwmon and either can be released before the other. These code paths (for device unbind) are as follows (see also the bug referenced below): Call Trace: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 component_unbind_all+0x8d/0xa0 component_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 device_release_driver_internal+0x19c/0x200 unbind_store+0x9c/0xb0 and Call Trace: release_nodes+0x11/0x70 devres_release_all+0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 This means that in i915, if use devm, we cannot gurantee that hwmon will always 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. Sin embargo, en i915 hay dos rutas de código independientes, que liberan drvdata o hwmon y cualquiera de ellas puede publicarse antes que la otra. • 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: 11EXPL: 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. Meanwhile, the hang problem will be fixed as well. 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(). La implementación actual en raid5d() tiene una dependencia extraña: 1) md_check_recovery() de raid5d() debe mantener 'reconfig_mutex' para borrar MD_SB_CHANGE_PENDING; 2) raid5d() maneja IO en un bucle muerto, hasta que se emiten todas las IO; 3) IO de raid5d() debe esperar a que se borre MD_SB_CHANGE_PENDING; Este comportamiento se introdujo antes de v2.6 y, como consecuencia, si otro contexto contiene 'reconfig_mutex' y md_check_recovery() no puede actualizar super_block, entonces raid5d() desperdiciará una CPU al 100% mediante el bucle muerto, hasta que 'reconfig_mutex' sea liberado. Consulte la implementación de raid1 y raid10, solucione este problema omitiendo el problema IO si MD_SB_CHANGE_PENDING todavía está configurado después de md_check_recovery(), el hilo del daemon se activará cuando se publique 'reconfig_mutex'. • 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/2cab058f2b147e0b7c01546ba00445e5701861f5 https://git.kernel.org/stable/c/91962e40ec3d26e291db230cd45b302da • CWE-667: Improper Locking CWE-833: Deadlock •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-39475 – fbdev: savage: Handle err return when savagefb_check_var failed
https://notcve.org/view.php?id=CVE-2024-39475
In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Handle err return when savagefb_check_var failed The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero") checks the value of pixclock to avoid divide-by-zero error. However the function savagefb_probe doesn't handle the error return of savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: savage: Maneja el retorno de error cuando falla savagefb_check_var. El commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock es igual a cero") verifica el valor de pixclock para evitar división por error cero. • https://git.kernel.org/stable/c/224453de8505aede1890f007be973925a3edf6a1 https://git.kernel.org/stable/c/84dce0f6a4cc5b7bfd7242ef9290db8ac1dd77ff https://git.kernel.org/stable/c/512ee6d6041e007ef5bf200c6e388e172a2c5b24 https://git.kernel.org/stable/c/8c54acf33e5adaad6374bf3ec1e3aff0591cc8e1 https://git.kernel.org/stable/c/070398d32c5f3ab0e890374904ad94551c76aec4 https://git.kernel.org/stable/c/bc3c2e58d73b28b9a8789fca84778ee165a72d13 https://git.kernel.org/stable/c/04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288 https://git.kernel.org/stable/c/a9ca4e80d23474f90841251f4ac0d941f • CWE-369: Divide By Zero •