Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: asegúrese de que snd_una se inicialice correctamente al conectarse. Esto está estrictamente relacionado con el commit fb7a0d334894 ("mptcp: asegúrese de que snd_nxt se inicialice correctamente al conectarse"). Resulta que syzkaller puede activar la retransmisión después del respaldo y antes de procesar cualquier otro paquete entrante, de modo que snd_una aún permanece sin inicializar. Solucione el problema al inicializar explícitamente snd_una junto con snd_nxt y write_seq.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/exynos/vidi: corrige la pérdida de memoria en .get_modes() El EDID duplicado nunca se libera. Arreglalo.

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 ha resuelto la siguiente vulnerabilidad: HID: logitech-dj: Reparar pérdida de memoria en logi_dj_recv_switch_to_dj_mode() Reparar una pérdida de memoria en la ruta de error logi_dj_recv_send_report().

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 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 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)

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: wifi: iwlwifi: mvm: verifique n_ssids antes de acceder a los ssids en algunas versiones de cfg80211, el punto ssids puede ser válido aunque n_ssids sea 0. Accediendo al puntero en este caso provocará un acceso fuera de los límites. Solucione este problema comprobando primero n_ssids.

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: memblock: make memblock_set_node() también advierte sobre el uso de MAX_NUMNODES En un sistema x86 (antiguo) con SRAT que solo cubre espacio superior a 4 Gb: ACPI: SRAT: Nodo 0 PXM 0 [mem 0x100000000 -0xfffffffff] hotplug, El commit a la que se hace referencia a continuación hace que esta configuración NUMA ya no sea rechazada por un kernel CONFIG_NUMA=y (anteriormente NUMA: los nodos solo cubren 6144 MB de su RAM e820 de 8185 MB. No se usa. No se encontró ninguna configuración NUMA Falsificar un nodo en [mem 0x0000000000000000-0x000000027fffffff] se vio en el registro directamente después del mensaje citado anteriormente), debido a que memblock_validate_numa_coverage() verifica NUMA_NO_NODE (solamente). Esto a su vez llevó a la advertencia de memblock_alloc_range_nid() sobre la activación de MAX_NUMNODES, seguida de una deref NULL en memmap_init() al intentar acceder a los datos del nodo 64 (NODE_SHIFT=6). Para compensar dicho cambio, active memblock_set_node() y ajuste un valor pasado de MAX_NUMNODES, tal como lo hacen otras funciones.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bnxt_en: Ajusta el registro de mensajes de firmware en caso de token liberado en __hwrm_send() En caso de que el token se libere debido al token->estado == BNXT_HWRM_DEFERRED, token liberado (establecido en NULL ) se utiliza en mensajes de registro. Se espera que este problema se evite mediante el código de error HWRM_ERR_CODE_PF_UNAVAILABLE. Pero este código de error lo devuelve un firmware reciente. Por lo tanto, es posible que algunos firmware no lo devuelvan. Esto puede provocar una desreferencia del puntero NULL. Ajuste este problema agregando una verificación del puntero del token. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.