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. A vulnerability was found in the Linux kernel’s `regmap` subsystem. • 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 •
CVSS: 4.1EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36017 – rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
https://notcve.org/view.php?id=CVE-2024-36017
In the Linux kernel, the following vulnerability has been resolved: rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a struct ifla_vf_vlan_info so the size of such attribute needs to be at least of sizeof(struct ifla_vf_vlan_info) which is 14 bytes. The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes) which is less than sizeof(struct ifla_vf_vlan_info) so this validation is not enough and a too small attribute might be cast to a struct ifla_vf_vlan_info, this might result in an out of bands read access when accessing the saved (casted) entry in ivvl. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtnetlink: Validación correcta del atributo IFLA_VF_VLAN_LIST anidado. Se supone que cada atributo dentro de un IFLA_VF_VLAN_LIST anidado es una estructura ifla_vf_vlan_info, por lo que el tamaño de dicho atributo debe ser al menos de sizeof(struct ifla_vf_vlan_info), que es de 14 bytes. La validación de tamaño actual en do_setvfinfo es contra NLA_HDRLEN (4 bytes), que es menor que sizeof(struct ifla_vf_vlan_info), por lo que esta validación no es suficiente y un atributo demasiado pequeño podría convertirse en una estructura ifla_vf_vlan_info, esto podría resultar en un acceso de lectura fuera de banda al acceder a la entrada guardada (transmitida) en ivvl. • https://git.kernel.org/stable/c/79aab093a0b5370d7fc4e99df75996f4744dc03f https://git.kernel.org/stable/c/8ac69ff2d0d5be9734c4402de932aa3dc8549c1a https://git.kernel.org/stable/c/5e7ef2d88666a0212db8c38e6703864b9ce70169 https://git.kernel.org/stable/c/6c8f44b02500c7d14b5e6618fe4ef9a0da47b3de https://git.kernel.org/stable/c/f3c1bf3054f96ddeab0621d920445bada769b40e https://git.kernel.org/stable/c/6e4c7193954f4faab92f6e8d88bc5565317b44e7 https://git.kernel.org/stable/c/206003c748b88890a910ef7142d18f77be57550b https://git.kernel.org/stable/c/4a4b9757789a1551d2df130df23bfb354 • CWE-125: Out-of-bounds Read •