CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52699 – sysv: don't call sb_bread() with pointers_lock held
https://notcve.org/view.php?id=CVE-2023-52699
In the Linux kernel, the following vulnerability has been resolved: sysv: don't call sb_bread() with pointers_lock held syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held. A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12. Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit). Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sysv: no llame a sb_bread() con pointers_lock retenido syzbot informa suspensión en contexto atómico en el sistema de archivos SysV [1], porque sb_bread() se llama con rw_spinlock retenido. Un error "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" y un error "sb_bread() with write_lock(&pointers_lock)" fueron introducidos por "Reemplazar BKL para bloqueo de cadena con sysvfs-private rwlock" en Linux 2.5.12. Luego, "[PATCH] err1-40: corrección de bloqueo de sysvfs" en Linux 2.6.8 solucionó el error anterior moviendo el bloqueo pointers_lock a las personas que llaman, pero en su lugar introdujo un error "sb_bread() con read_lock(&pointers_lock)" (que hizo que esto problema más fácil de abordar). • https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76 https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1 https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927 https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09 https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3 https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441ab •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35917 – s390/bpf: Fix bpf_plt pointer arithmetic
https://notcve.org/view.php?id=CVE-2024-35917
In the Linux kernel, the following vulnerability has been resolved: s390/bpf: Fix bpf_plt pointer arithmetic Kui-Feng Lee reported a crash on s390x triggered by the dummy_st_ops/dummy_init_ptr_arg test [1]: [<0000000000000002>] 0x2 [<00000000009d5cde>] bpf_struct_ops_test_run+0x156/0x250 [<000000000033145a>] __sys_bpf+0xa1a/0xd00 [<00000000003319dc>] __s390x_sys_bpf+0x44/0x50 [<0000000000c4382c>] __do_syscall+0x244/0x300 [<0000000000c59a40>] system_call+0x70/0x98 This is caused by GCC moving memcpy() after assignments in bpf_jit_plt(), resulting in NULL pointers being written instead of the return and the target addresses. Looking at the GCC internals, the reordering is allowed because the alias analysis thinks that the memcpy() destination and the assignments' left-hand-sides are based on different objects: new_plt and bpf_plt_ret/bpf_plt_target respectively, and therefore they cannot alias. This is in turn due to a violation of the C standard: When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object ... From the C's perspective, bpf_plt_ret and bpf_plt are distinct objects and cannot be subtracted. In the practical terms, doing so confuses the GCC's alias analysis. The code was written this way in order to let the C side know a few offsets defined in the assembly. While nice, this is by no means necessary. Fix the noncompliance by hardcoding these offsets. [1] https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8-1364e929d34c@gmail.com/ En el kernel de Linux, se resolvió la siguiente vulnerabilidad: s390/bpf: Corrección de la aritmética del puntero bpf_plt Kui-Feng Lee informó un bloqueo en s390x provocado por la prueba dummy_st_ops/dummy_init_ptr_arg [1]: [<00000000000000002>] 0x2 [<00000000009d5cde> ] bpf_struct_ops_test_run+0x156/0x250 [<000000000033145a>] __sys_bpf+0xa1a/0xd00 [<00000000003319dc>] __s390x_sys_bpf+0x44/0x50 [<0000000000 c4382c>] __do_syscall+0x244/0x300 [<0000000000c59a40>] system_call+0x70/0x98 Esto es causado por GCC mueve memcpy() después de las asignaciones en bpf_jit_plt(), lo que da como resultado que se escriban punteros NULL en lugar de las direcciones de retorno y de destino. Al observar los aspectos internos de GCC, se permite el reordenamiento porque el análisis de alias piensa que el destino memcpy() y los lados izquierdos de las asignaciones se basan en objetos diferentes: new_plt y bpf_plt_ret/bpf_plt_target respectivamente y, por lo tanto, no pueden crear alias. • https://git.kernel.org/stable/c/f1d5df84cd8c3ec6460c78f5b86be7c84577a83f https://git.kernel.org/stable/c/c3062bdb859b6e2567e7f5c8cde20c0250bb130f https://git.kernel.org/stable/c/d3d74e45a060d218fe4b0c9174f0a77517509d8e https://git.kernel.org/stable/c/7ded842b356d151ece8ac4985940438e6d3998bb •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35916 – dma-buf: Fix NULL pointer dereference in sanitycheck()
https://notcve.org/view.php?id=CVE-2024-35916
In the Linux kernel, the following vulnerability has been resolved: dma-buf: Fix NULL pointer dereference in sanitycheck() If due to a memory allocation failure mock_chain() returns NULL, it is passed to dma_fence_enable_sw_signaling() resulting in NULL pointer dereference there. Call dma_fence_enable_sw_signaling() only if mock_chain() succeeds. Found by Linux Verification Center (linuxtesting.org) with SVACE. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dma-buf: corrige la desreferencia del puntero NULL en sanitycheck(). Si debido a un error en la asignación de memoria, mock_chain() devuelve NULL, se pasa a dma_fence_enable_sw_signaling(), lo que genera una desreferencia del puntero NULL allí. . Llame a dma_fence_enable_sw_signaling() solo si mock_chain() tiene éxito. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. • https://git.kernel.org/stable/c/d62c43a953ce02d54521ec06217d0c2ed6d489af https://git.kernel.org/stable/c/0336995512cdab0c65e99e4cdd47c4606debe14e https://git.kernel.org/stable/c/156c226cbbdcf5f3bce7b2408a33b59fab7fae2c https://git.kernel.org/stable/c/eabf131cba1db12005a68378305f13b9090a7a6b https://git.kernel.org/stable/c/2295bd846765c766701e666ed2e4b35396be25e6 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35915 – nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
https://notcve.org/view.php?id=CVE-2024-35915
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet syzbot reported the following uninit-value access issue [1][2]: nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded. This patch resolved this issue by checking payload size before calling each message type handler codes. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfc: nci: corrigió el valor uninit en nci_dev_up y nci_ntf_packet syzbot informó el siguiente problema de acceso al valor uninit [1][2]: nci_rx_work() analiza y procesa el paquete recibido. Cuando la longitud del payload es cero, cada controlador de tipo de mensaje lee el payload no inicializado y KMSAN detecta este problema. • https://git.kernel.org/stable/c/6a2968aaf50c7a22fced77a5e24aa636281efca8 https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240 https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16 https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7 https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f600 •
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 •