CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36901 – ipv6: prevent NULL dereference in ip6_output()
https://notcve.org/view.php?id=CVE-2024-36901
In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent NULL dereference in ip6_output() According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 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 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: evita la desreferencia a NULL en ip6_output() Según syzbot, existe la posibilidad de que ip6_dst_idev() devuelva NULL en ip6_output(). La mayoría de los lugares en la pila IPv6 manejan un idev NULL muy bien, pero no aquí. syzbot informó: falla de protección general, probablemente para dirección no canónica 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref en rango [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: ejecutor. 4 No contaminado 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 27/03/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output. c:237 Código: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 00000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: ffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:00000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: NF_HOOK include/linux/netfilter.h:314 [en línea] ip6_xmit+0xefe /0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net /sctp/cola de salida. c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [en línea] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [en línea] 9cc/0x60c0 neto/ sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [en línea] sctp_inet_connect+ 0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [en línea] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [en línea] __se_sys_connect red/socket .c:2072 [en línea] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entrada_SYSCALL_64_after_hwframe+0x77/0x7f • https://git.kernel.org/stable/c/778d80be52699596bf70e0eb0761cf5e1e46088d https://git.kernel.org/stable/c/9df3b2474a627994433a87cbf325a562555b17de https://git.kernel.org/stable/c/2272e2db38f2e85929278146d7c770f22f528579 https://git.kernel.org/stable/c/ea0cb87402f774b0e1214ffba0f57028b27cf155 https://git.kernel.org/stable/c/e31b25cc2066d3f2b6c38579253882008d4469b0 https://git.kernel.org/stable/c/55f7eb4001ef2a3b48cf039cf263f9ed0ec5a488 https://git.kernel.org/stable/c/4db783d68b9b39a411a96096c10828ff5dfada7a https://access.redhat.com/security/cve/CVE-2024-36901 • CWE-476: NULL Pointer Dereference •
CVSS: 6.7EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36899 – gpiolib: cdev: Fix use after free in lineinfo_changed_notify
https://notcve.org/view.php?id=CVE-2024-36899
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Fix use after free in lineinfo_changed_notify The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines. Here is the typical stack when issue happened: [free] gpio_chrdev_release() --> bitmap_free(cdev->watched_lines) <-- freed --> blocking_notifier_chain_unregister() --> down_write(&nh->rwsem) <-- waiting rwsem --> __down_write_common() --> rwsem_down_write_slowpath() --> schedule_preempt_disabled() --> schedule() [use] st54spi_gpio_dev_release() --> gpio_free() --> gpiod_free() --> gpiod_free_commit() --> gpiod_line_state_notify() --> blocking_notifier_call_chain() --> down_read(&nh->rwsem); <-- held rwsem --> notifier_call_chain() --> lineinfo_changed_notify() --> test_bit(xxxx, cdev->watched_lines) <-- use after free The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway. To fix the issue, call the bitmap_free() function after the unregistration of lineinfo_changed_nb notifier chain. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: cdev: corrige el use after free en lineinfo_changed_notify El problema de use after free ocurre de la siguiente manera: cuando el archivo del dispositivo del chip GPIO se cierra al invocar gpio_chrdev_release(), las líneas vigiladas son liberado por bitmap_free(), pero la cancelación del registro de la cadena de notificador lineinfo_changed_nb falló debido a la espera de escritura de rwsem. • https://git.kernel.org/stable/c/51c1064e82e77b39a49889287ca50709303e2f26 https://git.kernel.org/stable/c/95ca7c90eaf5ea8a8460536535101e3e81160e2a https://git.kernel.org/stable/c/ca710b5f40b8b16fdcad50bebd47f50e4c62d239 https://git.kernel.org/stable/c/02f6b0e1ec7e0e7d059dddc893645816552039da https://access.redhat.com/security/cve/CVE-2024-36899 https://bugzilla.redhat.com/show_bug.cgi?id=2284549 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36898 – gpiolib: cdev: fix uninitialised kfifo
https://notcve.org/view.php?id=CVE-2024-36898
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: fix uninitialised kfifo If a line is requested with debounce, and that results in debouncing in software, and the line is subsequently reconfigured to enable edge detection then the allocation of the kfifo to contain edge events is overlooked. This results in events being written to and read from an uninitialised kfifo. Read events are returned to userspace. Initialise the kfifo in the case where the software debounce is already active. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpiolib: cdev: corrige kfifo no inicializado Si se solicita una línea con antirrebote, y eso resulta en un antirrebote en el software, y la línea se reconfigura posteriormente para habilitar la detección de bordes, entonces se realiza la asignación del Se pasa por alto kfifo para contener eventos de borde. Esto da como resultado que los eventos se escriban y lean desde un kfifo no inicializado. • https://git.kernel.org/stable/c/65cff70464068a823b3f4a28074000febdce0630 https://git.kernel.org/stable/c/1a51e24404d77bb3307c1e39eee0d8e86febb1a5 https://git.kernel.org/stable/c/883e4bbf06eb5fb7482679e4edb201093e9f55a2 https://git.kernel.org/stable/c/bd7139a70ee8d8ea872b223e043730cf6f5e2b0e https://git.kernel.org/stable/c/ee0166b637a5e376118e9659e5b4148080f1d27e •
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: 5.6EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36894 – usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete
https://notcve.org/view.php?id=CVE-2024-36894
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete FFS based applications can utilize the aio_cancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following: DWC3 Gadget FFS Application dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue() There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (io_data->req) the FFS application is also referencing it for the usb_ep_dequeue() call. This can lead to accessing a stale/hanging pointer. commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") relocated the usb_ep_free_request() into ffs_epfile_async_io_complete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffs_epfile_async_io_complete(), as usb_ep_dequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock. Fix this issue by moving the usb_ep_free_request() back to ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req to NULL after freeing it within the ffs->eps_lock. • https://git.kernel.org/stable/c/2e4c7553cd6f9c68bb741582dcb614edcbeca70f https://git.kernel.org/stable/c/f71a53148ce34898fef099b75386a3a9f4449311 https://git.kernel.org/stable/c/9e72ef59cbe61cd1243857a6418ca92104275867 https://git.kernel.org/stable/c/e500b1c4e29ad0bd1c1332a1eaea2913627a92dd https://git.kernel.org/stable/c/3613e5023f09b3308545e9d1acda86017ebd418a https://git.kernel.org/stable/c/a0fdccb1c9e027e3195f947f61aa87d6d0d2ea14 https://git.kernel.org/stable/c/73c05ad46bb4fbbdb346004651576d1c8dbcffbb https://git.kernel.org/stable/c/d7461830823242702f5d84084bcccb251 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •