CVSS: 5.5EPSS: 0%CPEs: 11EXPL: 0CVE-2024-38598 – md: fix resync softlockup when bitmap size is less than array size
https://notcve.org/view.php?id=CVE-2024-38598
In the Linux kernel, the following vulnerability has been resolved: md: fix resync softlockup when bitmap size is less than array size Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup: kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976] CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:_raw_spin_unlock_irq+0x13/0x30 Call Trace: <TASK> md_bitmap_start_sync+0x6b/0xf0 raid10_sync_request+0x25c/0x1b40 [raid10] md_do_sync+0x64b/0x1020 md_thread+0xa7/0x170 kthread+0xcf/0x100 ret_from_fork+0x30/0x50 ret_from_fork_asm+0x1a/0x30 And the detailed process is as follows: md_do_sync j = mddev->resync_min while (j < max_sectors) sectors = raid10_sync_request(mddev, j, &skipped) if (!md_bitmap_start_sync(..., &sync_blocks)) // md_bitmap_start_sync set sync_blocks to 0 return sync_blocks + sectors_skippe; // sectors = 0; j += sectors; // j never change Root cause is that commit 301867b1c168 ("md/raid10: check slab-out-of-bounds in md_bitmap_get_counter") return early from md_bitmap_get_counter(), without setting returned blocks. Fix this problem by always set returned blocks from md_bitmap_get_counter"(), as it used to be. Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn't match array size still need to be fixed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: corrige el bloqueo suave de resincronización cuando el tamaño del mapa de bits es menor que el tamaño de la matriz. Se informa que para dm-raid10, lvextend + lvchange --syncaction activará el siguiente bloqueo suave: kernel:watchdog: ERROR : bloqueo suave - ¡CPU n.° 3 bloqueada durante 26 segundos! • https://git.kernel.org/stable/c/374fb914304d9b500721007f3837ea8f1f9a2418 https://git.kernel.org/stable/c/b0b971fe7d61411ede63c3291764dbde1577ef2c https://git.kernel.org/stable/c/39fa14e824acfd470db4f42c354297456bd82b53 https://git.kernel.org/stable/c/a134dd582c0d5b6068efa308bd485cf1d00b3f65 https://git.kernel.org/stable/c/be1a3ec63a840cc9e59a033acf154f56255699a1 https://git.kernel.org/stable/c/301867b1c16805aebbc306aafa6ecdc68b73c7e5 https://git.kernel.org/stable/c/152bb26796ff054af50b2ee1b3ca56e364e4f61b https://git.kernel.org/stable/c/bea301c046110bf421a3ce153fb868cb8 • CWE-667: Improper Locking •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-38597 – eth: sungem: remove .ndo_poll_controller to avoid deadlocks
https://notcve.org/view.php?id=CVE-2024-38597
In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: eth: sungem: elimine .ndo_poll_controller para evitar interbloqueos Erhard informa advertencias de netpoll desde sungem: netpoll_send_skb_on_dev(): eth0 habilitó interrupciones en la encuesta (gem_start_xmit+0x0/0x398) ADVERTENCIA: CPU: 1 PID: 1 en net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() desactiva las interrupciones, que pueden dormir. No podemos dormir en netpoll, tiene las interrupciones desactivadas por completo. Curiosamente, gem_poll_controller() ni siquiera sondea las finalizaciones y, en cambio, actúa como si se hubiera disparado una interrupción, por lo que simplemente programa NAPI y sale. • https://git.kernel.org/stable/c/fe09bb619096a0aa139210748ddc668c2dbe2308 https://git.kernel.org/stable/c/e22b23f5888a065d084e87db1eec639c445e677f https://git.kernel.org/stable/c/fbeeb55dbb33d562149c57e794f06b7414e44289 https://git.kernel.org/stable/c/476adb3bbbd7886e8251d3b9ce2d3c3e680f35d6 https://git.kernel.org/stable/c/5de5aeb98f9a000adb0db184e32765e4815d860b https://git.kernel.org/stable/c/faf94f1eb8a34b2c31b2042051ef36f63420ecce https://git.kernel.org/stable/c/6400d205fbbcbcf9b8510157e1f379c1d7e2e937 https://git.kernel.org/stable/c/ac0a230f719b02432d8c7eba7615ebd69 •
CVSS: 4.7EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38596 – af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
https://notcve.org/view.php?id=CVE-2024-38596
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg A data-race condition has been identified in af_unix. In one data path, the write function unix_release_sock() atomically writes to sk->sk_shutdown using WRITE_ONCE. However, on the reader side, unix_stream_sendmsg() does not read it atomically. Consequently, this issue is causing the following KCSAN splat to occur: BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28: unix_release_sock (net/unix/af_unix.c:640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket.c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/fca6072e1a7b1e709ada5604b951513b89b4bd0a https://git.kernel.org/stable/c/de6641d213373fbde9bbdd7c4b552254bc9f82fe https://git.kernel.org/stable/c/4d51845d734a4c5d079e56e0916f936a55e15055 https://git.kernel.org/stable/c/9aa8773abfa0e954136875b4cbf2df4cf638e8a5 https://git.kernel.org/stable/c/8299e4d778f664b31b67cf4cf3d5409de2ecb92c https://git.kernel.org/stable/c/0688d4e499bee3f2749bca27329bd128686230cb https://git.kernel.org/stable/c/a4c88072abcaca593cefe70f90e9d3707 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-38595 – net/mlx5: Fix peer devlink set for SF representor devlink port
https://notcve.org/view.php?id=CVE-2024-38595
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix peer devlink set for SF representor devlink port The cited patch change register devlink flow, and neglect to reflect the changes for peer devlink set logic. Peer devlink set is triggering a call trace if done after devl_register.[1] Hence, align peer devlink set logic with register devlink flow. [1] WARNING: CPU: 4 PID: 3394 at net/devlink/core.c:155 devlink_rel_nested_in_add+0x177/0x180 CPU: 4 PID: 3394 Comm: kworker/u40:1 Not tainted 6.9.0-rc4_for_linust_min_debug_2024_04_16_14_08 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_vhca_event0 mlx5_vhca_state_work_handler [mlx5_core] RIP: 0010:devlink_rel_nested_in_add+0x177/0x180 Call Trace: <TASK> ? __warn+0x78/0x120 ? devlink_rel_nested_in_add+0x177/0x180 ? report_bug+0x16d/0x180 ? • https://git.kernel.org/stable/c/967caa3d37c078e5b95a32094657e6a4cad145f0 https://git.kernel.org/stable/c/bf729988303a27833a86acb561f42b9a3cc12728 https://git.kernel.org/stable/c/8c91c60858473731bcdaf04fda99fcbcf84420d4 https://git.kernel.org/stable/c/8256c1211dc6fa606269aa043b6e294247820b31 https://git.kernel.org/stable/c/a0501201751034ebe7a22bd9483ed28fea1cd213 https://git.kernel.org/stable/c/05d9d7b66836d87c914f8fdd4b062b78e373458d https://git.kernel.org/stable/c/3c453e8cc672de1f9c662948dba43176bc68d7f0 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-38594 – net: stmmac: move the EST lock to struct stmmac_priv
https://notcve.org/view.php?id=CVE-2024-38594
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: move the EST lock to struct stmmac_priv Reinitialize the whole EST structure would also reset the mutex lock which is embedded in the EST structure, and then trigger the following warning. To address this, move the lock to struct stmmac_priv. We also need to reacquire the mutex lock when doing this initialization. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068 Modules linked in: CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0xd84/0x1068 lr : __mutex_lock+0xd84/0x1068 sp : ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698 x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027 x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: __mutex_lock+0xd84/0x1068 mutex_lock_nested+0x28/0x34 tc_setup_taprio+0x118/0x68c stmmac_setup_tc+0x50/0xf0 taprio_change+0x868/0xc9c En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: stmmac: mover el bloqueo EST a la estructura stmmac_priv Reinicializar toda la estructura EST también restablecería el bloqueo mutex que está incrustado en la estructura EST y luego activaría la siguiente advertencia. Para solucionar esto, mueva el candado a la estructura stmmac_priv. • https://git.kernel.org/stable/c/b2aae654a4794ef898ad33a179f341eb610f6b85 https://git.kernel.org/stable/c/b2091d47a14e8e6b3f03d792c1b25255d60b3219 https://git.kernel.org/stable/c/5ce4cc16d47186f0b76254e6f27beea25bafc1d9 https://git.kernel.org/stable/c/b538fefeb1026aad9dcdcbb410c42b56dff8aae9 https://git.kernel.org/stable/c/487f9030b1ef34bab123f2df2a4ccbe01ba84416 https://git.kernel.org/stable/c/6f476aff2d8da1a189621c4c16a76a6c534e4312 https://git.kernel.org/stable/c/36ac9e7f2e5786bd37c5cd91132e1f39c29b8197 •