CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-38630 – watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
https://notcve.org/view.php?id=CVE-2024-38630
In the Linux kernel, the following vulnerability has been resolved: watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger When the cpu5wdt module is removing, the origin code uses del_timer() to de-activate the timer. If the timer handler is running, del_timer() could not stop it and will return directly. If the port region is released by release_region() and then the timer handler cpu5wdt_trigger() calls outb() to write into the region that is released, the use-after-free bug will happen. Change del_timer() to timer_shutdown_sync() in order that the timer handler could be finished before the port region is released. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/9b1c063ffc075abf56f63e55d70b9778ff534314 https://git.kernel.org/stable/c/f19686d616500cd0d47b30cee82392b53f7f784a https://git.kernel.org/stable/c/573601521277119f2e2ba5f28ae6e87fc594f4d4 •
CVSS: 5.6EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38627 – stm class: Fix a double free in stm_register_device()
https://notcve.org/view.php?id=CVE-2024-38627
In the Linux kernel, the following vulnerability has been resolved: stm class: Fix a double free in stm_register_device() The put_device(&stm->dev) call will trigger stm_device_release() which frees "stm" so the vfree(stm) on the next line is a double free. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clase stm: corrige un doble free en stm_register_device() La llamada put_device(&stm->dev) activará stm_device_release() que libera "stm" para que vfree(stm) en el La siguiente línea es un doble libre. A vulnerability was found in the Linux kernel's stm class, where an improper memory management sequence in stm_register_device() could lead to a double-free error. This issue occurs when the put_device(&stm->dev) call triggers stm_device_release() to free "stm", making the subsequent vfree(stm) call redundant and potentially harmful. • https://git.kernel.org/stable/c/389b6699a2aa0b457aa69986e9ddf39f3b4030fd https://git.kernel.org/stable/c/b0351a51ffda593b2b1b35dd0c00a73505edb256 https://git.kernel.org/stable/c/6cc30ef8eb6d8f8d6df43152264bbf8835d99931 https://git.kernel.org/stable/c/a0450d3f38e7c6c0a7c0afd4182976ee15573695 https://git.kernel.org/stable/c/713fc00c571dde4af3db2dbd5d1b0eadc327817b https://git.kernel.org/stable/c/7419df1acffbcc90037f6b5a2823e81389659b36 https://git.kernel.org/stable/c/4bfd48bb6e62512b9c392c5002c11e1e3b18d247 https://git.kernel.org/stable/c/370c480410f60b90ba3e96abe73ead21e • CWE-415: Double Free •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38621 – media: stk1160: fix bounds checking in stk1160_copy_video()
https://notcve.org/view.php?id=CVE-2024-38621
In the Linux kernel, the following vulnerability has been resolved: media: stk1160: fix bounds checking in stk1160_copy_video() The subtract in this condition is reversed. The ->length is the length of the buffer. The ->bytesused is how many bytes we have copied thus far. When the condition is reversed that means the result of the subtraction is always negative but since it's unsigned then the result is a very high positive value. That means the overflow check is never true. Additionally, the ->bytesused doesn't actually work for this purpose because we're not writing to "buf->mem + buf->bytesused". • https://git.kernel.org/stable/c/9cb2173e6ea8f2948bd1367c93083a2500fcf08f https://git.kernel.org/stable/c/f6a392266276730bea893b55d12940e32a25f56a https://git.kernel.org/stable/c/ecf4ddc3aee8ade504c4d36b7b4053ce6093e200 https://git.kernel.org/stable/c/a16775828aaed1c54ff4e6fe83e8e4d5c6a50cb7 https://git.kernel.org/stable/c/7532bcec0797adfa08791301c3bcae14141db3bd https://git.kernel.org/stable/c/b504518a397059e1d55c521ba0ea2b545a6c4b52 https://git.kernel.org/stable/c/d410017a7181cb55e4a5c810b32b75e4416c6808 https://git.kernel.org/stable/c/a08492832cc4cacc24e0612f483c86ca8 •
CVSS: 6.6EPSS: 0%CPEs: 8EXPL: 0CVE-2024-37356 – tcp: Fix shift-out-of-bounds in dctcp_update_alpha().
https://notcve.org/view.php?id=CVE-2024-37356
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix shift-out-of-bounds in dctcp_update_alpha(). In dctcp_update_alpha(), we use a module parameter dctcp_shift_g as follows: alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g); ... delivered_ce <<= (10 - dctcp_shift_g); It seems syzkaller started fuzzing module parameters and triggered shift-out-of-bounds [0] by setting 100 to dctcp_shift_g: memcpy((void*)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47); res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul, /*flags=*/2ul, /*mode=*/0ul); memcpy((void*)0x20000000, "100\000", 4); syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul); Let's limit the max value of dctcp_shift_g by param_set_uint_minmax(). With this patch: # echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g 10 # echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g -bash: echo: write error: Invalid argument [0]: UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12 shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468 dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143 tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline] tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948 tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711 tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937 sk_backlog_rcv include/net/sock.h:1106 [inline] __release_sock+0x20f/0x350 net/core/sock.c:2983 release_sock+0x61/0x1f0 net/core/sock.c:3549 mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976 __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072 mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127 inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:659 [inline] sock_close+0xc0/0x240 net/socket.c:1421 __fput+0x41b/0x890 fs/file_table.c:422 task_work_run+0x23b/0x300 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x9c8/0x2540 kernel/exit.c:878 do_group_exit+0x201/0x2b0 kernel/exit.c:1027 __do_sys_exit_group kernel/exit.c:1038 [inline] __se_sys_exit_group kernel/exit.c:1036 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Code: Unable to access opcode bytes at 0x7f6c2b50058c. RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: corrige el desplazamiento fuera de los límites en dctcp_update_alpha(). En dctcp_update_alpha(), utilizamos un parámetro de módulo dctcp_shift_g de la siguiente manera: alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g); ... entregado_ce <<= (10 - dctcp_shift_g); Parece que syzkaller comenzó a modificar los parámetros del módulo y activó el desplazamiento fuera de los límites [0] estableciendo 100 en dctcp_shift_g: memcpy((void*)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47) ; res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul, /*flags=*/2ul, /*mode=*/0ul); memcpy((void*)0x20000000, "100\000", 4); syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul); Limitemos el valor máximo de dctcp_shift_g mediante param_set_uint_minmax(). Con este parche: # echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g 10 # echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g -bash: echo: error de escritura: argumento no válido [0]: UBSAN: desplazamiento fuera de los límites en net/ipv4/tcp_dctcp.c:143:12 el exponente de desplazamiento 100 es demasiado grande para el tipo 'u32' de 32 bits (también conocido como 'int sin signo' ) CPU: 0 PID: 8083 Comm: syz-executor345 No contaminado 6.9.0-05151-g1b294a1f3561 #2 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114 ubsan_epilogue lib/ubsan.c:231 [en línea] __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c :468 dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143 tcp_in_ack_event net/ipv4/tcp_input.c:3802 [en línea] tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948 v_state_process+0x57a/0x2290 neto/ ipv4/tcp_input.c:6711 tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937 sk_backlog_rcv include/net/sock.h:1106 [en línea] __release_sock+0x20f/0x350 net/core/sock.c:2983 release_sock+ 0x61/0x1f0 net/core/sock.c:3549 mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976 __mptcp_close+0x238/0x ad0 net/mptcp/protocolo .c:3072 mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127 inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:659 [en línea] sock_close+0xc0/0x240 net/ socket.c:1421 __fput+0x41b/0x890 fs/file_table.c:422 task_work_run+0x23b/0x300 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [en línea] do_exit+0x9c8/0x2540 kernel/exit .c:878 do_group_exit+0x201/0x2b0 kernel/exit.c:1027 __do_sys_exit_group kernel/exit.c:1038 [en línea] __se_sys_exit_group kernel/exit.c:1036 [en línea] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:10 36 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Código: no se puede acceder a los bytes del código de operación en 0x7f6c2b50058c . RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 06 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 • https://git.kernel.org/stable/c/e3118e8359bb7c59555aca60c725106e6d78c5ce https://git.kernel.org/stable/c/06d0fe049b51b0a92a70df8333fd85c4ba3eb2c6 https://git.kernel.org/stable/c/6aacaa80d962f4916ccf90e2080306cec6c90fcf https://git.kernel.org/stable/c/e9b2f60636d18dfd0dd4965b3316f88dfd6a2b31 https://git.kernel.org/stable/c/8602150286a2a860a1dc55cbd04f99316f19b40a https://git.kernel.org/stable/c/e65d13ec00a738fa7661925fd5929ab3c765d4be https://git.kernel.org/stable/c/02261d3f9dc7d1d7be7d778f839e3404ab99034c https://git.kernel.org/stable/c/237340dee373b97833a491d2e99fcf1d4 • CWE-125: Out-of-bounds Read •
CVSS: 4.7EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36286 – netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()
https://notcve.org/view.php?id=CVE-2024-36286
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu() syzbot reported that nf_reinject() could be called without rcu_read_lock() : WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172 stack backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK> En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nfnetlink_queue: adquirir rcu_read_lock() en instancia_destroy_rcu() syzbot informó que se podía llamar a nf_reinject() sin rcu_read_lock() : ADVERTENCIA: uso sospechoso de RCU 6.9.0-rc7-syzkaller -02060-g5c1672705a1a #0 ¡No está contaminado net/netfilter/nfnetlink_queue.c:263 uso sospechoso de rcu_dereference_check()! otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 2 bloqueos mantenidos por syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, en: rcu_lock_acquire include/linux/rcupdate.h:329 [en línea] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, en: rcu_do_batch kernel/rcu/tree.c:2190 [en línea] #0 : ffffffff8e334f60 (rcu_callback){....}-{0:0}, en: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.} -{2:2}, en: spin_lock_bh include/linux/spinlock.h:356 [en línea] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, en: nfqnl_flush net/ netfilter/nfnetlink_queue.c:405 [en línea] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, en: instancia_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172 pila backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 No contaminado 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Llamada de Google 02/04/2024 Trace: __dump_stack lib/dump_stack.c: 88 [en línea] dump_stack_lvl+0x241/0x360 lib/dump_stack.c: 114 Lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c: 6712 nf_filt. C :323 [en línea] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [en línea] instancia_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 do_batch kernel/rcu /tree.c:2196 [en línea] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [en línea] invoke_softirq kernel/softirq .c:428 [en línea] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [en línea] r_interrupción+ 0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 • https://git.kernel.org/stable/c/9872bec773c2e8503fec480c1e8a0c732517e257 https://git.kernel.org/stable/c/8658bd777cbfcb0c13df23d0ea120e70517761b9 https://git.kernel.org/stable/c/3989b817857f4890fab9379221a9d3f52bf5c256 https://git.kernel.org/stable/c/e01065b339e323b3dfa1be217fd89e9b3208b0ab https://git.kernel.org/stable/c/25ea5377e3d2921a0f96ae2551f5ab1b36825dd4 https://git.kernel.org/stable/c/68f40354a3851df46c27be96b84f11ae193e36c5 https://git.kernel.org/stable/c/8f365564af898819a523f1a8cf5c6ce053e9f718 https://git.kernel.org/stable/c/215df6490e208bfdd5b3012f5075e7f87 • CWE-667: Improper Locking •