Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfs: soluciona el pánico cuando falla nfs4_ff_layout_prepare_ds() Hemos estado viendo el siguiente error de pánico en producción: desreferencia del puntero NULL del kernel, dirección: 0000000000000065 PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD RIP : 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles] Seguimiento de llamadas: ? __die+0x78/0xc0 ? page_fault_oops+0x286/0x380? __rpc_execute+0x2c3/0x470 [sunrpc] ? rpc_new_task+0x42/0x1c0 [sunrpc] ? exc_page_fault+0x5d/0x110? asm_exc_page_fault+0x22/0x30? ff_layout_free_layoutreturn+0x110/0x110 [nfs_layout_flexfiles]? ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]? ff_layout_cancel_io+0x6f/0x90 [nfs_layout_flexfiles] pnfs_mark_matching_lsegs_return+0x1b0/0x360 [nfsv4] pnfs_error_mark_layout_for_return+0x9e/0x110 [nfsv4] ? ff_layout_send_layouterror+0x50/0x160 [nfs_layout_flexfiles] nfs4_ff_layout_prepare_ds+0x11f/0x290 [nfs_layout_flexfiles] ff_layout_pg_init_write+0xf0/0x1f0 [nfs_layout_flexfiles] __nfs_pageio_add_re búsqueda+0x154/0x6c0 [nfs] nfs_pageio_add_request+0x26b/0x380 [nfs] nfs_do_writepage+0x111/0x1e0 [nfs] nfs_writepages_callback+ 0xf/0x30 [nfs] write_cache_pages+0x17f/0x380 ? nfs_pageio_init_write+0x50/0x50 [nfs] ? nfs_writepages+0x6d/0x210 [nfs]? nfs_writepages+0x6d/0x210 [nfs] nfs_writepages+0x125/0x210 [nfs] do_writepages+0x67/0x220? generic_perform_write+0x14b/0x210 filemap_fdatawrite_wbc+0x5b/0x80 file_write_and_wait_range+0x6d/0xc0 nfs_file_fsync+0x81/0x170 [nfs] ? nfs_file_mmap+0x60/0x60 [nfs] __x64_sys_fsync+0x53/0x90 do_syscall_64+0x3d/0x90 Entry_SYSCALL_64_after_hwframe+0x46/0xb0 Inspeccionando el núcleo con drgn pude extraer esto >>> prog.crashed_thread().stack_trace()[0 ] # 0 en 0xffffffffa079657a (ff_layout_cancel_io+0x3a/0x84) en ff_layout_cancel_io en fs/nfs/flexfilelayout/flexfilelayout.c:2021:27 >>> prog.crashed_thread().stack_trace()[0]['idx'] (u32)1 >>> prog.crashed_thread().stack_trace()[0]['flseg'].mirror_array[1].mirror_ds (struct nfs4_ff_layout_ds *)0xffffffffffffffed Esto queda claro en el seguimiento de la pila, llamamos a nfs4_ff_layout_prepare_ds(), lo que podría generar un error inicializando mirror_ds, y luego vamos a limpiarlo todo y nuestra verificación es solo para if (!mirror->mirror_ds). Esto es inconsistente con el resto de usuarios de mirror_ds, que tienen if (IS_ERR_OR_NULL(mirror_ds)) para evitar tropezar con este escenario exacto. Solucione esto en ff_layout_cancel_io() para asegurarnos de que no entremos en pánico cuando recibamos un error. También revisé todas las demás instancias de verificación de mirror_ds y parece que estamos haciendo las verificaciones correctas en todas partes, solo desreferenciando incondicionalmente mirror_ds cuando sabemos que sería válido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para truncar las páginas de meta-inodo a la fuerza El siguiente caso de carrera puede causar corrupción de datos: Hilo Un hilo de GC - gc_data_segment - ra_data_block - página de meta_inodo bloqueada - f2fs_inplace_write_data - invalidate_mapping_pages: no se puede invalidar meta_inode página debido a falla de bloqueo o estado sucio|reescritura - f2fs_submit_page_bio: escribe los últimos datos sucios en el blkaddr antiguo - move_data_block - carga datos antiguos de la página meta_inode - f2fs_submit_page_write: escribe datos antiguos en el blkaddr nuevo Porque invalidate_mapping_pages() omitirá la página de invalidación cuyo estado no está claro incluyendo bloqueado, sucio, reescritura, etc., por lo que debemos usar truncate_inode_pages_range() en lugar de invalidate_mapping_pages() para asegurarnos de que la página meta_inode se elimine.

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! [99.404063] Error interno: Ups - ERROR: 00000000f2000800 [#1] SMP [99.408463] CPU: 0 PID: 3310 Comm: python3 No contaminado 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Seguimiento de llamadas: [ 99.41 5985] 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] 48/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] Código: aa0003e3 d000a3e0 91310000 97f49bdb (d42 10000) El problema se reproduce cuando generic_listxattr() devuelve 'system.nfs4_acl', llamando así a lisxattr() con tamaño = 16 activará el error. Agregue verificación en nfs4_listxattr() para devolver el error ERANGE cuando se llama con un tamaño > 0 y el valor de retorno es mayor que el tamaño.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrige la desreferencia del puntero NULL en f2fs_submit_page_write() ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000014 RIP: 0010:f2fs_submit_page_write+0x6cf/0x780 [f2fs] Seguimiento de llamadas: ? show_regs+0x6e/0x80? __morir+0x29/0x70 ? page_fault_oops+0x154/0x4a0? prb_read_valid+0x20/0x30? __irq_work_queue_local+0x39/0xd0 ? irq_work_queue+0x36/0x70? do_user_addr_fault+0x314/0x6c0? exc_page_fault+0x7d/0x190? asm_exc_page_fault+0x2b/0x30? f2fs_submit_page_write+0x6cf/0x780 [f2fs] ? f2fs_submit_page_write+0x736/0x780 [f2fs] do_write_page+0x50/0x170 [f2fs] f2fs_outplace_write_data+0x61/0xb0 [f2fs] f2fs_do_write_data_page+0x3f8/0x660 [f2fs] f2fs_write_single_data_page+0 x5bb/0x7a0 [f2fs] f2fs_write_cache_pages+0x3da/0xbe0 [f2fs] .. Es posible que otros hilos hayan agregado este fio a io->bio y hayan enviado el io->bio antes de ingresar a f2fs_submit_page_write(). En este punto io->bio = NULL. Si is_end_zone_blkaddr(sbi, fio->new_blkaddr) de este fio es verdadero, entonces se produce un error de desreferencia de puntero NULL en bio_get(io->bio). El código original para determinar el final de la zona estaba después de "out:", lo que habría pasado por alto a algún fio que es el final de la zona. Moví este código antes de "omitir:" para asegurarme de que esté hecho para cada fio.

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: hisi_sas: soluciona un problema de interbloqueo relacionado con el volcado automático. Si emitimos un comando de desactivación PHY, el dispositivo conectado se desconectará si se produce un error ECC de 2 bits en el Al mismo tiempo, se puede encontrar una tarea colgada: [ 4613.652388] INFORMACIÓN: tarea kworker/u256:0:165233 bloqueada durante más de 120 segundos. [4613.666297] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [ 4613.674809] tarea:kworker/u256:0 estado:D pila: 0 pid:165233 ppid: 2 banderas:0x00000208 [ 4613.683959] Cola de trabajo: 0000:74:02.0_disco_q sas_revalidate_domain [libsas] [ 4613.691518] Rastreo de llamadas: [4613.694678] __switch_to +0xf8/0x17c [ 4613.698872] __programación+0x660/0xee0 [ 4613.703063] programación+0xac/0x240 [ 4613.706994] programación_timeout+0x500/0x610 [ 4613.711705] c [ 4613.715548] abajo+0x240/0x2d0 [ 4613.719221] hisi_sas_internal_abort_timeout+0x1bc /0x260 [hisi_sas_main] [ 4613.726618] sas_execute_internal_abort+0x144/0x310 [libsas] [ 4613.732976] sas_execute_internal_abort_dev+0x44/0x60 [libsas] [ 4613.739504] _dev.isra.0+0xbc/0x1b0 [hisi_sas_main] [ 4613.747499] hisi_sas_dev_gone+0x174/0x250 [hisi_sas_main] [ 4613.753682] sas_notify_lldd_dev_gone+0xec/0x2e0 [libsas] [ 4613.759781] sas_unregister_common_dev+0x4c/0x7a0 [libsas] [ 4613.765962] sas_destruct_devices+0xb8/0x120 [libsas] [ 4613.771709] sas_do_revalidate_domain.constprop.0+0x1b8/0x31c [libsas ] [ 4613.778930] sas_revalidate_domain+0x60/0xa4 [libsas] [ 4613.784716] Process_one_work+0x248/0x950 [ 4613.789424] trabajador_thread+0x318/0x934 [ 4613.793878] 0x200 [4613.797810] ret_from_fork+0x10/0x18 [4613.802121] INFORMACIÓN: tarea kworker/u256:4:316722 bloqueado durante más de 120 segundos. [4613.816026] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [ 4613.824538] tarea:kworker/u256:4 estado:D pila: 0 pid:316722 ppid: 2 banderas:0x00000208 [ 4613.833670] Cola de trabajo: 0000:74:02.0 hisi_sas_rst_work_handler [hisi_sas_main] [ 4613.841491 ] Rastreo de llamadas: [4613.844647] __switch_to+ 0xf8/0x17c [ 4613.848852] __programación+0x660/0xee0 [ 4613.853052] programación+0xac/0x240 [ 4613.856984] programación_timeout+0x500/0x610 [ 4613.861695] c [ 4613.865542] abajo+0x240/0x2d0 [ 4613.869216] hisi_sas_controller_prereset+0x58/ 0x1fc [hisi_sas_main] [ 4613.876324] hisi_sas_rst_work_handler+0x40/0x8c [hisi_sas_main] [ 4613.883019] Process_one_work+0x248/0x950 [ 4613.887732] trabajador_thread+0x318/0x934 [ 461 3.892204] kthread+0x190/0x200 [ 4613.896118] ret_from_fork+0x10/0x18 [ 4613.900423] INFORMACIÓN: tarea kworker/u256:1:348985 bloqueada durante más de 121 segundos. [4613.914341] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [ 4613.922852] tarea:kworker/u256:1 estado:D pila: 0 pid:348985 ppid: 2 banderas:0x00000208 [ 4613.931984] Cola de trabajo: 0000:74:02.0_event_q sas_port_event_worker [libsas] [ 4613.939549] Rastreo de llamadas: [4613.942702] __switch_to +0xf8/0x17c [ 4613.946892] __schedule+0x660/0xee0 [ 4613.951083] Schedule+0xac/0x240 [ 4613.955015] Schedule_timeout+0x500/0x610 [ 4613.959725] x610 [ 4613.964349] espera_para_compleción+0x3c/0x5c [ 4613.969146] descarga_cola de trabajo+0x198 /0x790 [ 4613.973776] sas_porte_broadcast_rcvd+0x1e8/0x320 [libsas] [ 4613.979960] sas_port_event_worker+0x54/0xa0 [libsas] [ 4613.985708] Process_one_work+0x248/0x950 [ 4613.9 90420] hilo_trabajador+0x318/0x934 [ 4613.994868] kthread+0x190/0x200 [ 4613.998800 ] ret_from_fork+0x10/0x18 Esto se debe a que cuando el dispositivo se desconecta, obtenemos el semáforo hisi_hba y enviamos el comando ABORT_DEV al dispositivo. Sin embargo, el aborto interno expiró debido al error ECC de 2 bits y activa el volcado automático. Además, dado que se obtuvo el semáforo hisi_hba, el volcado no se puede ejecutar y el controlador no se puede restablecer. Por lo tanto, los interbloqueos ocurren en las siguientes dependencias circulares ---truncadas---

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( !!mtk_crtc->event) paso 2: mtk_crtc_ddp_irq -> mtk_drm_finish _page_flip: bloquear mtk_crtc->evento establecido en nulo, pendiente_needs_vblank configurado en falso desbloqueo pendiente_needs_vblank configurado en verdadero, paso 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip llamado nuevamente, pendiente_needs_vblank sigue siendo verdadero //puntero nulo En lugar de proteger todo el mtk_drm_crtc_atomic_flush(), es más eficiente simplemente verificar si mtk_crtc->even t es nulo antes de su uso.

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: xilinx - llamada a finalizar con bh deshabilitado Al llamar a crypto_finalize_request, BH debe estar deshabilitado para evitar que se active el siguiente seguimiento de llamadas: ------------[ cut aquí ]------------ ADVERTENCIA: CPU: 2 PID: 74 en crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118 Módulos vinculados en: cryptodev(O) CPU: 2 PID: 74 Comm : firmware:zynqmp Contaminado: GO 6.8.0-rc1-yocto-standard #323 Nombre del hardware: ZynqMP ZCU102 Rev1.0 (DT) pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: crypto_finalize_request+0xa0/0x118 lr: crypto_finalize_request+0x104/0x118 sp: ffffffc085353ce0 x29: ffffffc085353ce0 x28: 00000000000000000 x27: ffffff8808ea8688 x26: 15038 x25: 0000000000000000 x24: ffffff880100db00 x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000 x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0 x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8 x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001 x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000 x2 : ffffffc7f9653000 x1: 0000000000000000 x0: ffffff8802d20000 Rastreo de llamadas: crypto_finalize_request+0xa0/0x118 crypto_finalize_aead_request+0x18/0x30 zynqmp_handle_aes_req+0xcc/0x388 crypto_pump_work+0x 168/0x2d8 kthread_worker_fn+0xfc/0x3a0 kthread+0x118/0x138 ret_from_fork+0x10/0x20 sello de evento irq: 40 hardirqs habilitado por última vez en (39): [] _raw_spin_unlock_irqrestore+0x70/0xb0 hardirqs habilitado por última vez en (40): [] el1_dbg+0x28/0x90 softirqs habilitado por última vez en (36): [] _comenzar +0x8c/0xf0 softirqs se deshabilitó por última vez en (34): [] kernel_neon_begin+0x60/0xf0 ---[ final de seguimiento 0000000000000000 ]---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm: llamar al método de reanudación en suspensión interna. Se informó este bloqueo al experimentar con el conjunto de pruebas lvm2. La corrupción de la lista se debe al hecho de que los métodos de possuspensión y reanudación no se emparejaron correctamente; hubo dos llamadas consecutivas a la función origin_postsuspend. La segunda llamada intenta eliminar la entrada "hash_list" de una lista, mientras que la primera llamada ya la eliminó. Corrige __dm_internal_resume para que llame a los métodos preresume y resume de los objetivos de la tabla. Si falla un método de reanudación previa de algún objetivo, estamos en una situación complicada. No podemos devolver un error porque se supone que dm_internal_resume no devuelve errores. No podemos devolver el éxito, porque entonces los métodos "reanudar" y "postsuspender" no se emparejarían correctamente. Entonces, configuramos el indicador DMF_SUSPENDED y simulamos una suspensión normal; puede confundir las herramientas del espacio de usuario, pero no causará una falla del kernel. ------------[ cortar aquí ]------------ ¡ERROR del kernel en lib/list_debug.c:56! código de operación no válido: 0000 [#1] PREEMPT SMP CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/ 01/2014 RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0 RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282 RAX: 000000000000004e RBX: ffff888143b6eb80 0000000000000000 RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 8 R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001 R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: fffffffa02e4bb0 FS: 7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0 Seguimiento de llamadas: ? morir+0x2d/0x80? do_trap+0xeb/0xf0? __list_del_entry_valid_or_report+0x77/0xc0 ? do_error_trap+0x60/0x80? __list_del_entry_valid_or_report+0x77/0xc0 ? exc_invalid_op+0x49/0x60? __list_del_entry_valid_or_report+0x77/0xc0 ? asm_exc_invalid_op+0x16/0x20? table_deps+0x1b0/0x1b0 [dm_mod] ? __list_del_entry_valid_or_report+0x77/0xc0 origin_postsuspend+0x1a/0x50 [dm_snapshot] dm_table_postsuspend_targets+0x34/0x50 [dm_mod] dm_suspend+0xd8/0xf0 [dm_mod] dev_suspend+0x1f2/0x2f0 modo] ? table_deps+0x1b0/0x1b0 [dm_mod] ctl_ioctl+0x300/0x5f0 [dm_mod] dm_compat_ctl_ioctl+0x7/0x10 [dm_mod] __x64_compat_sys_ioctl+0x104/0x170 do_syscall_64+0x184/0x1b0 entrada _SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0xf7e6aead --- [fin de seguimiento 0000000000000000]---

Vulnerabilidad de autorización faltante en Undsgn Uncode Core. Este problema afecta a Uncode Core: desde n/a hasta 2.8.8.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: b43: Detener/activar la cola correcta en la ruta DMA Tx cuando QoS está deshabilitado Cuando QoS está deshabilitado, el valor de prioridad de la cola no se asignará a la cola ieee80211 correcta ya que solo hay una cola. Detener/activar la cola 0 cuando la QoS está deshabilitada para evitar intentar detener/activar una cola inexistente y no poder detener/activar la cola real instanciada. Registro del problema antes del cambio (con el parámetro del kernel qos=0): [+5.112651] ------------[ cortar aquí ]------------ [ +0.000005] ADVERTENCIA: CPU: 7 PID: 25513 en net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Módulos vinculados en: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft _chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype superposición ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt _tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel _rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_ buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [+0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common _hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc botón ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fusible retroiluminación firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci cd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [última descarga: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Contaminado: GWO 6.6.7 #1-NixOS [ +0.000 003] Hardware nombre: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 13/06/2019 [+0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [+0.000046] Código: 00 5 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 000002 RCX: 0000000000000000 [+0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS :ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0 ---truncado---