CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35883 – spi: mchp-pci1xxx: Fix a possible null pointer dereference in pci1xxx_spi_probe
https://notcve.org/view.php?id=CVE-2024-35883
In the Linux kernel, the following vulnerability has been resolved: spi: mchp-pci1xxx: Fix a possible null pointer dereference in pci1xxx_spi_probe In function pci1xxxx_spi_probe, there is a potential null pointer that may be caused by a failed memory allocation by the function devm_kzalloc. Hence, a null pointer check needs to be added to prevent null pointer dereferencing later in the code. To fix this issue, spi_bus->spi_int[iter] should be checked. The memory allocated by devm_kzalloc will be automatically released, so just directly return -ENOMEM without worrying about memory leaks. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: mchp-pci1xxx: corrige una posible desreferencia de puntero null en pci1xxx_spi_probe En la función pci1xxxx_spi_probe, existe un posible puntero null que puede deberse a una asignación de memoria fallida por parte de la función devm_kzalloc. Por lo tanto, es necesario agregar una verificación de puntero null para evitar que se elimine la referencia al puntero null más adelante en el código. Para solucionar este problema, se debe marcar spi_bus->spi_int[iter]. • https://git.kernel.org/stable/c/1cc0cbea7167af524a7f7b2d0d2f19f7a324e807 https://git.kernel.org/stable/c/4b31a226097cf8cc3c9de5e855d97757fdb2bf06 https://git.kernel.org/stable/c/95e5d9eb26705a9a76d2ef8bcba9ee2e195d653d https://git.kernel.org/stable/c/1f886a7bfb3faf4c1021e73f045538008ce7634e •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35882 – SUNRPC: Fix a slow server-side memory leak with RPC-over-TCP
https://notcve.org/view.php?id=CVE-2024-35882
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a slow server-side memory leak with RPC-over-TCP Jan Schunk reports that his small NFS servers suffer from memory exhaustion after just a few days. A bisect shows that commit e18e157bb5c8 ("SUNRPC: Send RPC message on TCP with a single sock_sendmsg() call") is the first bad commit. That commit assumed that sock_sendmsg() releases all the pages in the underlying bio_vec array, but the reality is that it doesn't. svc_xprt_release() releases the rqst's response pages, but the record marker page fragment isn't one of those, so it is never released. This is a narrow fix that can be applied to stable kernels. A more extensive fix is in the works. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Revertir "drm/amd/display: Enviar mensaje de desactivación DTBCLK en la primera confirmación" Esto revierte la confirmación f341055b10bd8be55c3c995dff5f770b236b8ca9. Se observó un bloqueo del sistema; se cree que este compromiso es el punto de regresión. • https://git.kernel.org/stable/c/e18e157bb5c8c1cd8a9ba25acfdcf4f3035836f4 https://git.kernel.org/stable/c/1ba1291172f935e6b6fe703161a948f3347400b8 https://git.kernel.org/stable/c/a2ebedf7bcd17a1194a0a18122c885eb578ee882 https://git.kernel.org/stable/c/05258a0a69b3c5d2c003f818702c0a52b6fea861 •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35880 – io_uring/kbuf: hold io_buffer_list reference over mmap
https://notcve.org/view.php?id=CVE-2024-35880
In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: hold io_buffer_list reference over mmap If we look up the kbuf, ensure that it doesn't get unregistered until after we're done with it. Since we're inside mmap, we cannot safely use the io_uring lock. Rely on the fact that we can lookup the buffer list under RCU now and grab a reference to it, preventing it from being unregistered until we're done with it. The lookup returns the io_buffer_list directly with it referenced. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/kbuf: mantiene la referencia io_buffer_list sobre mmap. • https://git.kernel.org/stable/c/09f7520048eaaee9709091cd2787966f807da7c5 https://git.kernel.org/stable/c/5cf4f52e6d8aa2d3b7728f568abbf9d42a3af252 https://git.kernel.org/stable/c/65938e81df2197203bda4b9a0c477e7987218d66 https://git.kernel.org/stable/c/5fd8e2359498043e0b5329a05f02d10a9eb91eb9 https://git.kernel.org/stable/c/561e4f9451d65fc2f7eef564e0064373e3019793 https://access.redhat.com/security/cve/CVE-2024-35880 https://bugzilla.redhat.com/show_bug.cgi?id=2281713 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-35879 – of: dynamic: Synchronize of_changeset_destroy() with the devlink removals
https://notcve.org/view.php?id=CVE-2024-35879
In the Linux kernel, the following vulnerability has been resolved: of: dynamic: Synchronize of_changeset_destroy() with the devlink removals In the following sequence: 1) of_platform_depopulate() 2) of_overlay_remove() During the step 1, devices are destroyed and devlinks are removed. During the step 2, OF nodes are destroyed but __of_changeset_entry_destroy() can raise warnings related to missing of_node_put(): ERROR: memory leak, expected refcount 1 instead of 2 ... Indeed, during the devlink removals performed at step 1, the removal itself releasing the device (and the attached of_node) is done by a job queued in a workqueue and so, it is done asynchronously with respect to function calls. When the warning is present, of_node_put() will be called but wrongly too late from the workqueue job. In order to be sure that any ongoing devlink removals are done before the of_node destruction, synchronize the of_changeset_destroy() with the devlink removals. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: of:dynamic: Sincronizar of_changeset_destroy() con las eliminaciones de devlink En la siguiente secuencia: 1) of_platform_depopulate() 2) of_overlay_remove() Durante el paso 1, los dispositivos se destruyen y los devlinks son remoto. Durante el paso 2, los nodos OF se destruyen, pero __of_changeset_entry_destroy() puede generar advertencias relacionadas con la falta de of_node_put(): ERROR: pérdida de memoria, recuento esperado 1 en lugar de 2... De hecho, durante las eliminaciones de devlink realizadas en el paso 1, la eliminación La liberación del dispositivo (y el of_node adjunto) se realiza mediante un trabajo en cola en una cola de trabajo y, por lo tanto, se realiza de forma asincrónica con respecto a las llamadas a funciones. Cuando la advertencia está presente, se llamará a of_node_put() pero erróneamente demasiado tarde desde el trabajo de la cola de trabajo. • https://git.kernel.org/stable/c/d007150b4e15bfcb8d36cfd88a5645d42e44d383 https://git.kernel.org/stable/c/80dd33cf72d1ab4f0af303f1fa242c6d6c8d328f https://git.kernel.org/stable/c/252c23915546863685ecc68cb3a39e7e80c6c9d4 https://git.kernel.org/stable/c/3127b2ee50c424a96eb3559fbb7b43cf0b111c7a https://git.kernel.org/stable/c/3ee2424107546d882e1ddd75333ca9c32879908c https://git.kernel.org/stable/c/7b6df050c45a1ea158fd50bc32a8e1447dd1e951 https://git.kernel.org/stable/c/801c8b8ec5bfb3519566dff16a5ecd48302fca82 https://git.kernel.org/stable/c/ae6d76e4f06c37a623e357e79d49b1741 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35878 – of: module: prevent NULL pointer dereference in vsnprintf()
https://notcve.org/view.php?id=CVE-2024-35878
In the Linux kernel, the following vulnerability has been resolved: of: module: prevent NULL pointer dereference in vsnprintf() In of_modalias(), we can get passed the str and len parameters which would cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr when the length is also 0. Also, we need to filter out the negative values of the len parameter as these will result in a really huge buffer since snprintf() takes size_t parameter while ours is ssize_t... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: de: módulo: evita la desreferencia del puntero NULL en vsnprintf() En of_modalias(), podemos pasar los parámetros str y len que provocarían un kernel ups en vsnprintf() ya que solo permite pasar un ptr NULL cuando la longitud también es 0. Además, necesitamos filtrar los valores negativos del parámetro len ya que estos darán como resultado un búfer realmente enorme ya que snprintf() toma el parámetro size_t mientras que el nuestro es ssize_t... Encontrado por el Centro de verificación de Linux (linuxtesting.org) con la herramienta de análisis estático Svace. • https://git.kernel.org/stable/c/e4a449368a2ce6d57a775d0ead27fc07f5a86e5b https://git.kernel.org/stable/c/544561dc56f7e69a053c25e11e6170f48bb97898 https://git.kernel.org/stable/c/a1aa5390cc912934fee76ce80af5f940452fa987 https://access.redhat.com/security/cve/CVE-2024-35878 https://bugzilla.redhat.com/show_bug.cgi?id=2281718 • CWE-476: NULL Pointer Dereference •