CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26615 – net/smc: fix illegal rmb_desc access in SMC-D connection dump
https://notcve.org/view.php?id=CVE-2024-26615
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix illegal rmb_desc access in SMC-D connection dump A crash was found when dumping SMC-D connections. It can be reproduced by following steps: - run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL> - continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D' BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? • https://git.kernel.org/stable/c/4b1b7d3b30a6d32ac1a1dcede284e76ef8a8542d https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22 https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9 https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3e • CWE-476: NULL Pointer Dereference •
CVSS: 3.3EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26614 – tcp: make sure init the accept_queue's spinlocks once
https://notcve.org/view.php?id=CVE-2024-26614
In the Linux kernel, the following vulnerability has been resolved: tcp: make sure init the accept_queue's spinlocks once When I run syz's reproduction C program locally, it causes the following issue: pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0! WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000 R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Call Trace: <IRQ> _raw_spin_unlock (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321) inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358) tcp_check_req (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234) __netif_receive_skb_one_core (net/core/dev.c:5529) process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533) net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:381) __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469) tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release_sock (. • https://git.kernel.org/stable/c/168a8f58059a22feb9e9a2dcc1b8053dbbbc12ef https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882 https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3 https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855 https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02 https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-413: Improper Resource Locking •
CVSS: 6.1EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26610 – wifi: iwlwifi: fix a memory corruption
https://notcve.org/view.php?id=CVE-2024-26610
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix a memory corruption iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in bytes, we'll write past the buffer. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: corrige una corrupción de memoria iwl_fw_ini_trigger_tlv::data es un puntero a un __le32, lo que significa que si copiamos a iwl_fw_ini_trigger_tlv::data + offset mientras el offset está en bytes, escribiremos más allá del búfer. A memory corruption flaw was found in the Linux kernel Intel Wireless WiFi Next Gen AGN module. This issue could allow a local user to crash the system. • https://git.kernel.org/stable/c/cf29c5b66b9f83939367d90679eb68cdfa2f0356 https://git.kernel.org/stable/c/05dd9facfb9a1e056752c0901c6e86416037d15a https://git.kernel.org/stable/c/99a23462fe1a6f709f0fda3ebbe8b6b193ac75bd https://git.kernel.org/stable/c/aa2cc9363926991ba74411e3aa0a0ea82c1ffe32 https://git.kernel.org/stable/c/870171899d75d43e3d14360f3a4850e90a9c289b https://git.kernel.org/stable/c/f32a81999d0b8e5ce60afb5f6a3dd7241c17dd67 https://git.kernel.org/stable/c/cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-680: Integer Overflow to Buffer Overflow •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52498 – PM: sleep: Fix possible deadlocks in core system-wide PM code
https://notcve.org/view.php?id=CVE-2023-52498
In the Linux kernel, the following vulnerability has been resolved: PM: sleep: Fix possible deadlocks in core system-wide PM code It is reported that in low-memory situations the system-wide resume core code deadlocks, because async_schedule_dev() executes its argument function synchronously if it cannot allocate memory (and not only in that case) and that function attempts to acquire a mutex that is already held. Executing the argument function synchronously from within dpm_async_fn() may also be problematic for ordering reasons (it may cause a consumer device's resume callback to be invoked before a requisite supplier device's one, for example). Address this by changing the code in question to use async_schedule_dev_nocall() for scheduling the asynchronous execution of device suspend and resume functions and to directly run them synchronously if async_schedule_dev_nocall() returns false. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: suspensión: soluciona posibles bloqueos en el código PM de todo el sistema central. Se informa que en situaciones de poca memoria, el código central de reanudación de todo el sistema se bloquea porque async_schedule_dev() ejecuta su el argumento funciona sincrónicamente si no puede asignar memoria (y no solo en ese caso) y esa función intenta adquirir un mutex que ya está retenido. La ejecución de la función de argumento sincrónicamente desde dpm_async_fn() también puede ser problemática por razones de pedido (puede causar que la devolución de llamada de currículum de un dispositivo consumidor se invoque antes que la de un dispositivo proveedor requerido, por ejemplo). • https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0 https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34 https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7 https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52497 – erofs: fix lz4 inplace decompression
https://notcve.org/view.php?id=CVE-2023-52497
In the Linux kernel, the following vulnerability has been resolved: erofs: fix lz4 inplace decompression Currently EROFS can map another compressed buffer for inplace decompression, that was used to handle the cases that some pages of compressed data are actually not in-place I/O. However, like most simple LZ77 algorithms, LZ4 expects the compressed data is arranged at the end of the decompressed buffer and it explicitly uses memmove() to handle overlapping: __________________________________________________________ |_ direction of decompression --> ____ |_ compressed data _| Although EROFS arranges compressed data like this, it typically maps two individual virtual buffers so the relative order is uncertain. Previously, it was hardly observed since LZ4 only uses memmove() for short overlapped literals and x86/arm64 memmove implementations seem to completely cover it up and they don't have this issue. Juhyung reported that EROFS data corruption can be found on a new Intel x86 processor. After some analysis, it seems that recent x86 processors with the new FSRM feature expose this issue with "rep movsb". Let's strictly use the decompressed buffer for lz4 inplace decompression for now. Later, as an useful improvement, we could try to tie up these two buffers together in the correct order. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: corrige la descompresión in situ de lz4 Actualmente, EROFS puede asignar otro búfer comprimido para la descompresión in situ, que se utilizó para manejar los casos en que algunas páginas de datos comprimidos en realidad no están in situ I/ o. Sin embargo, como la mayoría de los algoritmos LZ77 simples, LZ4 espera que los datos comprimidos estén organizados al final del buffer descomprimido y usa explícitamente memmove() para manejar la superposición: ________________________________________________________ |_ dirección de descompresión --> ____ |_ datos comprimidos _| Aunque EROFS organiza los datos comprimidos de esta manera, normalmente asigna dos buffers virtuales individuales, por lo que el orden relativo es incierto. • https://git.kernel.org/stable/c/0ffd71bcc3a03ebb3551661a36052488369c4de9 https://git.kernel.org/stable/c/a0180e940cf1aefa7d516e20b259ad34f7a8b379 https://git.kernel.org/stable/c/77cbc04a1a8610e303a0e0d74f2676667876a184 https://git.kernel.org/stable/c/33bf23c9940dbd3a22aad7f0cda4c84ed5701847 https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de https://lists.debian.org/debian-lts-announce/2024/06/ •