Page 336 of 3027 results (0.008 seconds)

CVSS: 5.3EPSS: 0%CPEs: 9EXPL: 0

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: 0

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: 0

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: 0

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 •

CVSS: 7.7EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: tty: n_gsm: corrige posibles fuera de los límites en gsm0_receive() Suponiendo lo siguiente: - el lado A configura el n_gsm en modo de opción básica - el lado B envía el encabezado de un mensaje básico trama del modo de opción con longitud de datos 1 - el lado A cambia al modo de opción avanzada - el lado B envía 2 bytes de datos que exceden gsm->len Motivo: gsm->len no se usa en el modo de opción avanzada. - el lado A cambia al modo de opción básica - el lado B continúa enviando hasta que gsm0_receive() escribe más allá de gsm->buf Motivo: Ni gsm->state ni gsm->len se han restablecido después de la reconfiguración. Solucione este problema cambiando gsm->count a gsm->len comparación de igual a menor que. También agregue comprobaciones de límite superior contra la constante MAX_MRU en gsm0_receive() y gsm1_receive() para proteger contra la corrupción de memoria de gsm->len y gsm->mru. • https://git.kernel.org/stable/c/e1eaea46bb4020b38a141b84f88565d4603f8dd0 https://git.kernel.org/stable/c/9513d4148950b05bc99fa7314dc883cc0e1605e5 https://git.kernel.org/stable/c/b229bc6c6ea9fe459fc3fa94fd0a27a2f32aca56 https://git.kernel.org/stable/c/0fb736c9931e02dbc7d9a75044c8e1c039e50f04 https://git.kernel.org/stable/c/4c267110fc110390704cc065edb9817fdd10ff54 https://git.kernel.org/stable/c/46f52c89a7e7d2691b97a9728e4591d071ca8abc https://git.kernel.org/stable/c/774d83b008eccb1c48c14dc5486e7aa255731350 https://git.kernel.org/stable/c/f126ce7305fe88f49cdabc6db4168b931 • CWE-125: Out-of-bounds Read CWE-787: Out-of-bounds Write •