CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-36939 – nfs: Handle error of rpc_proc_register() in nfs_net_init().
https://notcve.org/view.php?id=CVE-2024-36939
In the Linux kernel, the following vulnerability has been resolved: nfs: Handle error of rpc_proc_register() in nfs_net_init(). syzkaller reported a warning [0] triggered while destroying immature netns. rpc_proc_register() was called in init_nfs_fs(), but its error has been ignored since at least the initial commit 1da177e4c3f4 ("Linux-2.6.12-rc2"). Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs in net namespaces") converted the procfs to per-netns and made the problem more visible. Even when rpc_proc_register() fails, nfs_net_init() could succeed, and thus nfs_net_exit() will be called while destroying the netns. Then, remove_proc_entry() will be called for non-existing proc directory and trigger the warning below. Let's handle the error of rpc_proc_register() properly in nfs_net_init(). [0]: name 'nfs' WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711 Modules linked in: CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711 Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8 FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310 nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438 ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170 setup_net+0x46c/0x660 net/core/net_namespace.c:372 copy_net_ns+0x244/0x590 net/core/net_namespace.c:505 create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228 ksys_unshare+0x342/0x760 kernel/fork.c:3322 __do_sys_unshare kernel/fork.c:3393 [inline] __se_sys_unshare kernel/fork.c:3391 [inline] __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0x7f30d0febe5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600 RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000 </TASK> En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: nfs: Maneja el error de rpc_proc_register() en nfs_net_init(). syzkaller informó que se activó una advertencia [0] al destruir redes inmaduras. Se llamó a rpc_proc_register() en init_nfs_fs(), pero su error se ignoró al menos desde el commit inicial 1da177e4c3f4 ("Linux-2.6.12-rc2"). Recientemente, el commit d47151b79e32 ("nfs: exponen /proc/net/sunrpc/nfs in net namespaces") convirtió los procfs a per-netns e hizo que el problema fuera más visible. Incluso cuando rpc_proc_register() falla, nfs_net_init() podría tener éxito y, por lo tanto, se llamará a nfs_net_exit() mientras se destruyen las redes. Luego, se llamará a remove_proc_entry() para un directorio proc no existente y se activará la siguiente advertencia. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/b33ca18c3a1190208dfd569c4fa8a2f93084709f https://git.kernel.org/stable/c/d4891d817350c67392d4731536945f3809a2a0ba https://git.kernel.org/stable/c/ea6ce93327bd2c8a0c6cf6f2f0e800f3b778f021 https://git.kernel.org/stable/c/8ae63bd858691bee0e2a92571f2fbb36a4d86d65 https://git.kernel.org/stable/c/8a1f89c98dcc542dd6d287e573523714702e0f9c https://git.kernel.org/stable/c/9909dde2e53a19585212c32fe3eda482b5faaaa3 https://git.kernel.org/stable/c/24457f1be29f1e7042e50a7749f5c2dde • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36938 – bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue
https://notcve.org/view.php?id=CVE-2024-36938
In the Linux kernel, the following vulnerability has been resolved: bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which syzbot reported [1]. [1] BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline] __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x312/0x410 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667 __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 value changed: 0xffffffff83d7feb0 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer similarly due to no protection of saved_data_ready. Here is another different caller causing the same issue because of the same reason. So we should protect it with sk_callback_lock read lock because the writer side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);". To avoid errors that could happen in future, I move those two pairs of lock into the sk_psock_data_ready(), which is suggested by John Fastabend. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf, skmsg: Se corrigió la desreferencia del puntero NULL en sk_psock_skb_ingress_enqueue Se corrigieron las ejecucións de datos del puntero NULL en sk_psock_skb_ingress_enqueue() que syzbot informó [1]. [1] ERROR: KCSAN: ejecución de datos en sk_psock_drop / sk_psock_skb_ingress_enqueue escribe en 0xffff88814b3278b8 de 8 bytes por tarea 10724 en la CPU 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [en línea] 0 neto/núcleo/skmsg .c:843 sk_psock_put include/linux/skmsg.h:459 [en línea] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048 __sock_release net/socket. c:659 [en línea] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [en línea] __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 leer en 0xffff8881 4b3278b8 de 8 bytes por tarea 10713 en la CPU 0: sk_psock_data_ready include/linux/skmsg.h:464 [en línea] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net /core/skmsg.c: 1008 [en línea] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [en línea] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 +0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x 312/ 0x410 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [en línea] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667 __do_sys_sendmsg net/socket.c:2676 [en línea] __se_sys_sendmsg net/socket. c:2674 [en línea] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 Entry_SYSCALL_64_after_hwframe+0x6d/0x75 valor cambiado: 0xffffffff83d7feb0 -> 0x0000000000000000 editado por Kernel Concurrency Sanitizer en: CPU: 0 PID: 10713 Comm: syz-executor .4 Contaminado: GW 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 29/02/2024 Antes de esto, confirme 4cd12c6065df ("bpf, sockmap: corrija el puntero NULL dereference in sk_psock_verdict_data_ready()") arregló un puntero NULL de manera similar debido a que no hay protección de save_data_ready. Aquí hay otra persona que llama y causa el mismo problema por el mismo motivo. • https://git.kernel.org/stable/c/604326b41a6fb9b4a78b6179335decee0365cd8c https://git.kernel.org/stable/c/c0809c128dad4c3413818384eb06a341633db973 https://git.kernel.org/stable/c/5965bc7535fb87510b724e5465ccc1a1cf00916d https://git.kernel.org/stable/c/39dc9e1442385d6e9be0b6491ee488dddd55ae27 https://git.kernel.org/stable/c/b397a0ab8582c533ec0c6b732392f141fc364f87 https://git.kernel.org/stable/c/772d5729b5ff0df0d37b32db600ce635b2172f80 https://git.kernel.org/stable/c/6648e613226e18897231ab5e42ffc29e63fa3365 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-36937 – xdp: use flags field to disambiguate broadcast redirect
https://notcve.org/view.php?id=CVE-2024-36937
In the Linux kernel, the following vulnerability has been resolved: xdp: use flags field to disambiguate broadcast redirect When redirecting a packet using XDP, the bpf_redirect_map() helper will set up the redirect destination information in struct bpf_redirect_info (using the __bpf_xdp_redirect_map() helper function), and the xdp_do_redirect() function will read this information after the XDP program returns and pass the frame on to the right redirect destination. When using the BPF_F_BROADCAST flag to do multicast redirect to a whole map, __bpf_xdp_redirect_map() sets the 'map' pointer in struct bpf_redirect_info to point to the destination map to be broadcast. And xdp_do_redirect() reacts to the value of this map pointer to decide whether it's dealing with a broadcast or a single-value redirect. However, if the destination map is being destroyed before xdp_do_redirect() is called, the map pointer will be cleared out (by bpf_clear_redirect_map()) without waiting for any XDP programs to stop running. This causes xdp_do_redirect() to think that the redirect was to a single target, but the target pointer is also NULL (since broadcast redirects don't have a single target), so this causes a crash when a NULL pointer is passed to dev_map_enqueue(). To fix this, change xdp_do_redirect() to react directly to the presence of the BPF_F_BROADCAST flag in the 'flags' value in struct bpf_redirect_info to disambiguate between a single-target and a broadcast redirect. And only read the 'map' pointer if the broadcast flag is set, aborting if that has been cleared out in the meantime. • https://git.kernel.org/stable/c/e624d4ed4aa8cc3c69d1359b0aaea539203ed266 https://git.kernel.org/stable/c/12481f30128fbebc2eeb55eb2d56390fdfa30c5e https://git.kernel.org/stable/c/272bfb019f3cc018f654b992115774e77b4f3ffc https://git.kernel.org/stable/c/e22e25820fa04ea5eaac4ef7ee200e9923f466a4 https://git.kernel.org/stable/c/6fd81f9d333e7b3532036577b1beb74ba1323553 https://git.kernel.org/stable/c/5bcf0dcbf9066348058b88a510c57f70f384c92c •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36936 – efi/unaccepted: touch soft lockup during memory accept
https://notcve.org/view.php?id=CVE-2024-36936
In the Linux kernel, the following vulnerability has been resolved: efi/unaccepted: touch soft lockup during memory accept Commit 50e782a86c98 ("efi/unaccepted: Fix soft lockups caused by parallel memory acceptance") has released the spinlock so other CPUs can do memory acceptance in parallel and not triggers softlockup on other CPUs. However the softlock up was intermittent shown up if the memory of the TD guest is large, and the timeout of softlockup is set to 1 second: RIP: 0010:_raw_spin_unlock_irqrestore Call Trace: ? __hrtimer_run_queues <IRQ> ? hrtimer_interrupt ? watchdog_timer_fn ? __sysvec_apic_timer_interrupt ? • https://git.kernel.org/stable/c/50e782a86c980d4f8292ef82ed8139282ca07a98 https://git.kernel.org/stable/c/b583bfcc5a36dbd1db1984dbfcfd23ba64d23604 https://git.kernel.org/stable/c/e115c1b5de55a105c75aba8eb08301c075fa4ef4 https://git.kernel.org/stable/c/781e34b736014188ba9e46a71535237313dcda81 https://git.kernel.org/stable/c/1c5a1627f48105cbab81d25ec2f72232bfaa8185 https://access.redhat.com/security/cve/CVE-2024-36936 https://bugzilla.redhat.com/show_bug.cgi?id=2296278 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36934 – bna: ensure the copied buf is NUL terminated
https://notcve.org/view.php?id=CVE-2024-36934
In the Linux kernel, the following vulnerability has been resolved: bna: ensure the copied buf is NUL terminated Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bna: asegúrese de que el buf copiado tenga terminación NUL. Actualmente, asignamos un búfer del kernel de tamaño nbytes y copiamos nbytes del espacio de usuario a ese búfer. • https://git.kernel.org/stable/c/7afc5dbde09104b023ce04465ba71aaba0fc4346 https://git.kernel.org/stable/c/bd502ba81cd1d515deddad7dbc6b812b14b97147 https://git.kernel.org/stable/c/80578ec10335bc15ac35fd1703c22aab34e39fdd https://git.kernel.org/stable/c/6f0f19b79c085cc891c418b768f26f7004bd51a4 https://git.kernel.org/stable/c/0f560240b4cc25d3de527deb257cdf072c0102a9 https://git.kernel.org/stable/c/06cb37e2ba6441888f24566a997481d4197b4e32 https://git.kernel.org/stable/c/e19478763154674c084defc62ae0d64d79657f91 https://git.kernel.org/stable/c/1518b2b498a0109eb6b15755169d3b660 •