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') •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36889 – mptcp: ensure snd_nxt is properly initialized on connect
https://notcve.org/view.php?id=CVE-2024-36889
In the Linux kernel, the following vulnerability has been resolved: mptcp: ensure snd_nxt is properly initialized on connect Christoph reported a splat hinting at a corrupted snd_una: WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767 process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 process_scheduled_works kernel/workqueue.c:3335 [inline] worker_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> When fallback to TCP happens early on a client socket, snd_nxt is not yet initialized and any incoming ack will copy such value into snd_una. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snd_una values. We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice. Instead address the issue always initializing snd_nxt (and write_seq, for consistency) at connect time. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mptcp: asegúrese de que snd_nxt se inicialice correctamente al conectar Christoph informó un símbolo que indica un snd_una dañado: ADVERTENCIA: CPU: 1 PID: 38 en net/mptcp/protocol.c:1005 __mptcp_clean_una +0x4b3/0x620 net/mptcp/protocol.c:1005 Módulos vinculados en: CPU: 1 PID: 38 Comm: kworker/1:1 No contaminado 6.9.0-rc1-gbbeac67456c9 #59 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 01/04/2014 Cola de trabajo: eventos mptcp_worker RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005 Código: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: 3cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 00000000000000000 R11: fefefefefefefeff R12 : ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 00000000000000000(0000) GS:ffff88813bd00000(0000) nlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Rastreo de llamadas: __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [en línea] mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [en línea] __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcp_worker+0x434/ 0x740 neto/ mptcp/protocol.c:2767 Process_one_work+0x1e0/0x560 kernel/workqueue.c:3254 Process_scheduled_works kernel/workqueue.c:3335 [en línea] work_thread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread .c:388 ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 Cuando el retorno a TCP ocurre temprano en un socket de cliente , snd_nxt aún no está inicializado y cualquier confirmación entrante copiará dicho valor en snd_una. Si el trabajador mptcp (tontamente) intenta la reinyección a nivel de mptcp después de tal confirmación, eso desencadenaría incondicionalmente una sanitización del búfer de envío utilizando valores snd_una 'incorrectos'. Podríamos desactivar fácilmente la reinyección para los sockets de respaldo, pero un comportamiento tan tonto ya ayudó a detectar algunos problemas sutiles y un impacto de muy bajo a cero en la práctica. • https://git.kernel.org/stable/c/8fd738049ac3d67a937d36577763b47180aae1ad https://git.kernel.org/stable/c/99951b62bf20cec9247f633a3bea898338b9e5b4 https://git.kernel.org/stable/c/dc941fec0719d0471a5902424d6b2a17df233193 https://git.kernel.org/stable/c/39ca83ed73db9edcc6d70c0dc7a73085a4725012 https://git.kernel.org/stable/c/aa0c07c1f20e05b30019bff083ec43665536f06f https://git.kernel.org/stable/c/592f69b41766d366dbb8ff4ef5a67c4396527bbe https://git.kernel.org/stable/c/fb7a0d334894206ae35f023a82cad5a290fd7386 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-665: Improper Initialization •
CVSS: 9.0EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36886 – tipc: fix UAF in error path
https://notcve.org/view.php?id=CVE-2024-36886
In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in error path Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipc_buf_append() error path: BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034 CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: <IRQ> __dump_stack linux/lib/dump_stack.c:88 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106 print_address_description linux/mm/kasan/report.c:377 print_report+0xc4/0x620 linux/mm/kasan/report.c:488 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026 skb_release_all linux/net/core/skbuff.c:1094 __kfree_skb linux/net/core/skbuff.c:1108 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfree_skb linux/./include/linux/skbuff.h:1244 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254 dst_input linux/./include/net/dst.h:461 ip_rcv_finish linux/net/ipv4/ip_input.c:449 NF_HOOK linux/. • https://git.kernel.org/stable/c/1149557d64c97dc9adf3103347a1c0e8c06d3b89 https://git.kernel.org/stable/c/e19ec8ab0e25bc4803d7cc91c84e84532e2781bd https://git.kernel.org/stable/c/93bc2d6d16f2c3178736ba6b845b30475856dc40 https://git.kernel.org/stable/c/367766ff9e407f8a68409b7ce4dc4d5a72afeab1 https://git.kernel.org/stable/c/66116556076f0b96bc1aa9844008c743c8c67684 https://git.kernel.org/stable/c/21ea04aad8a0839b4ec27ef1691ca480620e8e14 https://git.kernel.org/stable/c/ffd4917c1edb3c3ff334fce3704fbe9c39f35682 https://git.kernel.org/stable/c/a0fbb26f8247e326a320e2cb4395bfb23 • CWE-416: Use After Free •