Vulnerabilidades

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mvm: no leer más allá de la notificación mfuart En caso de que el firmware envíe una notificación que dice que tiene más datos de los que tiene, leeremos más allá de los asignados para la notificación. Elimina la impresión del búfer, no la veremos por defecto. Si es necesario, podemos ver el contenido con rastreo. Así lo informó KFENCE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: mac80211: mesh: corrige la fuga de objetos mesh_preq_queue El código hwmp usa objetos de tipo mesh_preq_queue, agregados a una lista en ieee80211_if_mesh, para realizar un seguimiento del mpath que necesitamos resolver. Si se elimina mpath, se elimina la interfaz ex mesh, las entradas en esa lista nunca se limpiarán. Solucione este problema eliminando todos los elementos correspondientes de preq_queue en mesh_path_flush_pending(). Esto debería encargarse de informes KASAN como este: objeto sin referencia 0xffff00000668d800 (tamaño 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (edad 1836.444s) volcado hexadecimal (primeros 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>.. ......... retroceso: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] 8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/ 0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] 11_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/ 0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] xa1c [<00000000b36425d1>] hilo_trabajador+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/ 0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20 objeto sin referencia 0xffff000009051f00 (tamaño 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (edad 1836.440s) volcado hexadecimal (primero 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.... ...Xy..... retroceso: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] 0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/ 0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] 11_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/ 0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] xa1c [<00000000b36425d1>] hilo_trabajador+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/ 0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige ejecuciones entre perforación y AIO+DIO Después de confirmar "ocfs2: devuelve código de error real en ocfs2_dio_wr_get_block", fstests/generic/300 pasa de siempre falló a a veces falló: = ==================================================== ===================== [ 473.293420 ] ejecute fstests generic/300 [ 475.296983 ] JBD2: ignorando la información de recuperación en el diario [ 475.302473 ] ocfs2: Dispositivo de montaje (253,1 ) en (nodo local, ranura 0) con modo de datos ordenados. [ 494.290998 ] OCFS2: ERROR (dispositivo dm-1): ocfs2_change_extent_flag: El propietario 5668 tiene una extensión en cpos 78723 que ya no se puede encontrar [ 494.291609 ] Se descubrió corrupción en el disco. Ejecute fsck.ocfs2 una vez que el sistema de archivos esté desmontado. [ 494.292018 ] OCFS2: el sistema de archivos ahora es de solo lectura. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_write:5272 ERROR: estado = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: estado = -3 fio: Error io_u en el archivo /mnt/scratch/racer: sistema de archivos de solo lectura: escritura offset=460849152, buflen=131072 ========================== ================================================= En __blockdev_direct_IO , se llama a ocfs2_dio_wr_get_block para agregar extensiones no escritas a una lista. Las extensiones también se insertan en el árbol de extensiones en ocfs2_write_begin_nolock. Luego, otro hilo llama a fallocate para hacer un agujero en una de las extensiones no escritas. La extensión en cpos fue eliminada por ocfs2_remove_extent(). Al final del hilo de trabajo de io, ocfs2_search_extent_list descubrió que no existe tal extensión en los cpos. T1 T2 T3 bloqueo de inodo... insertar extensiones... desbloqueo de inodo ocfs2_fallocate __ocfs2_change_file_space bloqueo de inodo bloqueo ip_alloc_sem ocfs2_remove_inode_range inodo ocfs2_remove_btree_range ocfs2_remove_extent ^---eliminar la extensión en cpos 78723... desbloquear inodo ip_alloc_sem desbloquear ocfs2_dio_end_io ocfs2_dio_end_io_write bloquear ip_alloc_sem ocfs2_mark_extent_writing ocfs2_change_extent_flag ocfs2_search_extent_list ^ ---no se pudo encontrar la extensión... desbloquear ip_alloc_sem En la mayoría de los sistemas de archivos, fallocate no es compatible con ejecuciones con AIO+DIO, así que solucionelo agregando esperar a que todos los dio antes de fallocate/punch_hole como ext4.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring/rsrc: no bloquear mientras !TASK_RUNNING Hay un informe de io_rsrc_ref_quiesce() bloqueando un mutex mientras no TASK_RUNNING, lo cual se debe a que se olvidó de restaurar el estado después de io_run_task_work_sig( ) e intenta salir del bucle de espera. no llame a operaciones de bloqueo cuando !TASK_RUNNING; state=1 establecido en [] prepare_to_wait+0xa4/0x380 kernel/sched/wait.c:237 ADVERTENCIA: CPU: 2 PID: 397056 en kernel/sched/core.c:10099 __might_sleep+0x114/0x160 kernel/sched /core.c:10099 RIP: 0010:__might_sleep+0x114/0x160 kernel/sched/core.c:10099 Seguimiento de llamadas: __mutex_lock_common kernel/locking/mutex.c:585 [en línea] __mutex_lock+0xb4/0x940 kernel/ bloqueo/mutex.c:752 io_rsrc_ref_quiesce+0x590/0x940 io_uring/rsrc.c:253 io_sqe_buffers_unregister+0xa2/0x340 io_uring/rsrc.c:799 __io_uring_register io_uring/register.c:424 __do_sys_io_uring_register+ 0x5b9/0x2400 io_uring/registro .c:613 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xd8/0x270 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x6f/0x77

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vmxnet3: deshabilite el anillo de datos rx en caso de falla en la asignación de dma Cuando vmxnet3_rq_create() no puede asignar memoria para rq->data_ring.base, la llamada posterior a vmxnet3_rq_destroy_all_rxdataring no restablece rq->data_ring .desc_size para el anillo de datos que falló, lo que presumiblemente hace que el hipervisor haga referencia a él al recibir el paquete. Para corregir este error, rq->data_ring.desc_size debe establecerse en 0 para indicarle al hipervisor que desactive esta función. [95.436876] ¡ERROR del kernel en net/core/skbuff.c:207! [ 95.439074] código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI [ 95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1 [ 95.441558] Nombre de hardware: VMware, Inc. VMware Virtual Platform Plataforma de referencia de escritorio /440BX, BIOS 6.00 12/12/2018 [ 95.443481] RIP: 0010:skb_panic+0x4d/0x4f [ 95.444404] Código: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 50 ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9 ff <0f> 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff 48 8b 14 24 [ 7684] RSP : 0018:ffffa13340274dd0 EFLAGS: 00010246 [ 95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f [ 95.450148] RDX: 00000000000000 RSI: 00000000000000f6 RDI: 000000000000083f [ 95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: 0 [ 95.452886] R10: fffffffa04ed468 R11 : 0000000000000002 R12: 0000000000000000 [ 95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0 [ 95.455682] FS: 00000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000 [ 95.457178] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0 [ 95.459791] Seguimiento de llamadas: [ 95.460515] [ 95.461180] ? __die_body.cold+0x19/0x27 [ 95.462150] ? morir+0x2e/0x50 [ 95.462976] ? do_trap+0xca/0x110 [95.463973]? do_error_trap+0x6a/0x90 [95.464966]? skb_panic+0x4d/0x4f [95.465901]? exc_invalid_op+0x50/0x70 [95.466849]? skb_panic+0x4d/0x4f [95.467718]? asm_exc_invalid_op+0x1a/0x20 [95.468758]? skb_panic+0x4d/0x4f [ 95.469655] skb_put.cold+0x10/0x10 [ 95.470573] vmxnet3_rq_rx_complete+0x862/0x11e0 [vmxnet3] [ 95.471853] [vmxnet3] [95.473185] __napi_poll+0x2b/0x160 [95.474145] net_rx_action+ 0x2c6/0x3b0 [ 95.475115] handle_softirqs+0xe7/0x2a0 [ 95.476122] __irq_exit_rcu+0x97/0xb0 [ 95.477109] common_interrupt+0x85/0xa0 [ 95.478102] 95.478 846] [ 95.479603] asm_common_interrupt+0x26/0x40 [ 95.480657 ] RIP: 0010:pv_native_safe_halt+0xf/0x20 [ 95.481801] Código: 22 d7 e9 54 87 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 93 ba 3b 00 fb f4 2c 87 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 [ 95.485563] RSP: 0018:ffffa133400ffe58 EFLAGS: 00000246 [ 95.486882] RAX: 0000000000004000 RBX: ffff8fbbc1d14064 RCX: 0000000000000000 [ 95.488477] RDX: ffff8fbeefd80000 RSI: ffff8fbbc1d14000 RDI: 00000000000000001 [ 95.490067] RBP: d14064 R08: fffffffa0652260 R09: 00000000000010d3 [ 95.491683] R10: 0000000000000018 R11: ffff8fbeefdb4764 R12: fffffffa0652260 [ 95.493389] fffffffa06522e0 R14: 0000000000000001 R15 : 0000000000000000 [ 95.495035] acpi_safe_halt+0x14/0x20 [ 95.496127] acpi_idle_do_entry+0x2f/0x50 [ 95.497221] acpi_idle_enter+0x7f/0xd0 [ 95.498272] le_enter_state+0x81/0x420 [ 95.499375] cpuidle_enter+0x2d/0x40 [ 95.500400] do_idle+0x1e5/0x240 [ 95.501385] cpu_startup_entry+0x29/0x30 [ 95.502422] start_secondary+0x11c/0x140 [ 95.503454] common_startup_64+0x13e/0x141 [ 95.504466] [ 95.505197] Módulos vinculados en: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ip ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: corrige el uso de request.queuelist en Flush Friedrich Weber informó un problema de falla del kernel y lo bisecó para el commit 81ada09cc25e ("blk-flush: reutilizar rq queuelist en la máquina de estado de descarga"). La causa principal es que usamos "list_move_tail(&rq->queuelist, pendiente)" en las secuencias PREFLUSH/POSTFLUSH. Pero rq->queuelist.next == xxx ya que salió del plug->cached_rq en __blk_mq_alloc_requests_batch(). No inicializamos su lista de colas solo para esta primera solicitud, aunque se inicializará la lista de colas de todas las solicitudes emergentes posteriores. Solucionelo cambiando para usar "list_add_tail(&rq->queuelist, pendiente)" para que no sea necesario inicializar rq->queuelist. Debería estar bien ya que rq no puede estar en ninguna lista cuando PREFLUSH o POSTFLUSH, en realidad no tiene movimiento. Tenga en cuenta que el commit 81ada09cc25e ("blk-flush: reutilizar rq queuelist en la máquina de estado de descarga") también tiene otro requisito de que ningún controlador toque rq->queuelist después de blk_mq_end_request() ya que lo reutilizaremos para agregar rq al post-flush lista pendiente en POSTFLUSH. Si esto no es cierto, tendremos que revertir ese commit en mi humilde opinión. Esta versión actualizada agrega "list_del_init(&rq->queuelist)" en la devolución de llamada de Flush rq ya que la capa dm puede enviar una solicitud de un formato extraño no válido (REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH), lo que provoca el doble list_add si no se tiene este "list_del_init(&rq->queuelist) ". El extraño problema del formato no válido debería solucionarse en la capa dm.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/nouveau: no intente programar hpd_work en tarjetas headless si la tarjeta no tiene hardware de visualización, hpd_work y hpd_lock quedan sin inicializar, lo que provoca un ERROR al intentar programar hpd_work en tiempo de ejecución, reanudación de PM. Solucionelo agregando una bandera sin cabeza a DRM y omita cualquier hpd si está configurado.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: validar análisis del elemento de operación HE Validar que el elemento de operación HE tenga la longitud correcta antes de analizarlo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iio: temperatura: mlx90635: corrige la desreferencia de ERR_PTR en mlx90635_probe() Cuando falla devm_regmap_init_i2c(), regmap_ee podría ser un puntero de error, en lugar de verificar IS_ERR(regmap_ee), se verifica regmap, que Parece un error de copiar y pegar.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: mst: corrige el uso sospechoso de rcu en br_mst_set_state Convertí br_mst_set_state a RCU para evitar un use-after-free de VLAN, pero olvidé cambiar el asistente de desreferencia del grupo VLAN. Cambie al asistente deref de RCU del grupo vlan para corregir la advertencia de uso sospechoso de rcu.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: bridge: mst: pasar grupo vlan directamente a br_mst_vlan_set_state Pase el puntero del grupo vlan ya obtenido a br_mst_vlan_set_state() en lugar de desreferenciarlo nuevamente. Cada persona que llama ya lo ha desreferenciado correctamente para su contexto. Este cambio es necesario para la siguiente corrección sospechosa de desreferencia de RCU. No se pretenden cambios funcionales.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/dpt: hacer que el objeto DPT no se pueda reducir. En algunos escenarios, el objeto DPT se reduce pero el framebuffer real no y, por lo tanto, sigue ahí en vm->bound_list del DPT. Luego intenta reescribir las PTE mediante una asignación de CPU obsoleta. Esto provoca pánico. [vsyrjala: Agregar comentario TODO] (seleccionado del commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)