CVSS: 4.4EPSS: 0%CPEs: 2EXPL: 0CVE-2024-36022 – drm/amdgpu: Init zone device and drm client after mode-1 reset on reload
https://notcve.org/view.php?id=CVE-2024-36022
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Init zone device and drm client after mode-1 reset on reload In passthrough environment, when amdgpu is reloaded after unload, mode-1 is triggered after initializing the necessary IPs, That init does not include KFD, and KFD init waits until the reset is completed. KFD init is called in the reset handler, but in this case, the zone device and drm client is not initialized, causing app to create kernel panic. v2: Removing the init KFD condition from amdgpu_amdkfd_drm_client_create. As the previous version has the potential of creating DRM client twice. v3: v2 patch results in SDMA engine hung as DRM open causes VM clear to SDMA before SDMA init. Adding the condition to in drm client creation, on top of v1, to guard against drm client creation call multiple times. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: dispositivo de zona de inicio y cliente drm después del restablecimiento del modo 1 al recargar. En el entorno de paso a través, cuando amdgpu se recarga después de la descarga, el modo 1 se activa después de inicializar las IP necesarias. • https://git.kernel.org/stable/c/4f8154f775197d0021b690c2945d6a4d8094c8f6 https://git.kernel.org/stable/c/f679fd6057fbf5ab34aaee28d58b7f81af0cbf48 https://access.redhat.com/security/cve/CVE-2024-36022 https://bugzilla.redhat.com/show_bug.cgi?id=2284427 • CWE-908: Use of Uninitialized Resource •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36021 – net: hns3: fix kernel crash when devlink reload during pf initialization
https://notcve.org/view.php?id=CVE-2024-36021
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when devlink reload during pf initialization The devlink reload process will access the hardware resources, but the register operation is done before the hardware is initialized. So, processing the devlink reload during initialization may lead to kernel crash. This patch fixes this by taking devl_lock during initialization. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hns3: soluciona el fallo del kernel cuando devlink se recarga durante la inicialización de pf. El proceso de recarga de devlink accederá a los recursos de hardware, pero la operación de registro se realiza antes de que se inicialice el hardware. Por lo tanto, procesar la recarga de devlink durante la inicialización puede provocar una falla del kernel. • https://git.kernel.org/stable/c/b741269b275953786832805df329851299ab4de7 https://git.kernel.org/stable/c/50b69054f455dcdb34bd6b22764c7579b270eef3 https://git.kernel.org/stable/c/1b550dae55901c2cc9075d6a7155a71b4f516e86 https://git.kernel.org/stable/c/7ca0f73e5e2da3c129935b97f3a0877cce8ebdf5 https://git.kernel.org/stable/c/93305b77ffcb042f1538ecc383505e87d95aa05a •
CVSS: 5.3EPSS: 0%CPEs: 9EXPL: 0CVE-2024-36020 – i40e: fix vf may be used uninitialized in this function warning
https://notcve.org/view.php?id=CVE-2024-36020
In the Linux kernel, the following vulnerability has been resolved: i40e: fix vf may be used uninitialized in this function warning To fix the regression introduced by commit 52424f974bc5, which causes servers hang in very hard to reproduce conditions with resets races. Using two sources for the information is the root cause. In this function before the fix bumping v didn't mean bumping vf pointer. But the code used this variables interchangeably, so stale vf could point to different/not intended vf. Remove redundant "v" variable and iterate via single VF pointer across whole function instead to guarantee VF pointer validity. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: se puede usar vf sin inicializar en esta función advertencia Para corregir la regresión introducida por el commit 52424f974bc5, que hace que los servidores se cuelguen con mucha dificultad para reproducir condiciones con restablecimientos de ejecución. El uso de dos fuentes para la información es la causa fundamental. En esta función, antes de la corrección, tocar v no significaba tocar el puntero vf. • https://git.kernel.org/stable/c/76ed715836c6994bac29d9638e9314e6e3b08651 https://git.kernel.org/stable/c/e88c2a1e28c5475065563d66c07ca879a9afbd07 https://git.kernel.org/stable/c/9abae363af5ced6adbf04c14366289540281fb26 https://git.kernel.org/stable/c/c39de3ae5075ea5f78e097cb5720d4e52d5caed9 https://git.kernel.org/stable/c/52424f974bc53c26ba3f00300a00e9de9afcd972 https://git.kernel.org/stable/c/02f949747e6fb767b29f7931d4bbf40911684e7a https://git.kernel.org/stable/c/cc9cd02dd9e8b7764ea9effb24f4f1dd73d1b23d https://git.kernel.org/stable/c/9dcf0fcb80f6aeb01469e3c957f8d4c97 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.1EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36019 – regmap: maple: Fix cache corruption in regcache_maple_drop()
https://notcve.org/view.php?id=CVE-2024-36019
In the Linux kernel, the following vulnerability has been resolved: regmap: maple: Fix cache corruption in regcache_maple_drop() When keeping the upper end of a cache block entry, the entry[] array must be indexed by the offset from the base register of the block, i.e. max - mas.index. The code was indexing entry[] by only the register address, leading to an out-of-bounds access that copied some part of the kernel memory over the cache contents. This bug was not detected by the regmap KUnit test because it only tests with a block of registers starting at 0, so mas.index == 0. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regmap: maple: corrige la corrupción de la caché en regcache_maple_drop() Cuando se mantiene el extremo superior de una entrada de bloque de caché, la matriz de entrada[] debe indexarse según el desplazamiento del registro base de el bloque, es decir, max - mas.index. El código indexaba la entrada [] solo por la dirección de registro, lo que generaba un acceso fuera de los límites que copiaba parte de la memoria del kernel sobre el contenido de la caché. Este error no fue detectado por la prueba regmap KUnit porque solo prueba con un bloque de registros que comienza en 0, por lo que mas.index == 0. • https://git.kernel.org/stable/c/f033c26de5a5734625d2dd1dc196745fae186f1b https://git.kernel.org/stable/c/3af6c5ac72dc5b721058132a0a1d7779e443175e https://git.kernel.org/stable/c/51c4440b9d3fd7c8234e6de9170a487c03506e53 https://git.kernel.org/stable/c/00bb549d7d63a21532e76e4a334d7807a54d9f31 https://access.redhat.com/security/cve/CVE-2024-36019 https://bugzilla.redhat.com/show_bug.cgi?id=2284402 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36018 – nouveau/uvmm: fix addr/range calcs for remap operations
https://notcve.org/view.php?id=CVE-2024-36018
In the Linux kernel, the following vulnerability has been resolved: nouveau/uvmm: fix addr/range calcs for remap operations dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8 was causing a remap operation like the below. op_remap: prev: 0000003fffed0000 00000000000f0000 00000000a5abd18a 0000000000000000 op_remap: next: op_remap: unmap: 0000003fffed0000 0000000000100000 0 op_map: map: 0000003ffffc0000 0000000000010000 000000005b1ba33c 00000000000e0000 This was resulting in an unmap operation from 0x3fffed0000+0xf0000, 0x100000 which was corrupting the pagetables and oopsing the kernel. Fixes the prev + unmap range calcs to use start/end and map back to addr/range. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nouveau/uvmm: corrige los cálculos de addr/range para operaciones de reasignación dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8 estaba provocando una operación de reasignación como la siguiente. OP_REMAP: Prev: 0000003FFED0000 00000000000F0000 0000000000A5ABD18A 0000000000000000 OP_REMAP: SIGUIEN 0000000000000E0000 Esto dio como resultado una operación de UNMAP desde 0x3fffed0000+0xf0000, 0x100000, que corrompía los pagetables y se agotaba el núcleo. Corrige los cálculos de rango anterior + desasignar para usar inicio/fin y volver a asignar a dirección/rango. • https://git.kernel.org/stable/c/b88baab828713ce0b49b185444b2ee83bed373a8 https://git.kernel.org/stable/c/692a51bebf4552bdf0a79ccd68d291182a26a569 https://git.kernel.org/stable/c/0c16020d2b69a602c8ae6a1dd2aac9a3023249d6 https://git.kernel.org/stable/c/be141849ec00ef39935bf169c0f194ac70bf85ce •