![](/assets/img/cve_300x82_sin_bg.png)
CVE-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') •
![](/assets/img/cve_300x82_sin_bg.png)
CVE-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 •
![](/assets/img/cve_300x82_sin_bg.png)
CVE-2024-36924 – scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()
https://notcve.org/view.php?id=CVE-2024-36924
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up() lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the hbalock to avoid potential deadlock. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: Libere hbalock antes de llamar a lpfc_worker_wake_up() lpfc_worker_wake_up() llama a la rutina lpfc_work_done(), que toma el hbalock. Por lo tanto, no se debe llamar a lpfc_worker_wake_up() mientras se mantiene presionado el hbalock para evitar un posible punto muerto. • https://git.kernel.org/stable/c/6503c39398506cadda9f4c81695a9655ca5fb4fd https://git.kernel.org/stable/c/e8bf2c05e8ad68e90f9d5889a9e4ef3f6fe00683 https://git.kernel.org/stable/c/ee833d7e62de2b84ed1332d501b67f12e7e5678f https://git.kernel.org/stable/c/ded20192dff31c91cef2a04f7e20e60e9bb887d3 https://access.redhat.com/security/cve/CVE-2024-36924 https://bugzilla.redhat.com/show_bug.cgi?id=2284506 • CWE-833: Deadlock •
![](/assets/img/cve_300x82_sin_bg.png)
CVE-2024-36923 – fs/9p: fix uninitialized values during inode evict
https://notcve.org/view.php?id=CVE-2024-36923
In the Linux kernel, the following vulnerability has been resolved: fs/9p: fix uninitialized values during inode evict If an iget fails due to not being able to retrieve information from the server then the inode structure is only partially initialized. When the inode gets evicted, references to uninitialized structures (like fscache cookies) were being made. This patch checks for a bad_inode before doing anything other than clearing the inode from the cache. Since the inode is bad, it shouldn't have any state associated with it that needs to be written back (and there really isn't a way to complete those anyways). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/9p: corrige valores no inicializados durante el desalojo de inodo. Si un iget falla debido a que no puede recuperar información del servidor, entonces la estructura del inodo solo se inicializa parcialmente. • https://git.kernel.org/stable/c/1b4cb6e91f19b81217ad98142ee53a1ab25893fd https://git.kernel.org/stable/c/6630036b7c228f57c7893ee0403e92c2db2cd21d •
![](/assets/img/cve_300x82_sin_bg.png)
CVE-2024-36922 – wifi: iwlwifi: read txq->read_ptr under lock
https://notcve.org/view.php?id=CVE-2024-36922
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: read txq->read_ptr under lock If we read txq->read_ptr without lock, we can read the same value twice, then obtain the lock, and reclaim from there to two different places, but crucially reclaim the same entry twice, resulting in the WARN_ONCE() a little later. Fix that by reading txq->read_ptr under lock. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: leer txq->read_ptr bajo bloqueo Si leemos txq->read_ptr sin bloqueo, podemos leer el mismo valor dos veces, luego obtener el bloqueo y reclamar desde allí a dos lugares diferentes, pero fundamentalmente reclama la misma entrada dos veces, lo que resulta en WARN_ONCE() un poco más tarde. Solucione eso leyendo txq->read_ptr bajo bloqueo. • https://git.kernel.org/stable/c/b83db8e756dec68a950ed2f056248b1704b3deaa https://git.kernel.org/stable/c/43d07103df670484cdd26f9588eabef80f69db89 https://git.kernel.org/stable/c/c2ace6300600c634553657785dfe5ea0ed688ac2 https://access.redhat.com/security/cve/CVE-2024-36922 https://bugzilla.redhat.com/show_bug.cgi?id=2284511 • CWE-413: Improper Resource Locking •