CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26869 – f2fs: fix to truncate meta inode pages forcely
https://notcve.org/view.php?id=CVE-2024-26869
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to truncate meta inode pages forcely Below race case can cause data corruption: Thread A GC thread - gc_data_segment - ra_data_block - locked meta_inode page - f2fs_inplace_write_data - invalidate_mapping_pages : fail to invalidate meta_inode page due to lock failure or dirty|writeback status - f2fs_submit_page_bio : write last dirty data to old blkaddr - move_data_block - load old data from meta_inode page - f2fs_submit_page_write : write old data to new blkaddr Because invalidate_mapping_pages() will skip invalidating page which has unclear status including locked, dirty, writeback and so on, so we need to use truncate_inode_pages_range() instead of invalidate_mapping_pages() to make sure meta_inode page will be dropped. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para truncar las páginas de meta-inodo a la fuerza El siguiente caso de carrera puede causar corrupción de datos: Hilo Un hilo de GC - gc_data_segment - ra_data_block - página de meta_inodo bloqueada - f2fs_inplace_write_data - invalidate_mapping_pages: no se puede invalidar meta_inode página debido a falla de bloqueo o estado sucio|reescritura - f2fs_submit_page_bio: escribe los últimos datos sucios en el blkaddr antiguo - move_data_block - carga datos antiguos de la página meta_inode - f2fs_submit_page_write: escribe datos antiguos en el blkaddr nuevo Porque invalidate_mapping_pages() omitirá la página de invalidación cuyo estado no está claro incluyendo bloqueado, sucio, reescritura, etc., por lo que debemos usar truncate_inode_pages_range() en lugar de invalidate_mapping_pages() para asegurarnos de que la página meta_inode se elimine. • https://git.kernel.org/stable/c/6aa58d8ad20a3323f42274c25820a6f54192422d https://git.kernel.org/stable/c/c92f2927df860a60ba815d3ee610a944b92a8694 https://git.kernel.org/stable/c/77bfdb89cc222fc7bfe198eda77bdc427d5ac189 https://git.kernel.org/stable/c/04226d8e3c4028dc451e9d8777356ec0f7919253 https://git.kernel.org/stable/c/9f0c4a46be1fe9b97dbe66d49204c1371e3ece65 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26866 – spi: lpspi: Avoid potential use-after-free in probe()
https://notcve.org/view.php?id=CVE-2024-26866
In the Linux kernel, the following vulnerability has been resolved: spi: lpspi: Avoid potential use-after-free in probe() fsl_lpspi_probe() is allocating/disposing memory manually with spi_alloc_host()/spi_alloc_target(), but uses devm_spi_register_controller(). In case of error after the latter call the memory will be explicitly freed in the probe function by spi_controller_put() call, but used afterwards by "devm" management outside probe() (spi_unregister_controller() <- devm_spi_unregister() below). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 ... Call trace: kernfs_find_ns kernfs_find_and_get_ns sysfs_remove_group sysfs_remove_groups device_remove_attrs device_del spi_unregister_controller devm_spi_unregister release_nodes devres_release_all really_probe driver_probe_device __device_attach_driver bus_for_each_drv __device_attach device_initial_probe bus_probe_device deferred_probe_work_func process_one_work worker_thread kthread ret_from_fork En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: lpspi: evita el posible use-after-free en probe() fsl_lpspi_probe() está asignando/eliminando memoria manualmente con spi_alloc_host()/spi_alloc_target(), pero usa devm_spi_register_controller() . En caso de error después de la última llamada, la memoria se liberará explícitamente en la función de sonda mediante la llamada a spi_controller_put(), pero la administración "devm" externa a probe() la utilizará después (spi_unregister_controller() <- devm_spi_unregister() a continuación). No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 0000000000000070... Rastreo de llamadas: kernfs_find_ns kernfs_find_and_get_ns sysfs_remove_group sysfs_remove_groups device_remove_attrs device_del spi_unregister_controller devm_spi_unregister release_nodes devres_release _todos realmente_probe driver_probe_device __device_attach_driver bus_for_each_drv __device_attach dispositivo_initial_probe bus_probe_device deferred_probe_work_func proceso_one_work trabajador_hilo kthread ret_from_fork • https://git.kernel.org/stable/c/5314987de5e5f5e38436ef4a69328bc472bbd63e https://git.kernel.org/stable/c/da83ed350e4604b976e94239b08d8e2e7eaee7ea https://git.kernel.org/stable/c/1543418e82789cc383cd36d41469983c64e3fc7f https://git.kernel.org/stable/c/996ce839606afd0fef91355627868022aa73eb68 https://git.kernel.org/stable/c/2ae0ab0143fcc06190713ed81a6486ed0ad3c861 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26865 – rds: tcp: Fix use-after-free of net in reqsk_timer_handler().
https://notcve.org/view.php?id=CVE-2024-26865
In the Linux kernel, the following vulnerability has been resolved: rds: tcp: Fix use-after-free of net in reqsk_timer_handler(). syzkaller reported a warning of netns tracker [0] followed by KASAN splat [1] and another ref tracker warning [1]. syzkaller could not find a repro, but in the log, the only suspicious sequence was as follows: 18:26:22 executing program 1: r0 = socket$inet6_mptcp(0xa, 0x1, 0x106) ... connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async) The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT. So, the scenario would be: 1. unshare(CLONE_NEWNET) creates a per netns tcp listener in rds_tcp_listen_init(). 2. syz-executor connect()s to it and creates a reqsk. 3. syz-executor exit()s immediately. 4. netns is dismantled. [0] 5. reqsk timer is fired, and UAF happens while freeing reqsk. [1] 6. listener is freed after RCU grace period • https://git.kernel.org/stable/c/467fa15356acfb7b2efa38839c3e76caa4e6e0ea https://git.kernel.org/stable/c/9905a157048f441f1412e7bd13372f4a971d75c6 https://git.kernel.org/stable/c/f901ee07853ce97e9f1104c7c898fbbe447f0279 https://git.kernel.org/stable/c/9ceac040506a05a30b104b2aa2e9146810704500 https://git.kernel.org/stable/c/1e9fd5cf8d7f487332560f7bb312fc7d416817f3 https://git.kernel.org/stable/c/2a750d6a5b365265dbda33330a6188547ddb5c24 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26863 – hsr: Fix uninit-value access in hsr_get_node()
https://notcve.org/view.php?id=CVE-2024-26863
In the Linux kernel, the following vulnerability has been resolved: hsr: Fix uninit-value access in hsr_get_node() KMSAN reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 ===================================================== If the packet type ID field in the Ethernet header is either ETH_P_PRP or ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr() reads an invalid value as a sequence number. This causes the above issue. This patch fixes the issue by returning NULL if the Ethernet header is not followed by an HSR tag. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: hsr: corrigió el acceso a valores uninit en hsr_get_node() KMSAN informó el siguiente problema de acceso a valores uninit [1]: ============== ======================================= ERROR: KMSAN: valor uninit en hsr_get_node+0xa2e /0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [en línea] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c :615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [en línea] netdev_start_xmit include/linux/netdevice.h:4954 [en línea] xmit_one net/core/dev.c :3548 [en línea] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [en línea] paquete_xmit+0x9c/ 0x6b0 net/packet/af_packet.c:276 paquete_snd net/packet/af_packet.c:3087 [en línea] paquete_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg neto /socket.c:745 [en línea] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [en línea] __se_sys_sendto net/socket.c:2199 [en línea] __x64_sys_sendto+0x125/0x1c0 socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit se creó en slab_post_alloc_hook+0x129/ 0xa70 mm/slab.h: 768 slab_alloc_node mm/slub.c: 3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c: 3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c: 560 __b.biloc. 740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [en línea] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 paquete_alloc_skb net/packet/af_packet.c:2936 [en línea] paquete_snd net/packet/af_packet.c:3030 [en línea] paquete_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [en línea ] __sock_sendmsg net/socket.c:745 [en línea] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [en línea] __se_sys_sendto net/socket.c:2199 [en línea] x125/ 0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 ============== ======================================== Si el campo ID de tipo de paquete en el encabezado Ethernet es ETH_P_PRP o ETH_P_HSR, pero no va seguido de una etiqueta HSR, hsr_get_skb_sequence_nr() lee un valor no válido como un número de secuencia. Esto causa el problema anterior. Este parche soluciona el problema al devolver NULL si el encabezado Ethernet no va seguido de una etiqueta HSR. • https://git.kernel.org/stable/c/f266a683a4804dc499efc6c2206ef68efed029d0 https://git.kernel.org/stable/c/e3b2bfb8ff1810a537b2aa55ba906a6743ed120c https://git.kernel.org/stable/c/889ed056eae7fda85b769a9ab33c093379c45428 https://git.kernel.org/stable/c/7fb2d4d6bb1c85f7a23aace0ed6c86a95dea792a https://git.kernel.org/stable/c/a809bbfd0e503351d3051317288a70a4569a4949 https://git.kernel.org/stable/c/1ed222ca7396938eb1ab2d034f1ba0d8b00a7122 https://git.kernel.org/stable/c/39cc316fb3bc5e7c9dc5eed314fe510d119c6862 https://git.kernel.org/stable/c/97d2148ea435dff4b4e71817c9032eb32 •
CVSS: 4.1EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26859 – net/bnx2x: Prevent access to a freed page in page_pool
https://notcve.org/view.php?id=CVE-2024-26859
In the Linux kernel, the following vulnerability has been resolved: net/bnx2x: Prevent access to a freed page in page_pool Fix race condition leading to system crash during EEH error handling During EEH error recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset tasks. The bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(), which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload() SGEs are freed using bnx2x_free_rx_sge_range(). However, this could overlap with the EEH driver's attempt to reset the device using bnx2x_io_slot_reset(), which also tries to free SGEs. This race condition can result in system crashes due to accessing freed memory locations in bnx2x_free_rx_sge() 799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp, 800 struct bnx2x_fastpath *fp, u16 index) 801 { 802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index]; 803 struct page *page = sw_buf->page; .... where sw_buf was set to NULL after the call to dma_unmap_page() by the preceding thread. EEH: Beginning: 'slot_reset' PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset() bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing... bnx2x 0011:01:00.0: enabling device (0140 -> 0142) bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload Kernel attempted to read user page (0) - exploit attempt? • https://git.kernel.org/stable/c/4cace675d687ebd2d813e90af80ff87ee85202f9 https://git.kernel.org/stable/c/7bcc090c81116c66936a7415f2c6b1483a4bcfd9 https://git.kernel.org/stable/c/4f37d3a7e004bbf560c21441ca9c022168017ec4 https://git.kernel.org/stable/c/8eebff95ce9558be66a36aa7cfb43223f3ab4699 https://git.kernel.org/stable/c/8ffcd3ccdbda0c918c4a0f922ef1c17010f1b598 https://git.kernel.org/stable/c/cf7d8cba639ae792a42c2a137b495eac262ac36c https://git.kernel.org/stable/c/3a9f78b297e08ca8e88ae3ecff1f6fe2766dc5eb https://git.kernel.org/stable/c/c51f8b6930db3f259b8820b589f2459d2 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •