CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36908 – blk-iocost: do not WARN if iocg was already offlined
https://notcve.org/view.php?id=CVE-2024-36908
In the Linux kernel, the following vulnerability has been resolved: blk-iocost: do not WARN if iocg was already offlined In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which is intended to confirm iocg is active when it has debt. However, warn can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn() is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0 The warn in this situation is meaningless. Since this iocg is being removed, the state of the 'active_list' is irrelevant, and 'waitq_timer' is canceled after removing 'active_list' in ioc_pd_free(), which ensures iocg is freed after iocg_waitq_timer_fn() returns. Therefore, add the check if iocg was already offlined to avoid warn when removing a blkcg or disk. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-iocost: no ADVERTIR si iocg ya estaba desconectado. En iocg_pay_debt(), se activa una advertencia si 'active_list' está vacía, lo que pretende confirmar que iocg está activo cuando deuda. • https://git.kernel.org/stable/c/1c172ac7afe4442964f4153b2c78fe4e005d9d67 https://git.kernel.org/stable/c/14b3275f93d4a0d8ddc02195bc4e9869b7a3700e https://git.kernel.org/stable/c/01bc4fda9ea0a6b52f12326486f07a4910666cf6 •
CVSS: 9.8EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36905 – tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
https://notcve.org/view.php?id=CVE-2024-36905
In the Linux kernel, the following vulnerability has been resolved: tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets TCP_SYN_RECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers. In the following crash [1], syzbot managed to trigger a divide by zero in tcp_rcv_space_adjust() A socket makes the following state transitions, without ever calling tcp_init_transfer(), meaning tcp_init_buffer_space() is also not called. TCP_CLOSE connect() TCP_SYN_SENT TCP_SYN_RECV shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1 To fix this issue, change tcp_shutdown() to not perform a TCP_SYN_RECV -> TCP_FIN_WAIT1 transition, which makes no sense anyway. When tcp_rcv_state_process() later changes socket state from TCP_SYN_RECV to TCP_ESTABLISH, then look at sk->sk_shutdown to finally enter TCP_FIN_WAIT1 state, and send a FIN packet from a sane socket state. This means tcp_send_fin() can now be called from BH context, and must use GFP_ATOMIC allocations. [1] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: <TASK> tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2803 ___sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x474/0xae0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 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 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: diferir apagado (SEND_SHUTDOWN) para sockets TCP_SYN_RECV El estado TCP_SYN_RECV es realmente especial, solo lo usan conexiones cross-syn, principalmente usado por fuzzers. En el siguiente fallo [1], syzbot logró activar una división por cero en tcp_rcv_space_adjust(). Un socket realiza las siguientes transiciones de estado, sin siquiera llamar a tcp_init_transfer(), lo que significa que tampoco se llama a tcp_init_buffer_space(). TCP_CLOSE connect() TCP_SYN_SENT TCP_SYN_RECV Shutdown() -> tcp_shutdown(sk, SEND_SHUTDOWN) TCP_FIN_WAIT1 Para solucionar este problema, cambie tcp_shutdown() para no realizar una transición TCP_SYN_RECV -> TCP_FIN_WAIT1, lo que de todos modos no tiene sentido. Cuando tcp_rcv_state_process() luego cambie el estado del socket de TCP_SYN_RECV a TCP_ESTABLISH, mire sk->sk_shutdown para finalmente ingresar al estado TCP_FIN_WAIT1 y envíe un paquete FIN desde un estado de socket sano. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/34e41a031fd7523bf1cd00a2adca2370aebea270 https://git.kernel.org/stable/c/ed5e279b69e007ce6c0fe82a5a534c1b19783214 https://git.kernel.org/stable/c/413c33b9f3bc36fdf719690a78824db9f88a9485 https://git.kernel.org/stable/c/2552c9d9440f8e7a2ed0660911ff00f25b90a0a4 https://git.kernel.org/stable/c/3fe4ef0568a48369b1891395d13ac593b1ba41b1 https://git.kernel.org/stable/c/f47d0d32fa94e815fdd78b8b88684873e67939f4 https://git.kernel.org/stable/c/cbf232ba11bc86a5281b4f00e1151349e • CWE-369: Divide By Zero •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-36897 – drm/amd/display: Atom Integrated System Info v2_2 for DCN35
https://notcve.org/view.php?id=CVE-2024-36897
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Atom Integrated System Info v2_2 for DCN35 New request from KMD/VBIOS in order to support new UMA carveout model. This fixes a null dereference from accessing Ctx->dc_bios->integrated_info while it was NULL. DAL parses through the BIOS and extracts the necessary integrated_info but was missing a case for the new BIOS version 2.3. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Atom Integrated System Info v2_2 para DCN35 Nueva solicitud de KMD/VBIOS para admitir el nuevo modelo de exclusión UMA. Esto corrige una desreferencia nula al acceder a Ctx->dc_bios->integrated_info mientras era NULL. DAL analiza el BIOS y extrae la información integrada necesaria, pero faltaba un caso para la nueva versión 2.3 del BIOS. • https://git.kernel.org/stable/c/3c7013a87124bab54216d9b99f77e8b6de6fbc1a https://git.kernel.org/stable/c/02f5300f6827206f6e48a77f51e6264993695e5c https://git.kernel.org/stable/c/7e3030774431eb093165a31baff040d35446fb8b https://git.kernel.org/stable/c/c2797ec16d9072327e7578d09ee05bcab52fffd0 https://git.kernel.org/stable/c/9a35d205f466501dcfe5625ca313d944d0ac2d60 • CWE-476: NULL Pointer Dereference •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36885 – drm/nouveau/firmware: Fix SG_DEBUG error with nvkm_firmware_ctor()
https://notcve.org/view.php?id=CVE-2024-36885
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/firmware: Fix SG_DEBUG error with nvkm_firmware_ctor() Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a BUG() on startup: kernel BUG at include/linux/scatterlist.h:187! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30 Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019 RIP: 0010:sg_init_one+0x85/0xa0 Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54 24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b 0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00 RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000 RBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508 R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018 FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0 Call Trace: <TASK> ? die+0x36/0x90 ? do_trap+0xdd/0x100 ? sg_init_one+0x85/0xa0 ? • https://git.kernel.org/stable/c/1a88c18da464db0ba8ea25196d0a06490f65322e https://git.kernel.org/stable/c/e05af009302893f39b072811a68fa4a196284c75 https://git.kernel.org/stable/c/52a6947bf576b97ff8e14bb0a31c5eaf2d0d96e2 https://access.redhat.com/security/cve/CVE-2024-36885 https://bugzilla.redhat.com/show_bug.cgi?id=2284265 • CWE-489: Active Debug Code •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36026 – drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11
https://notcve.org/view.php?id=CVE-2024-36026
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11 While doing multiple S4 stress tests, GC/RLC/PMFW get into an invalid state resulting into hard hangs. Adding a GFX reset as workaround just before sending the MP1_UNLOAD message avoids this failure. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/pm: corrige un bloqueo aleatorio en S4 para SMU v13.0.4/11 Al realizar múltiples pruebas de estrés de S4, GC/RLC/PMFW entra en un estado no válido, lo que resulta en cuelga duro. Agregar un reinicio de GFX como workaround justo antes de enviar el mensaje MP1_UNLOAD evita este error. • https://git.kernel.org/stable/c/bd9b94055c3deb2398ee4490c1dfdf03f53efb8f https://git.kernel.org/stable/c/1e3b8874d55c0c28378beb9007494a7a9269a5f5 https://git.kernel.org/stable/c/7521329e54931ede9e042bbf5f4f812b5bc4a01d https://git.kernel.org/stable/c/31729e8c21ecfd671458e02b6511eb68c2225113 •