CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35885 – mlxbf_gige: stop interface during shutdown
https://notcve.org/view.php?id=CVE-2024-35885
In the Linux kernel, the following vulnerability has been resolved: mlxbf_gige: stop interface during shutdown The mlxbf_gige driver intermittantly encounters a NULL pointer exception while the system is shutting down via "reboot" command. The mlxbf_driver will experience an exception right after executing its shutdown() method. One example of this exception is: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000 [0000000000000070] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] SMP CPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S OE 5.15.0-bf.6.gef6992a #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023 pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] sp : ffff8000080d3c10 x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58 x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008 x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128 x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7 x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101 x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404 x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080 x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] __napi_poll+0x40/0x1c8 net_rx_action+0x314/0x3a0 __do_softirq+0x128/0x334 run_ksoftirqd+0x54/0x6c smpboot_thread_fn+0x14c/0x190 kthread+0x10c/0x110 ret_from_fork+0x10/0x20 Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002) ---[ end trace 7cc3941aa0d8e6a4 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x4ce722520000 from 0xffff800008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x000005c1,a3330e5a Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- During system shutdown, the mlxbf_gige driver's shutdown() is always executed. However, the driver's stop() method will only execute if networking interface configuration logic within the Linux distribution has been setup to do so. If shutdown() executes but stop() does not execute, NAPI remains enabled and this can lead to an exception if NAPI is scheduled while the hardware interface has only been partially deinitialized. The networking interface managed by the mlxbf_gige driver must be properly stopped during system shutdown so that IFF_UP is cleared, the hardware interface is put into a clean state, and NAPI is fully deinitialized. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mlxbf_gige: detiene la interfaz durante el apagado El controlador mlxbf_gige encuentra intermitentemente una excepción de puntero NULL mientras el sistema se apaga mediante el comando "reboot". El mlxbf_driver experimentará una excepción justo después de ejecutar su método de apagado(). Un ejemplo de esta excepción es: No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000070 Información de cancelación de memoria: ESR = 0x0000000096000004 EC = 0x25: DABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: error de traducción de nivel 0 Información de cancelación de datos: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 tabla de páginas de usuario: 4k páginas, VA de 48 bits, pgdp=000000011d373000 [0000000000000070] 000000000000, p4d=0000000000000000 Error interno: Ups: 96000004 [#1] CPU SMP: 0 PID: 13 Comm: ksoftirqd/0 Contaminado: GS OE 5.15.0-bf.6.gef6992a #1 Nombre de hardware: https://www.mellanox .com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 21 de abril de 2023 pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] lr: mlxbf_ gige_poll+ 0x54/0x160 [mlxbf_gige] sp: ffff8000080d3c10 x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58 x26: ffff0000814e7340 x25: a05000 x24: ffffcce72c4ea008 x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128 x20: 0000000000000000 x19: ffff0000814e4a80 ffffffffffffffff x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7 x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101 x11: 7f7f7f7f7f7f7f7f x10: ac898b17576267 x9: ffffcce720fa5404 x8: ffff000080812138 x7: 0000000000002e9a x6: 00000000000000080 x5: ffff00008de3b000 x4: 00000000000000000 x3: 0000000000000001 x2: 0000000000000000 x1: 0000000000000000 x0: 00000000000000000 Llamada seguimiento: mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] __napi_poll+0x40/0x1c8 net_rx_action+0x314/0x3a0 __do_softirq+0x128/0x334 _ksoftirqd+0x54/0x6c smpboot_thread_fn+0x14c/0x190 kthread+0x10c/0x110 ret_from_fork+ 0x10/0x20 Código: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002) ---[ seguimiento final 7cc3941aa0d8e6a4 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x4ce722520000 de 0xffff 800008000000 PHYS_OFFSET: 0x80000000 Características de la CPU: 0x000005c1,a3330e5a Límite de memoria: ninguno ---[ fin del pánico del kernel - no se sincroniza: Ups: excepción fatal en la interrupción ]--- Durante el apagado del sistema, el apagado() del controlador mlxbf_gige siempre se ejecuta. • https://git.kernel.org/stable/c/f92e1869d74e1acc6551256eb084a1c14a054e19 https://git.kernel.org/stable/c/63a10b530e22cc923008b5925821c26872f37971 https://git.kernel.org/stable/c/80247e0eca14ff177d565f58ecd3010f6b7910a4 https://git.kernel.org/stable/c/36a1cb0371aa6f0698910ee70cb4ed3c349f4fa4 https://git.kernel.org/stable/c/9783b3b0e71d704949214a8f76468f591a31f3f5 https://git.kernel.org/stable/c/09ba28e1cd3cf715daab1fca6e1623e22fd754a6 https://access.redhat.com/security/cve/CVE-2024-35885 https://bugzilla.redhat.com/show_bug.cgi?id=2281700 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35884 – udp: do not accept non-tunnel GSO skbs landing in a tunnel
https://notcve.org/view.php?id=CVE-2024-35884
In the Linux kernel, the following vulnerability has been resolved: udp: do not accept non-tunnel GSO skbs landing in a tunnel When rx-udp-gro-forwarding is enabled UDP packets might be GROed when being forwarded. If such packets might land in a tunnel this can cause various issues and udp_gro_receive makes sure this isn't the case by looking for a matching socket. This is performed in udp4/6_gro_lookup_skb but only in the current netns. This is an issue with tunneled packets when the endpoint is in another netns. In such cases the packets will be GROed at the UDP level, which leads to various issues later on. • https://git.kernel.org/stable/c/9fd1ff5d2ac7181844735806b0a703c942365291 https://git.kernel.org/stable/c/3391b157780bbedf8ef9f202cbf10ee90bf6b0f8 https://git.kernel.org/stable/c/d49ae15a5767d4e9ef8bbb79e42df1bfebc94670 https://git.kernel.org/stable/c/d12245080cb259d82b34699f6cd4ec11bdb688bd https://git.kernel.org/stable/c/3001e7aa43d6691db2a878b0745b854bf12ddd19 https://git.kernel.org/stable/c/35fe0e0b5c00bef7dde74842a2564c43856fbce4 https://git.kernel.org/stable/c/3d010c8031e39f5fa1e8b13ada77e0321091011f https://lists.debian.org/debian-lts-announce/2024/06/ •
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: -EPSS: 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 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35877 – x86/mm/pat: fix VM_PAT handling in COW mappings
https://notcve.org/view.php?id=CVE-2024-35877
In the Linux kernel, the following vulnerability has been resolved: x86/mm/pat: fix VM_PAT handling in COW mappings PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using follow_phys() from PTEs will not work in COW mappings. Using follow_phys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and track_pfn_copy(), not properly calling free_pfn_range(). In free_pfn_range(), we either wouldn't call memtype_free() or would call it with the wrong range, possibly leaking memory. To fix that, let's update follow_phys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings if we run into that. We will now properly handle untrack_pfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->track_pfn_copy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size. For now, lets keep it simple and let track_pfn_copy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios. Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn(): <--- C reproducer ---> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> #include <liburing.h> int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map; ring_fd = io_uring_setup(1, &p); if (ring_fd < 0) { perror("io_uring_setup"); return 1; } size = p.sq_off.array + p.sq_entries * sizeof(unsigned); /* Map the submission queue ring MAP_PRIVATE */ map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, ring_fd, IORING_OFF_SQ_RING); if (map == MAP_FAILED) { perror("mmap"); return 1; } /* We have at least one page. Let's COW it. */ *map = 0; pause(); return 0; } <--- C reproducer ---> On a system with 16 GiB RAM and swap configured: # . • https://git.kernel.org/stable/c/5899329b19100c0b82dc78e9b21ed8b920c9ffb3 https://git.kernel.org/stable/c/f18681daaec9665a15c5e7e0f591aad5d0ac622b https://git.kernel.org/stable/c/09e6bb53217bf388a0d2fd7fb21e74ab9dffc173 https://git.kernel.org/stable/c/c2b2430b48f3c9eaccd2c3d2ad75bb540d4952f4 https://git.kernel.org/stable/c/7cfee26d1950250b14c5cb0a37b142f3fcc6396a https://git.kernel.org/stable/c/97e93367e82752e475a33839a80b33bdbef1209f https://git.kernel.org/stable/c/51b7841f3fe84606ec0bd8da859d22e05e5419ec https://git.kernel.org/stable/c/1341e4b32e1fb1b0acd002ccd56f07bd3 •