CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-35914 – nfsd: Fix error cleanup path in nfsd_rename()
https://notcve.org/view.php?id=CVE-2024-35914
In the Linux kernel, the following vulnerability has been resolved: nfsd: Fix error cleanup path in nfsd_rename() Commit a8b0026847b8 ("rename(): avoid a deadlock in the case of parents having no common ancestor") added an error bail out path. However this path does not drop the remount protection that has been acquired. Fix the cleanup path to properly drop the remount protection. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrigió la ruta de limpieza de errores en nfsd_rename() Confirme a8b0026847b8 ("rename(): evite un punto muerto en el caso de que los padres no tengan un ancestro común") agregó una ruta de rescate de errores . Sin embargo, este camino no elimina la protección de remontaje adquirida. • https://git.kernel.org/stable/c/a8b0026847b8c43445c921ad2c85521c92eb175f https://git.kernel.org/stable/c/331e125e02c08ffaecc1074af78a988a278039bd https://git.kernel.org/stable/c/9fe6e9e7b58944037714442384075c17cfde1c56 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-35913 – wifi: iwlwifi: mvm: pick the version of SESSION_PROTECTION_NOTIF
https://notcve.org/view.php?id=CVE-2024-35913
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: pick the version of SESSION_PROTECTION_NOTIF When we want to know whether we should look for the mac_id or the link_id in struct iwl_mvm_session_prot_notif, we should look at the version of SESSION_PROTECTION_NOTIF. This causes WARNINGs: WARNING: CPU: 0 PID: 11403 at drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:959 iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] RIP: 0010:iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] Code: 00 49 c7 84 24 48 07 00 00 00 00 00 00 41 c6 84 24 78 07 00 00 ff 4c 89 f7 e8 e9 71 54 d9 e9 7d fd ff ff 0f 0b e9 23 fe ff ff <0f> 0b e9 1c fe ff ff 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffb4bb00003d40 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff9ae63a361000 RCX: ffff9ae4a98b60d4 RDX: ffff9ae4588499c0 RSI: 0000000000000305 RDI: ffff9ae4a98b6358 RBP: ffffb4bb00003d68 R08: 0000000000000003 R09: 0000000000000010 R10: ffffb4bb00003d00 R11: 000000000000000f R12: ffff9ae441399050 R13: ffff9ae4761329e8 R14: 0000000000000001 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9ae7af400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055fb75680018 CR3: 00000003dae32006 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <IRQ> ? show_regs+0x69/0x80 ? __warn+0x8d/0x150 ? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm] ? report_bug+0x196/0x1c0 ? • https://git.kernel.org/stable/c/085d33c53012866b6c088b69b603af7cf69c0a53 https://git.kernel.org/stable/c/222abd95f503e28c0404e596291fe472fe90929c https://git.kernel.org/stable/c/bbe806c294c9c4cd1221140d96e5f367673e393a •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35912 – wifi: iwlwifi: mvm: rfi: fix potential response leaks
https://notcve.org/view.php?id=CVE-2024-35912
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: rfi: fix potential response leaks If the rx payload length check fails, or if kmemdup() fails, we still need to free the command response. Fix that. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: iwlwifi: mvm: rfi: corrige posibles fugas de respuesta Si falla la verificación de la longitud de la payload de rx, o si falla kmemdup(), aún necesitamos liberar la respuesta del comando. Arregla eso. • https://git.kernel.org/stable/c/21254908cbe995a3982a23da32c30d1b43467043 https://git.kernel.org/stable/c/28db0ae86cb91a4ab0e855cff779daead936b7d5 https://git.kernel.org/stable/c/99a75d75007421d8e08ba139e24f77395cd08f62 https://git.kernel.org/stable/c/c0a40f2f8eba07416f695ffe2011bf3f8b0b6dc8 https://git.kernel.org/stable/c/f7f0e784894dfcb265f0f9fa499103b0ca7eabde https://git.kernel.org/stable/c/06a093807eb7b5c5b29b6cff49f8174a4e702341 https://access.redhat.com/security/cve/CVE-2024-35912 https://bugzilla.redhat.com/show_bug.cgi?id=2281636 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35911 – ice: fix memory corruption bug with suspend and rebuild
https://notcve.org/view.php?id=CVE-2024-35911
In the Linux kernel, the following vulnerability has been resolved: ice: fix memory corruption bug with suspend and rebuild The ice driver would previously panic after suspend. This is caused from the driver *only* calling the ice_vsi_free_q_vectors() function by itself, when it is suspending. Since commit b3e7b3a6ee92 ("ice: prevent NULL pointer deref during reload") the driver has zeroed out num_q_vectors, and only restored it in ice_vsi_cfg_def(). This further causes the ice_rebuild() function to allocate a zero length buffer, after which num_q_vectors is updated, and then the new value of num_q_vectors is used to index into the zero length buffer, which corrupts memory. The fix entails making sure all the code referencing num_q_vectors only does so after it has been reset via ice_vsi_cfg_def(). I didn't perform a full bisect, but I was able to test against 6.1.77 kernel and that ice driver works fine for suspend/resume with no panic, so sometime since then, this problem was introduced. Also clean up an un-needed init of a local variable in the function being modified. PANIC from 6.8.0-rc1: [1026674.915596] PM: suspend exit [1026675.664697] ice 0000:17:00.1: PTP reset successful [1026675.664707] ice 0000:17:00.1: 2755 msecs passed between update to cached PHC time [1026675.667660] ice 0000:b1:00.0: PTP reset successful [1026675.675944] ice 0000:b1:00.0: 2832 msecs passed between update to cached PHC time [1026677.137733] ixgbe 0000:31:00.0 ens787: NIC Link is Up 1 Gbps, Flow Control: None [1026677.190201] BUG: kernel NULL pointer dereference, address: 0000000000000010 [1026677.192753] ice 0000:17:00.0: PTP reset successful [1026677.192764] ice 0000:17:00.0: 4548 msecs passed between update to cached PHC time [1026677.197928] #PF: supervisor read access in kernel mode [1026677.197933] #PF: error_code(0x0000) - not-present page [1026677.197937] PGD 1557a7067 P4D 0 [1026677.212133] ice 0000:b1:00.1: PTP reset successful [1026677.212143] ice 0000:b1:00.1: 4344 msecs passed between update to cached PHC time [1026677.212575] [1026677.243142] Oops: 0000 [#1] PREEMPT SMP NOPTI [1026677.247918] CPU: 23 PID: 42790 Comm: kworker/23:0 Kdump: loaded Tainted: G W 6.8.0-rc1+ #1 [1026677.257989] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022 [1026677.269367] Workqueue: ice ice_service_task [ice] [1026677.274592] RIP: 0010:ice_vsi_rebuild_set_coalesce+0x130/0x1e0 [ice] [1026677.281421] Code: 0f 84 3a ff ff ff 41 0f b7 74 ec 02 66 89 b0 22 02 00 00 81 e6 ff 1f 00 00 e8 ec fd ff ff e9 35 ff ff ff 48 8b 43 30 49 63 ed <41> 0f b7 34 24 41 83 c5 01 48 8b 3c e8 66 89 b7 aa 02 00 00 81 e6 [1026677.300877] RSP: 0018:ff3be62a6399bcc0 EFLAGS: 00010202 [1026677.306556] RAX: ff28691e28980828 RBX: ff28691e41099828 RCX: 0000000000188000 [1026677.314148] RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff28691e41099828 [1026677.321730] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [1026677.329311] R10: 0000000000000007 R11: ffffffffffffffc0 R12: 0000000000000010 [1026677.336896] R13: 0000000000000000 R14: 0000000000000000 R15: ff28691e0eaa81a0 [1026677.344472] FS: 0000000000000000(0000) GS:ff28693cbffc0000(0000) knlGS:0000000000000000 [1026677.353000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [1026677.359195] CR2: 0000000000000010 CR3: 0000000128df4001 CR4: 0000000000771ef0 [1026677.366779] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [1026677.374369] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [1026677.381952] PKRU: 55555554 [1026677.385116] Call Trace: [1026677.388023] <TASK> [1026677.390589] ? __die+0x20/0x70 [1026677.394105] ? page_fault_oops+0x82/0x160 [1026677.398576] ? • https://git.kernel.org/stable/c/b3e7b3a6ee92ab927f750a6b19615ce88ece808f https://git.kernel.org/stable/c/ca03b327224ed6be2d07f42ee6ee1cdd586cfd5b https://git.kernel.org/stable/c/e40a02f06ceb0e0b0183e0b973ac5dbf8f75edec https://git.kernel.org/stable/c/11ff8392943e08a35cb0aa19d638b02db745f170 https://git.kernel.org/stable/c/1cb7fdb1dfde1aab66780b4ba44dba6402172111 https://access.redhat.com/security/cve/CVE-2024-35911 https://bugzilla.redhat.com/show_bug.cgi?id=2281639 •
CVSS: 5.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35910 – tcp: properly terminate timers for kernel sockets
https://notcve.org/view.php?id=CVE-2024-35910
In the Linux kernel, the following vulnerability has been resolved: tcp: properly terminate timers for kernel sockets We had various syzbot reports about tcp timers firing after the corresponding netns has been dismantled. Fortunately Josef Bacik could trigger the issue more often, and could test a patch I wrote two years ago. When TCP sockets are closed, we call inet_csk_clear_xmit_timers() to 'stop' the timers. inet_csk_clear_xmit_timers() can be called from any context, including when socket lock is held. This is the reason it uses sk_stop_timer(), aka del_timer(). This means that ongoing timers might finish much later. For user sockets, this is fine because each running timer holds a reference on the socket, and the user socket holds a reference on the netns. For kernel sockets, we risk that the netns is freed before timer can complete, because kernel sockets do not hold reference on the netns. This patch adds inet_csk_clear_xmit_timers_sync() function that using sk_stop_timer_sync() to make sure all timers are terminated before the kernel socket is released. Modules using kernel sockets close them in their netns exit() handler. Also add sock_not_owned_by_me() helper to get LOCKDEP support : inet_csk_clear_xmit_timers_sync() must not be called while socket lock is held. It is very possible we can revert in the future commit 3a58f13a881e ("net: rds: acquire refcount on TCP sockets") which attempted to solve the issue in rds only. (net/smc/af_smc.c and net/mptcp/subflow.c have similar code) We probably can remove the check_net() tests from tcp_out_of_resources() and __tcp_close() in the future. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: termina correctamente los temporizadores para los sockets del kernel. Recibimos varios informes de syzbot sobre los temporizadores tcp que se activan después de que se han desmantelado las redes correspondientes. Afortunadamente, Josef Bacik pudo provocar el problema con más frecuencia y pudo probar un parche que escribí hace dos años. Cuando los sockets TCP están cerrados, llamamos a inet_csk_clear_xmit_timers() para "detener" los temporizadores. • https://git.kernel.org/stable/c/8a68173691f036613e3d4e6bf8dc129d4a7bf383 https://git.kernel.org/stable/c/93f0133b9d589cc6e865f254ad9be3e9d8133f50 https://git.kernel.org/stable/c/44e62f5d35678686734afd47c6a421ad30772e7f https://git.kernel.org/stable/c/e3e27d2b446deb1f643758a0c4731f5c22492810 https://git.kernel.org/stable/c/2e43d8eba6edd1cf05a3a20fdd77688fa7ec16a4 https://git.kernel.org/stable/c/91b243de910a9ac8476d40238ab3dbfeedd5b7de https://git.kernel.org/stable/c/c1ae4d1e76eacddaacb958b67cd942082f800c87 https://git.kernel.org/stable/c/899265c1389fe022802aae73dbf13ee08 •