Page 191 of 2565 results (0.010 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: dm: call the resume method on internal suspend There is this reported crash when experimenting with the lvm2 testsuite. The list corruption is caused by the fact that the postsuspend and resume methods were not paired correctly; there were two consecutive calls to the origin_postsuspend function. The second call attempts to remove the "hash_list" entry from a list, while it was already removed by the first call. Fix __dm_internal_resume so that it calls the preresume and resume methods of the table's targets. If a preresume method of some target fails, we are in a tricky situation. We can't return an error because dm_internal_resume isn't supposed to return errors. We can't return success, because then the "resume" and "postsuspend" methods would not be paired correctly. So, we set the DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace tools, but it won't cause a kernel crash. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:56! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0 <snip> RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282 RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058 R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001 R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0 FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0 Call Trace: <TASK> ? • https://git.kernel.org/stable/c/ffcc39364160663cda1a3c358f4537302a92459b https://git.kernel.org/stable/c/69836d9329f0b4c58faaf3d886a7748ddb5bf718 https://git.kernel.org/stable/c/da7ece2197101b1469853e6b5e915be1e3896d52 https://git.kernel.org/stable/c/f89bd27709376d37ff883067193320c58a8c1d5a https://git.kernel.org/stable/c/03ad5ad53e51abf3a4c7538c1bc67a5982b41dc5 https://git.kernel.org/stable/c/ad10289f68f45649816cc68eb93f45fd5ec48a15 https://git.kernel.org/stable/c/15a3fc5c8774c17589dabfe1d642d40685c985af https://git.kernel.org/stable/c/ef02d8edf738557af2865c5bfb66a03c4 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •

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

In the Linux kernel, the following vulnerability has been resolved: quota: Fix potential NULL pointer dereference Below race may cause NULL pointer dereference P1 P2 dquot_free_inode quota_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... If dquot_free_inode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered. So let's fix it by using a temporary pointer to avoid this issue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cuota: corrige una posible desreferencia del puntero NULL La siguiente carrera puede causar una desreferencia del puntero NULL P1 P2 dquot_free_inode quote_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[tipo] = NULL (2) spin_lock(&amp;dquots[cnt]-&gt;dq_dqb_lock) (3) .... Si dquot_free_inode(u otras rutinas) verifica los punteros de cuota del inodo (1) antes de que cuota_off lo establezca a NULL(2) y usarlo (3) después de eso, se activará la desreferencia del puntero NULL. • https://git.kernel.org/stable/c/8514899c1a4edf802f03c408db901063aa3f05a1 https://git.kernel.org/stable/c/49669f8e7eb053f91d239df7b1bfb4500255a9d0 https://git.kernel.org/stable/c/61380537aa6dd32d8a723d98b8f1bd1b11d8fee0 https://git.kernel.org/stable/c/1ca72a3de915f87232c9a4cb9bebbd3af8ed3e25 https://git.kernel.org/stable/c/7f9e833fc0f9b47be503af012eb5903086939754 https://git.kernel.org/stable/c/40a673b4b07efd6f74ff3ab60f38b26aa91ee5d5 https://git.kernel.org/stable/c/f2649d98aa9ca8623149b3cb8df00c944f5655c7 https://git.kernel.org/stable/c/6afc9f4434fa8063aa768c2bf5bf98583 • CWE-476: NULL Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix uaf in pvr2_context_set_notify [Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26 CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272 Freed by task 906: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inline] slab_free mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158 [Analyze] Task A set disconnect_flag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue. [Fix] Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect() to avoid this issue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: pvrusb2: corrige uaf en pvr2_context_set_notify [Syzbot informó] ERROR: KASAN: slab-use-after-free en pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2 -context.c:35 Lectura del tamaño 4 en la dirección ffff888113aeb0d8 por tarea kworker/1:1/26 CPU: 1 PID: 26 Comm: kworker/1:1 No contaminado 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 Cola de trabajo: usb_hub_wq hub_event Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c :106 print_address_description mm/kasan/report.c:377 [en línea] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 controladores/ media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify controladores/media/usb/pvrusb2/pvrusb2-context.c:95 [en línea] pvr2_context_disconnect+0x94/0xb0 controladores/media/usb/pvrusb2/pvrusb2-context.c :272 Liberado por la tarea 906: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 veneno_slab_object mm/kasan/common.c:241 [en línea] __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [en línea] slab_free_hook mm/slub.c:2121 [en línea] slab_free mm/slub.c:4299 [en línea] kfree+0x105/0x340 mm/slub.c:4409 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [en línea] pvr2_context_thread_func+0x69d/0x960 controladores/medios /usb/pvrusb2/pvrusb2-context.c:158 [Analizar] La tarea A estableció desconectar_flag = !0, lo que resultó en que se cumpliera la condición de la tarea B y se liberara mp, lo que generó este problema. [Solución] Coloque la operación de asignaciónconnect_flag después de todo el código en pvr2_context_disconnect() para evitar este problema. • https://git.kernel.org/stable/c/e5be15c63804e05b5a94197524023702a259e308 https://git.kernel.org/stable/c/ed8000e1e8e9684ab6c30cf2b526c0cea039929c https://git.kernel.org/stable/c/d29ed08964cec8b9729bc55c7bb23f679d7a18fb https://git.kernel.org/stable/c/ab896d93fd6a2cd1afeb034c3cc9226cb499209f https://git.kernel.org/stable/c/eb6e9dce979c08210ff7249e5e0eceb8991bfcd7 https://git.kernel.org/stable/c/3a1ec89708d2e57e2712f46241282961b1a7a475 https://git.kernel.org/stable/c/8e60b99f6b7ccb3badeb512f5eb613ad45904592 https://git.kernel.org/stable/c/40cd818fae875c424a8335009db33c7b5 • CWE-416: Use After Free •

CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Do not register event handler until srpt device is fully setup Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/srpt: no registrar el controlador de eventos hasta que el dispositivo srpt esté completamente configurado. En raras ocasiones, KASAN informa una escritura de use-after-free en srpt_refresh_port(). Esto parece deberse a que se registra un controlador de eventos antes de que el dispositivo srpt esté completamente configurado y una condición de carrera en caso de error puede dejar en su lugar un controlador de eventos parcialmente configurado. En su lugar, registre el controlador de eventos solo después de que se complete la inicialización del dispositivo srpt. • https://git.kernel.org/stable/c/a42d985bd5b234da8b61347a78dc3057bf7bb94d https://git.kernel.org/stable/c/bdd895e0190c464f54f84579e7535d80276f0fc5 https://git.kernel.org/stable/c/6413e78086caf7bf15639923740da0d91fdfd090 https://git.kernel.org/stable/c/e362d007294955a4fb929e1c8978154a64efdcb6 https://git.kernel.org/stable/c/85570b91e4820a0db9d9432098778cafafa7d217 https://git.kernel.org/stable/c/7104a00fa37ae898a827381f1161fa3286c8b346 https://git.kernel.org/stable/c/ec77fa12da41260c6bf9e060b89234b980c5130f https://git.kernel.org/stable/c/c21a8870c98611e8f892511825c9607f1 • CWE-416: Use After Free •

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

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 •