CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-38633 – serial: max3100: Update uart_driver_registered on driver removal
https://notcve.org/view.php?id=CVE-2024-38633
In the Linux kernel, the following vulnerability has been resolved: serial: max3100: Update uart_driver_registered on driver removal The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 Update the actual state so next time UART driver will be registered again. Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uart_register_driver() call. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: max3100: actualización uart_driver_registered al eliminar el controlador La eliminación del último dispositivo MAX3100 desencadena la eliminación del controlador. Sin embargo, el código no actualiza la variable global respectiva y después del ciclo insmod — rmmod — insmod, el kernel falla: max3100 spi-PRP0001:01: max3100_probe: agregando el puerto 0 ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000408... • https://git.kernel.org/stable/c/7831d56b0a3544cbb6f82f76c34ca95e24d5b676 https://git.kernel.org/stable/c/21a61a7fbcfdd3493cede43ebc7c4dfae2147a8b https://git.kernel.org/stable/c/9db4222ed8cd3e50b81c8b910ae74c26427a4003 https://git.kernel.org/stable/c/e8e2a4339decad7e59425b594a98613402652d72 https://git.kernel.org/stable/c/361a92c9038e8c8c3996f8eeaa14522a8ad90752 https://git.kernel.org/stable/c/b6eb7aff23e05f362e8c9b560f6ac5e727b70e00 https://git.kernel.org/stable/c/e8a10089eddba40d4b2080c9d3fc2d2b2488f762 https://git.kernel.org/stable/c/fa84ca78b048dfb00df0ef446f5c35e0a •
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: 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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-4439 – isdn: cpai: check ctr->cnr to avoid array index out of bound
https://notcve.org/view.php?id=CVE-2021-4439
In the Linux kernel, the following vulnerability has been resolved: isdn: cpai: check ctr->cnr to avoid array index out of bound The cmtp_add_connection() would add a cmtp session to a controller and run a kernel thread to process cmtp. __module_get(THIS_MODULE); session->task = kthread_run(cmtp_session, session, "kcmtpd_ctr_%d", session->num); During this process, the kernel thread would call detach_capi_ctr() to detach a register controller. if the controller was not attached yet, detach_capi_ctr() would trigger an array-index-out-bounds bug. [ 46.866069][ T6479] UBSAN: array-index-out-of-bounds in drivers/isdn/capi/kcapi.c:483:21 [ 46.867196][ T6479] index -1 is out of range for type 'capi_ctr *[32]' [ 46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpd_ctr_0 Not tainted 5.15.0-rc2+ #8 [ 46.869002][ T6479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [ 46.870107][ T6479] Call Trace: [ 46.870473][ T6479] dump_stack_lvl+0x57/0x7d [ 46.870974][ T6479] ubsan_epilogue+0x5/0x40 [ 46.871458][ T6479] __ubsan_handle_out_of_bounds.cold+0x43/0x48 [ 46.872135][ T6479] detach_capi_ctr+0x64/0xc0 [ 46.872639][ T6479] cmtp_session+0x5c8/0x5d0 [ 46.873131][ T6479] ? __init_waitqueue_head+0x60/0x60 [ 46.873712][ T6479] ? cmtp_add_msgpart+0x120/0x120 [ 46.874256][ T6479] kthread+0x147/0x170 [ 46.874709][ T6479] ? set_kthread_struct+0x40/0x40 [ 46.875248][ T6479] ret_from_fork+0x1f/0x30 [ 46.875773][ T6479] • https://git.kernel.org/stable/c/e8b8de17e164c9f1b7777f1c6f99d05539000036 https://git.kernel.org/stable/c/24219a977bfe3d658687e45615c70998acdbac5a https://git.kernel.org/stable/c/9b6b2db77bc3121fe435f1d4b56e34de443bec75 https://git.kernel.org/stable/c/7d91adc0ccb060ce564103315189466eb822cc6a https://git.kernel.org/stable/c/285e9210b1fab96a11c0be3ed5cea9dd48b6ac54 https://git.kernel.org/stable/c/7f221ccbee4ec662e2292d490a43ce6c314c4594 https://git.kernel.org/stable/c/cc20226e218a2375d50dd9ac14fb4121b43375ff https://git.kernel.org/stable/c/1f3e2e97c003f80c4b087092b225c8787 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48769 – efi: runtime: avoid EFIv2 runtime services on Apple x86 machines
https://notcve.org/view.php?id=CVE-2022-48769
In the Linux kernel, the following vulnerability has been resolved: efi: runtime: avoid EFIv2 runtime services on Apple x86 machines Aditya reports [0] that his recent MacbookPro crashes in the firmware when using the variable services at runtime. The culprit appears to be a call to QueryVariableInfo(), which we did not use to call on Apple x86 machines in the past as they only upgraded from EFI v1.10 to EFI v2.40 firmware fairly recently, and QueryVariableInfo() (along with UpdateCapsule() et al) was added in EFI v2.00. The only runtime service introduced in EFI v2.00 that we actually use in Linux is QueryVariableInfo(), as the capsule based ones are optional, generally not used at runtime (all the LVFS/fwupd firmware update infrastructure uses helper EFI programs that invoke capsule update at boot time, not runtime), and not implemented by Apple machines in the first place. QueryVariableInfo() is used to 'safely' set variables, i.e., only when there is enough space. This prevents machines with buggy firmwares from corrupting their NVRAMs when they run out of space. Given that Apple machines have been using EFI v1.10 services only for the longest time (the EFI v2.0 spec was released in 2006, and Linux support for the newly introduced runtime services was added in 2011, but the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only), let's avoid the EFI v2.0 ones on all Apple x86 machines. [0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/ • https://git.kernel.org/stable/c/b0f1cc093bc2493ac259c53766fd2b800e085807 https://git.kernel.org/stable/c/3df52448978802ae15dcebf66beba1029df957b4 https://git.kernel.org/stable/c/a4085859411c825c321c9b55b8a9dc5a128a6684 https://git.kernel.org/stable/c/f5390cd0b43c2e54c7cf5506c7da4a37c5cef746 •