CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26876 – drm/bridge: adv7511: fix crash on irq during probe
https://notcve.org/view.php?id=CVE-2024-26876
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: adv7511: fix crash on irq during probe Moved IRQ registration down to end of adv7511_probe(). If an IRQ already is pending during adv7511_probe (before adv7511_cec_init) then cec_received_msg_ts could crash using uninitialized data: Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5 Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP Call trace: cec_received_msg_ts+0x48/0x990 [cec] adv7511_cec_irq_process+0x1cc/0x308 [adv7511] adv7511_irq_process+0xd8/0x120 [adv7511] adv7511_irq_handler+0x1c/0x30 [adv7511] irq_thread_fn+0x30/0xa0 irq_thread+0x14c/0x238 kthread+0x190/0x1a8 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/bridge: adv7511: corrige el fallo en irq durante la sonda Se movió el registro de IRQ al final de adv7511_probe(). Si ya hay una IRQ pendiente durante adv7511_probe (antes de adv7511_cec_init), entonces cec_received_msg_ts podría fallar usando datos no inicializados: No se puede manejar la lectura del kernel desde memoria ilegible en la dirección virtual 00000000000003d5 Error interno: Ups: 96000004 [#1] PREEMPT_RT SMP Seguimiento de llamadas: _ts+0x48 /0x990 [cec] adv7511_cec_irq_process+0x1cc/0x308 [adv7511] adv7511_irq_process+0xd8/0x120 [adv7511] adv7511_irq_handler+0x1c/0x30 [adv7511] irq_thread_fn+0x30/0xa0 leer+0x14c/0x238 khilo+0x190/0x1a8 • https://git.kernel.org/stable/c/3b1b975003e4a3da4b93ab032487a3ae4afca7b5 https://git.kernel.org/stable/c/50f4b57e9a9db4ede9294f39b9e75b5f26bae9b7 https://git.kernel.org/stable/c/955c1252930677762e0db2b6b9e36938c887445c https://git.kernel.org/stable/c/28a94271bd50e4cf498df0381f776f8ea40a289e https://git.kernel.org/stable/c/aeedaee5ef5468caf59e2bb1265c2116e0c9a924 •
CVSS: 6.4EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26875 – media: pvrusb2: fix uaf in pvr2_context_set_notify
https://notcve.org/view.php?id=CVE-2024-26875
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix uaf in pvr2_context_set_notify [Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26 CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272 Freed by task 906: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inline] slab_free mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158 [Analyze] Task A set disconnect_flag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue. [Fix] Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect() to avoid this issue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: pvrusb2: corrige uaf en pvr2_context_set_notify [Syzbot informó] ERROR: KASAN: slab-use-after-free en pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2 -context.c:35 Lectura del tamaño 4 en la dirección ffff888113aeb0d8 por tarea kworker/1:1/26 CPU: 1 PID: 26 Comm: kworker/1:1 No contaminado 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 25/01/2024 Cola de trabajo: usb_hub_wq hub_event Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c :106 print_address_description mm/kasan/report.c:377 [en línea] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 controladores/ media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify controladores/media/usb/pvrusb2/pvrusb2-context.c:95 [en línea] pvr2_context_disconnect+0x94/0xb0 controladores/media/usb/pvrusb2/pvrusb2-context.c :272 Liberado por la tarea 906: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 veneno_slab_object mm/kasan/common.c:241 [en línea] __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [en línea] slab_free_hook mm/slub.c:2121 [en línea] slab_free mm/slub.c:4299 [en línea] kfree+0x105/0x340 mm/slub.c:4409 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [en línea] pvr2_context_thread_func+0x69d/0x960 controladores/medios /usb/pvrusb2/pvrusb2-context.c:158 [Analizar] La tarea A estableció desconectar_flag = !0, lo que resultó en que se cumpliera la condición de la tarea B y se liberara mp, lo que generó este problema. [Solución] Coloque la operación de asignaciónconnect_flag después de todo el código en pvr2_context_disconnect() para evitar este problema. • https://git.kernel.org/stable/c/e5be15c63804e05b5a94197524023702a259e308 https://git.kernel.org/stable/c/ed8000e1e8e9684ab6c30cf2b526c0cea039929c https://git.kernel.org/stable/c/d29ed08964cec8b9729bc55c7bb23f679d7a18fb https://git.kernel.org/stable/c/ab896d93fd6a2cd1afeb034c3cc9226cb499209f https://git.kernel.org/stable/c/eb6e9dce979c08210ff7249e5e0eceb8991bfcd7 https://git.kernel.org/stable/c/3a1ec89708d2e57e2712f46241282961b1a7a475 https://git.kernel.org/stable/c/8e60b99f6b7ccb3badeb512f5eb613ad45904592 https://git.kernel.org/stable/c/40cd818fae875c424a8335009db33c7b5 • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26874 – drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip
https://notcve.org/view.php?id=CVE-2024-26874
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip It's possible that mtk_crtc->event is NULL in mtk_drm_crtc_finish_page_flip(). pending_needs_vblank value is set by mtk_crtc->event, but in mtk_drm_crtc_atomic_flush(), it's is not guarded by the same lock in mtk_drm_finish_page_flip(), thus a race condition happens. Consider the following case: CPU1 CPU2 step 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event) step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip: lock mtk_crtc->event set to null, pending_needs_vblank set to false unlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointer Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more efficient to just check if mtk_crtc->event is null before use. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/mediatek: corrige un fallo del puntero nulo en mtk_drm_crtc_finish_page_flip Es posible que mtk_crtc->event sea NULL en mtk_drm_crtc_finish_page_flip(). El valor pendiente_needs_vblank lo establece mtk_crtc->event, pero en mtk_drm_crtc_atomic_flush(), no está protegido por el mismo bloqueo en mtk_drm_finish_page_flip(), por lo que ocurre una condición de carrera. Considere el siguiente caso: CPU1 CPU2 paso 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, paso 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !! • https://git.kernel.org/stable/c/119f5173628aa7a0c3cf9db83460d40709e8241d https://git.kernel.org/stable/c/accdac6b71d5a2b84040c3d2234f53a60edc398e https://git.kernel.org/stable/c/dfde84cc6c589f2a9f820f12426d97365670b731 https://git.kernel.org/stable/c/4688be96d20ffa49d2186523ee84f475f316fd49 https://git.kernel.org/stable/c/9beec711a17245b853d64488fd5b739031612340 https://git.kernel.org/stable/c/d2bd30c710475b2e29288827d2c91f9e6e2b91d7 https://git.kernel.org/stable/c/a3dd12b64ae8373a41a216a0b621df224210860a https://git.kernel.org/stable/c/9acee29a38b4d4b70f1f583e5ef9a245d •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26872 – RDMA/srpt: Do not register event handler until srpt device is fully setup
https://notcve.org/view.php?id=CVE-2024-26872
In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Do not register event handler until srpt device is fully setup Upon rare occasions, KASAN reports a use-after-free Write in srpt_refresh_port(). This seems to be because an event handler is registered before the srpt device is fully setup and a race condition upon error may leave a partially setup event handler in place. Instead, only register the event handler after srpt device initialization is complete. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/srpt: no registrar el controlador de eventos hasta que el dispositivo srpt esté completamente configurado. En raras ocasiones, KASAN informa una escritura de use-after-free en srpt_refresh_port(). Esto parece deberse a que se registra un controlador de eventos antes de que el dispositivo srpt esté completamente configurado y una condición de carrera en caso de error puede dejar en su lugar un controlador de eventos parcialmente configurado. En su lugar, registre el controlador de eventos solo después de que se complete la inicialización del dispositivo srpt. • https://git.kernel.org/stable/c/a42d985bd5b234da8b61347a78dc3057bf7bb94d https://git.kernel.org/stable/c/bdd895e0190c464f54f84579e7535d80276f0fc5 https://git.kernel.org/stable/c/6413e78086caf7bf15639923740da0d91fdfd090 https://git.kernel.org/stable/c/e362d007294955a4fb929e1c8978154a64efdcb6 https://git.kernel.org/stable/c/85570b91e4820a0db9d9432098778cafafa7d217 https://git.kernel.org/stable/c/7104a00fa37ae898a827381f1161fa3286c8b346 https://git.kernel.org/stable/c/ec77fa12da41260c6bf9e060b89234b980c5130f https://git.kernel.org/stable/c/c21a8870c98611e8f892511825c9607f1 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26870 – NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102
https://notcve.org/view.php?id=CVE-2024-26870
In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102 A call to listxattr() with a buffer size = 0 returns the actual size of the buffer needed for a subsequent call. When size > 0, nfs4_listxattr() does not return an error because either generic_listxattr() or nfs4_listxattr_nfs4_label() consumes exactly all the bytes then size is 0 when calling nfs4_listxattr_nfs4_user() which then triggers the following kernel BUG: [ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000) Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl', thus calling lisxattr() with size = 16 will trigger the bug. Add check on nfs4_listxattr() to return ERANGE error when it is called with size > 0 and the return value is greater than size. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4.2: corrige el ERROR del kernel nfs4_listxattr en mm/usercopy.c:102 Una llamada a listxattr() con un tamaño de búfer = 0 devuelve el tamaño real del búfer necesario para un convocatoria posterior. Cuando el tamaño > 0, nfs4_listxattr() no devuelve un error porque generic_listxattr() o nfs4_listxattr_nfs4_label() consume exactamente todos los bytes, entonces el tamaño es 0 al llamar a nfs4_listxattr_nfs4_user(), lo que luego activa el siguiente ERROR del kernel: [99.403778] ERROR del kernel en mm/usercopy.c:102! • https://git.kernel.org/stable/c/012a211abd5db098094ce429de5f046368391e68 https://git.kernel.org/stable/c/4403438eaca6e91f02d272211c4d6b045092396b https://git.kernel.org/stable/c/9d52865ff28245fc2134da9f99baff603a24407a https://git.kernel.org/stable/c/06e828b3f1b206de08ef520fc46a40b22e1869cb https://git.kernel.org/stable/c/79cdcc765969d23f4e3d6ea115660c3333498768 https://git.kernel.org/stable/c/80365c9f96015bbf048fdd6c8705d3f8770132bf https://git.kernel.org/stable/c/23bfecb4d852751d5e403557dd500bb563313baf https://git.kernel.org/stable/c/251a658bbfceafb4d58c76b77682c8bf7 • CWE-20: Improper Input Validation •