Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usbnet: ipheth: usar ubicación estática de NDP16 en URB El código original permitía que el inicio de NDP16 estuviera en cualquier lugar dentro de URB según el valor `wNdpIndex` en NTH16. Solo se comprobó la posición de inicio de NDP16, por lo que era posible que incluso la parte de longitud fija de NDP16 se extendiera más allá del final de URB, lo que generaba una lectura fuera de los límites. En los dispositivos iOS, el encabezado NDP16 siempre sigue directamente a NTH16. Confíe en este formato específico y compruébelo. Esto, junto con la comprobación de longitud mínima de URB específica de NCM que ya existe, garantizará que la parte de longitud fija de NDP16 más una cantidad establecida de DPE quepan dentro de URB. Tenga en cuenta que esta confirmación por sí sola no aborda por completo la lectura OoB. El límite en la cantidad de DPE debe aplicarse por separado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usbnet: ipheth: corrige posible desbordamiento en la comprobación de longitud de DPE Originalmente, era posible que la comprobación de longitud de DPE se desbordara si wDatagramIndex + wDatagramLength > U16_MAX. Esto podría provocar una lectura OoB. Mueva el término wDatagramIndex al otro lado de la desigualdad. Una condición existente asegura que wDatagramIndex < urb->actual_length.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: fastrpc: Se corrige el tamaño de página del búfer de copia Para un búfer no registrado, el controlador fastrpc copia el búfer y lo pasa al subsistema remoto. Hay un problema con la implementación actual del cálculo del tamaño de página que no considera el desplazamiento en el cálculo. Esto podría provocar que se pase un tamaño de página incorrecto y fuera de los límites, lo que podría generar un problema de memoria. Calcule el inicio y el final de la página utilizando la dirección ajustada por desplazamiento en lugar de la dirección absoluta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFC: nci: Añadir comprobación de los límites en nci_hci_create_pipe() La variable "pipe" es un u8 que proviene de la red. Si es mayor que 127, entonces da como resultado una corrupción de memoria en el llamador, nci_hci_connect_gate().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: se corrigen posibles desbordamientos de int en nilfs_fiemap() Dado que nilfs_bmap_lookup_contig() en nilfs_fiemap() calcula su resultado al estar preparado para pasar por bloques potencialmente maxblocks == INT_MAX, el valor en n puede experimentar un desbordamiento causado por el desplazamiento a la izquierda de blkbits. Si bien es extremadamente improbable que ocurra, no corra riesgos y convierta la expresión de la mano derecha a un tipo más amplio para mitigar el problema. Encontrado por Linux Verification Center (linuxtesting.org) con la herramienta de análisis estático SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ata: libata-sff: Asegúrese de que no podamos escribir fuera del búfer asignado reveliofuzzing informó que un ioctl SCSI_IOCTL_SEND_COMMAND con out_len establecido en 0xd42, comando SCSI establecido en ATA_16 PASS-THROUGH, comando ATA establecido en ATA_NOP y protocolo establecido en ATA_PROT_PIO, puede hacer que ata_pio_sector() escriba fuera del búfer asignado, sobrescribiendo memoria aleatoria. Si bien se supone que un dispositivo ATA debe abortar un comando ATA_NOP, parece haber un error en libata-sff o QEMU, donde este estado no está establecido o el estado se borra antes de la lectura por ata_sff_hsm_move(). De todos modos, es muy probable que se trate de un error separado. Si analizamos __atapi_pio_bytes(), veremos que ya tiene una comprobación de seguridad para garantizar que __atapi_pio_bytes() no pueda escribir fuera del búfer asignado. Agreguemos una comprobación similar a ata_pio_sector(), de modo que ata_pio_sector() tampoco pueda escribir fuera del búfer asignado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: corrige una ejecución para un MR de ODP que conduce a un CQE con error Este parche soluciona una condición de ejecución para un MR de ODP que puede resultar en un CQE con un error en el QP de UMR. Durante el flujo __mlx5_ib_dereg_mr(), ocurre la siguiente secuencia de llamadas: mlx5_revoke_mr() mlx5r_umr_revoke_mr() mlx5r_umr_post_send_wait() En este punto, la lkey se libera desde la perspectiva del hardware. Sin embargo, al mismo tiempo, mlx5_ib_invalidate_range() podría ser activado por otra tarea que intente invalidar un rango para la misma lkey liberada. Esta tarea: - Adquirirá el bloqueo umem_odp->umem_mutex. - Llamará a mlx5r_umr_update_xlt() en el QP de UMR. - Dado que la lkey ya se ha liberado, esto puede provocar un error de CQE, lo que hace que el QP de UMR entre en un estado de error [1]. Para resolver esta condición de ejecución, el bloqueo umem_odp->umem_mutex ahora también se adquiere como parte del ámbito mlx5_revoke_mr(). Tras una revocación exitosa, configuramos umem_odp->private que apunta a ese MR en NULL, lo que evita cualquier otro intento de invalidación en su lkey. [1] De dmesg: infiniband rocep8s0f0: dump_cqe:277:(pid 0): Error de WC: 6, Mensaje: error de operación de enlace de memoria cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2 ADVERTENCIA: CPU: 15 PID: 1506 en drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] Módulos vinculados en: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss superposición de oid_registry rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong No contaminado 6.12.0-rc7+ #1626 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib] [..] Llamada Rastreo: mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib] mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib] __mmu_notifier_invalidate_range_start+0x1e1/0x240 zap_page_range_single+0xf1/0x1a0 madvise_vma_behavior+0x677/0x6e0 do_madvise+0x1a2/0x4b0 __x64_sys_madvise+0x25/0x30 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/osnoise: Arreglar el restablecimiento de los puntos de seguimiento Si se inicia un rastreador timerlat con la opción de osnoise OSNOISE_WORKLOAD deshabilitada, pero luego se habilita esa opción y se elimina timerlat, los puntos de seguimiento que se habilitaron en el registro de timerlat no se deshabilitan. Si la opción se deshabilita nuevamente y se inicia timelat, entonces se activa una advertencia en el código del punto de seguimiento debido a que se registra nuevamente el punto de seguimiento sin deshabilitarlo nunca. No use las mismas opciones definidas en el espacio de usuario para saber que debe deshabilitar los puntos de seguimiento cuando se elimina timerlat. En su lugar, configure un indicador global cuando esté habilitado y use ese indicador para saber que debe deshabilitar los eventos. ~# echo NO_OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo timerlat > /sys/kernel/tracing/current_tracer ~# echo OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo nop > /sys/kernel/tracing/current_tracer ~# echo NO_OSNOISE_WORKLOAD > /sys/kernel/tracing/osnoise/options ~# echo timerlat > /sys/kernel/tracing/current_tracer Desencadenadores: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 6 PID: 1337 en kernel/tracepoint.c:294 tracepoint_add_func+0x3b6/0x3f0 Módulos vinculados: CPU: 6 UID: 0 PID: 1337 Comm: rtla No contaminado 6.13.0-rc4-test-00018-ga867c441128e-dirty #73 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 RIP: 0010:tracepoint_add_func+0x3b6/0x3f0 Código: 48 8b 53 28 48 8b 73 20 4c 89 04 24 e8 23 59 11 00 4c 8b 04 24 e9 36 fe ff ff 0f 0b b8 ea ff ff ff 45 84 e4 0f 84 68 fe ff ff <0f> 0b e9 61 fe ff ff 48 8b 7b 18 48 85 ff 0f 84 4f ff ff ff 49 8b RSP: 0018:ffffb9b003a87ca0 EFLAGS: 00010202 RAX: 00000000ffffffef RBX: ffffffff92f30860 RCX: 000000000000000 RDX: 000000000000000 RSI: ffff9bf59e91ccd0 RDI: ffffffff913b6410 RBP: 000000000000000a R08: 00000000000005c7 R09: 0000000000000002 R10: ffffb9b003a87ce0 R11: 0000000000000002 R12: 0000000000000001 R13: ffffb9b003a87ce0 R14: ffffffffffffffff R15: 0000000000000008 FS: 00007fce81209240(0000) GS:ffff9bf6fdd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055e99b728000 CR3: 00000001277c0002 CR4: 0000000000172ef0 Seguimiento de llamadas: ? __warn.cold+0xb7/0x14d ? tracepoint_add_func+0x3b6/0x3f0 ? report_bug+0xea/0x170 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? __pfx_trace_sched_migrate_callback+0x10/0x10 ? tracepoint_add_func+0x3b6/0x3f0 ? __pfx_trace_sched_migrate_callback+0x10/0x10 ? __pfx_trace_sched_migrate_callback+0x10/0x10 tracepoint_probe_register+0x78/0xb0 ? __pfx_trace_sched_migrate_callback+0x10/0x10 osnoise_workload_start+0x2b5/0x370 timerlat_tracer_init+0x76/0x1b0 tracing_set_tracer+0x244/0x400 tracing_set_trace_write+0xa0/0xe0 vfs_write+0xfc/0x570 ? do_sys_openat2+0x9c/0xe0 ksys_write+0x72/0xf0 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: winwing: Agregar comprobación NULL en winwing_init_led() devm_kasprintf() puede devolver un puntero NULL en caso de error, pero este valor devuelto en winwing_init_led() no se comprueba. Agregar comprobación NULL en winwing_init_led() para controlar el error de desreferencia de puntero NULL del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvkm/gsp: avanza correctamente el puntero de lectura de la cola de mensajes GSP Un mensaje de evento GSP consta de tres partes: encabezado del mensaje, encabezado RPC, cuerpo del mensaje. GSP calcula el número de páginas a escribir a partir del tamaño total de un mensaje GSP. Este comportamiento se puede observar a partir del movimiento del puntero de escritura. Sin embargo, nvkm solo toma el tamaño del encabezado RPC y el cuerpo del mensaje como el tamaño del mensaje al avanzar el puntero de lectura. Al manejar un mensaje GSP de dos páginas en el caso de no reversión, toma erróneamente el cuerpo del mensaje anterior como el encabezado del mensaje del siguiente mensaje. Como la "longitud del mensaje" tiende a ser cero, en el cálculo del tamaño que se debe copiar (0 - tamaño de (encabezado del mensaje)), el tamaño que se debe copiar será "0xffffffxx". También desencadena un pánico del kernel debido a un error de puntero NULL. [ 547.614102] mensaje: 00000f90: ff ff ff ff ff ff ff ff 40 d7 18 fb 8b 00 00 00 ........@....... [ 547.622533] mensaje: 00000fa0: 00 00 00 00 ff ff ff ff ff ff ff 00 00 00 00 ................ [ 547.630965] msj: 00000fb0: ff ff ff ff ff ff ff ff 00 00 00 00 ff ff ff ff ................ [ 547.639397] msj: 00000fc0: ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff ff ................ [ 547.647832] nvkm 0000:c1:00.0: gsp: peek msg rpc fn:0 len:0x0/0xffffffffffffffe0 [ 547.655225] nvkm 0000:c1:00.0: gsp: get msg rpc fn:0 len:0x0/0xffffffffffffffe0 [ 547.662532] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000020 [ 547.669485] #PF: acceso de lectura del supervisor en modo núcleo [ 547.674624] #PF: error_code(0x0000) - página no presente [ 547.679755] PGD 0 P4D 0 [ 547.682294] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 547.686643] CPU: 22 PID: 322 Comm: kworker/22:1 Contaminado: GE 6.9.0-rc6+ #1 [ 547.694893] Nombre del hardware: ASRockRack 1U1G-MILAN/N/ROMED8-NL, BIOS L3.12E 09/06/2022 [ 547.702626] Cola de trabajo: eventos r535_gsp_msgq_work [nvkm] [ 547.707921] RIP: 0010:r535_gsp_msg_recv+0x87/0x230 [nvkm] [ 547.713375] Código: 00 8b 70 08 48 89 e1 31 d2 4c 89 f7 e8 12 f5 ff ff 48 89 c5 48 85 c0 0f 84 cf 00 00 00 48 81 fd 00 f0 ff ff 0f 87 c4 00 00 00 <8b> 55 10 41 8b 46 30 85 d2 0f 85 f6 00 00 00 83 f8 04 76 10 ba 05 [ 547.732119] RSP: 0018:ffffabe440f87e10 EFLAGS: 00010203 [ 547.737335] RAX: 0000000000000010 RBX: 000000000000000008 RCX: 000000000000003f [ 547.744461] RDX: 0000000000000000 RSI: ffffabe4480a8030 RDI: 0000000000000010 [ 547.751585] RBP: 0000000000000010 R08: 0000000000000000 R09: ffffabe440f87bb0 [ 547.758707] R10: ffffabe440f87dc8 R11: 0000000000000010 R12: 0000000000000000 [ 547.765834] R13: 0000000000000000 R14: ffff9351df1e5000 R15: 0000000000000000 [ 547.772958] FS: 0000000000000000(0000) GS:ffff93708eb00000(0000) knlGS:0000000000000000 [ 547.781035] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 547.786771] CR2: 0000000000000020 CR3: 00000003cc220002 CR4: 0000000000770ef0 [ 547.793896] PKRU: 55555554 [ 547.796600] Rastreo de llamadas: [ 547.799046] [ 547.801152] ? __die+0x20/0x70 [ 547.804211] ? page_fault_oops+0x75/0x170 [ 547.808221] ? print_hex_dump+0x100/0x160 [ 547.812226] ? exc_page_fault+0x64/0x150 [ 547.816152] ? asm_exc_page_fault+0x22/0x30 [ 547.820341] ? r535_gsp_msg_recv+0x87/0x230 [nvkm] [ 547.825184] r535_gsp_msgq_work+0x42/0x50 [nvkm] [ 547.829845] process_one_work+0x196/0x3d0 [ 547.833861] worker_thread+0x2fc/0x410 [ 547.837613] ? __pfx_worker_thread+0x10/0x10 [ 547.841885] kthread+0xdf/0x110 [ 547.845031] ? __pfx_kthread+0x10/0x10 [ 547.848775] ret_from_fork+0x30/0x50 [ 547.852354] ? __pfx_kthread+0x10/0x10 [ 547.856097] ret_from_fork_asm+0x1a/0x30 [ 547.860019] [ 547.862208] Módulos vinculados en: nvkm(E) gsp_log(E) snd_seq_dummy(E) snd_hrtimer(E) snd_seq(E) snd_timer(E) snd_seq_device(E) snd(E) soundcore(E) rfkill(E) qrtr(E) vfat(E) fat(E) ipmi_ssif(E) amd_atl(E) intel_rapl_msr(E) intel_rapl_common(E) amd64_edac(E) mlx5_ ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: Intel: hda-dai: Asegúrese de que el widget DAI sea válido durante los parámetros Cada DAI de la CPU debe asociarse con un widget. Sin embargo, la topología podría no crear la cantidad correcta de widgets DAI para amplificadores agregados. Y provocará una deferencia de puntero NULL. Verifique que el widget DAI asociado con el DAI de la CPU sea válido para evitar la deferencia de puntero NULL debido a la falta de widgets DAI en topologías con amplificadores agregados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Corrección del error de acceso fuera de los límites Las estadísticas de autogeneración se colocan en un búfer mediante la función print_array_to_buf_index(). El parámetro de longitud de matriz que se pasa a la función es demasiado grande, lo que da como resultado un posible error de memoria fuera de los límites. La reducción del tamaño del búfer en uno corrige el límite superior defectuoso de la matriz pasada. Descubierto en el análisis de cobertura, CID 1600742 y CID 1600758