Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: act_ct: corrige el acceso salvaje a la memoria al borrar fragmentos mientras se prueba el reensamblaje/refragmentación usando act_ct, es posible observar un bloqueo como el siguiente: KASAN: tal vez acceso a memoria salvaje en el rango [0x0001000000000448-0x000100000000044f] CPU: 50 PID: 0 Comunicaciones: swapper/50 Tainted: GS 5.12.0-rc7+ #424 Nombre de hardware: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01 /17/2017 RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0 Código: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48 RSP: 0018:ffff888c31449db8 EFLAGS: 00010203 RAX: 00 00200000000089 RBX: 000100000000040e RCX: ffffffff989eb960 RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e RBP: 0000000000000900 R08: 00000000000000000 R09: ffffed1186289350 R10: 00000000 00000003 R11: ffffed1186289350 R12: dffffc0000000000 R13: 000100000000040e R14: 00000000000000000 R15: ffff888155e02160 FS: 00000000000000000 (0000) GS:ffff888c31440000(0000) knlGS:0000000000000000 CS : 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0 000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000000400 Seguimiento de llamadas: inet_frag_destroy+0xa9/0x150 call_timer_fn +0x2d/0x180 run_timer_softirq+0x4fe/0xe70 __do_softirq+0x197/0x5a0 irq_exit_rcu+0x1de/0x200 sysvec_apic_timer_interrupt+0x6b/0x80 cuando act_ct almacena temporalmente un fragmento de IP, la restauración de skb qdisc cb da como resultado la colocación de datos aleatorios en FR AG_CB() , y esto provoca esos accesos a la memoria "salvajes" más adelante, cuando se purga el rbtree. Nunca sobrescriba el skb cb en caso de que tcf_ct_handle_fragments() devuelva -EINPROGRESS.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bnxt_en: corrige la lógica del índice del consumidor RX en la ruta del error. En bnxt_rx_pkt(), se espera que los buffers RX se completen en orden. Si el índice del consumidor RX indica que el búfer está fuera de servicio, significa que estamos sufriendo un error de hardware y el controlador cancelará todos los paquetes RX restantes y restablecerá el anillo RX. El índice de consumidores RX que pasamos a bnxt_discard_rx() no es correcto. Deberíamos pasar el índice actual (tmp_raw_cons) en lugar del índice anterior (raw_cons). Este error puede hacer que estemos en el índice incorrecto al intentar abortar el siguiente paquete RX. Puede fallar así: #0 [ffff9bbcdf5c39a8] machine_kexec en ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec en ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] pánico en ffffffff9b07d61e #3 [ffff9bbcdf5c3b50 ] oops_end en ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context en ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8 ] __bad_area_nosemaphore en ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore en ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault en ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault en ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault en ffffffff9bc015c5 [excepción RIP: bnxt_rx_pkt+237] RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000000100 0 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath10k: corrige un use after free en ath10k_htc_send_bundle En ath10k_htc_send_bundle, el paquete_skb podría ser liberado por dev_kfree_skb_any(bundle_skb). Pero el paquete_skb lo utiliza más tarde el paquete_skb->len. Como skb_len = bundle_skb->len, mi parche reemplaza bundle_skb->len por skb_len después de que se liberó el paquete_skb.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nftables: corrige una fuga de memoria de la ruta de error de los datos del usuario en objetos nuevos. Libera el nombre del objeto si falla la asignación de los datos del usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: entrada: configure siempre GIC_PRIO_PSR_I_SET durante la entrada Zenghui informa que al iniciar un kernel con "irqchip.gicv3_pseudo_nmi=1" en la línea de comando aparece una advertencia durante la entrada del kernel, debido a la forma manipulamos el PMR. Al principio de la secuencia de entrada, llamamos a lockdep_hardirqs_off() para informar a lockdep que las interrupciones han sido enmascaradas (ya que el HW configura DAIF cuando ingresa una excepción). Desde el punto de vista arquitectónico, PMR_EL1 no se ve afectado por la entrada de excepción y no configuramos GIC_PRIO_PSR_I_SET en el PMR al principio de la secuencia de entrada de excepción, por lo que al principio de la entrada de excepción el PMR puede indicar que las interrupciones están desenmascaradas aunque estén enmascaradas por DAIF. Si se selecciona DEBUG_LOCKDEP, lockdep_hardirqs_off() verificará que las interrupciones estén enmascaradas, antes de configurar GIC_PRIO_PSR_I_SET en cualquiera de las rutas de entrada de excepción y, por lo tanto, lockdep_hardirqs_off() ADVERTENCIA() que algo anda mal. Podemos evitar esto configurando consistentemente GIC_PRIO_PSR_I_SET durante la entrada de excepciones para que el código del kernel vea un entorno consistente. También debemos actualizar local_daif_inherit() para deshacer esto, ya que actualmente solo toca DAIF. Para otras rutas, local_daif_restore() actualizará tanto DAIF como PMR. Una vez hecho esto, podemos eliminar los casos especiales existentes que configuran esto más adelante en el código de entrada. Siempre usamos (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) para mantener la coherencia con local_daif_save(), ya que esto avisará si alguna vez encuentra (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), y nunca lo configura por sí mismo. Esto coincide con gic_prio_kentry_setup que debemos conservar para ret_to_user. El símbolo original del informe de Zenghui fue: | DEBUG_LOCKS_WARN_ON(!irqs_disabled()) | ADVERTENCIA: CPU: 3 PID: 125 en kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8 | Módulos enlazados en: | CPU: 3 PID: 125 Comunicaciones: modprobe Contaminado: GW 5.12.0-rc8+ #463 | Nombre del hardware: Máquina virtual QEMU KVM, BIOS 0.0.0 06/02/2015 | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--) | ordenador personal: lockdep_hardirqs_off+0xd4/0xe8 | lr: lockdep_hardirqs_off+0xd4/0xe8 | sp: ffff80002a39bad0 | pmr_save: 000000e0 | x29: ffff80002a39bad0 x28: ffff0000de214bc0 | x27: ffff0000de1c0400 x26: 000000000049b328 | x25: 0000000000406f30 x24: ffff0000de1c00a0 | x23: 0000000020400005 x22: ffff8000105f747c | x21: 0000000096000044 x20: 0000000000498ef9 | x19: ffff80002a39bc88 x18: ffffffffffffffff | x17: 0000000000000000 x16: ffff800011c61eb0 | x15: ffff800011700a88 x14: 0720072007200720 | x13: 0720072007200720 x12: 0720072007200720 | x11: 0720072007200720 x10: 0720072007200720 | x9: ffff80002a39bad0 x8: ffff80002a39bad0 | x7: ffff8000119f0800 x6: c0000000ffff7fff | x5: ffff8000119f07a8 x4: 0000000000000001 | x3: 9bcdab23f2432800 x2: ffff800011730538 | x1: 9bcdab23f2432800 x0: 0000000000000000 | Rastreo de llamadas: | lockdep_hardirqs_off+0xd4/0xe8 | enter_from_kernel_mode.isra.5+0x7c/0xa8 | el1_abort+0x24/0x100 | el1_sync_handler+0x80/0xd0 | el1_sync+0x6c/0x100 | __arch_clear_user+0xc/0x90 | load_elf_binary+0x9fc/0x1450 | bprm_execve+0x404/0x880 | kernel_execve+0x180/0x188 | call_usermodehelper_exec_async+0xdc/0x158 | ret_from_fork+0x10/0x18

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ethernet:enic: corrige un error de use after free en enic_hard_start_xmit. En enic_hard_start_xmit, llama a enic_queue_wq_skb(). Dentro de enic_queue_wq_skb, si ocurre algún error, dev_kfree_skb(skb) liberará el skb. Pero el skb liberado todavía se usa en skb_tx_timestamp(skb). Mi parche hace que enic_queue_wq_skb() devuelva un error y vaya a spin_unlock() en caso de error. La solución la proporciona Govind. Consulte https://lkml.org/lkml/2021/4/30/961.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: aspeed: corrige la lógica de manejo del reloj El motor de video usa eclk y vclk para sus fuentes de reloj y su control de reinicio está acoplado con eclk para que la secuencia de habilitación del reloj actual funcione como se muestra a continuación. Habilitar eclk De-assert Video Engine restablece un retraso de 10 ms Habilitar vclk Introduce un reinicio incorrecto en el hardware de Video Engine y eventualmente el hardware genera transferencias de memoria DMA inesperadas que pueden dañar la región de la memoria en patrones aleatorios y esporádicos. Este problema se observa muy raramente en algunos SoC AST2500 específicos, pero provoca un pánico crítico en el kernel al crear varias formas de firma, por lo que es extremadamente difícil de depurar. Además, el problema se observa incluso cuando el motor de vídeo no se utiliza activamente porque udevd enciende el hardware del motor de vídeo durante un breve periodo de tiempo para realizar una consulta en cada arranque. Para solucionar este problema, esta confirmación cambia la lógica de manejo del reloj para activar la anulación de reinicio después de habilitar tanto eclk como vclk. Además, agrega la llamada clk_unprepare para un caso en el que falla la sonda. clk: ast2600: corrige la configuración de restablecimiento para eclk y vclk La configuración de restablecimiento del motor de video debe combinarse con eclk para que coincida con la configuración de los SoC Aspeed anteriores que se define en clk-aspeed.c, ya que todos los SoC Aspeed comparten un único controlador de motor de video. Además, el bit de reinicio 6 se define como reinicio del 'Motor de video' en la hoja de datos, por lo que debe desactivarse cuando eclk está habilitado. Este commit corrige la configuración.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915: soluciona el fallo en auto_retire La lógica de retiro utiliza los 2 bits inferiores del puntero a la función de retiro para almacenar indicadores. Sin embargo, no se garantiza que la función auto_retire esté alineada con un múltiplo de 4, lo que provoca fallas cuando saltamos a la dirección incorrecta, por ejemplo así: 2021-04-24T18:03:53.804300Z WARNING kernel: [ 516.876901] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI 2021-04-24T18:03:53.804310Z WARNING kernel: [ 516.876906] CPU: 7 PID: 146 Comm: kworker/u16:6 Tainted: G U 5.4.105-13595-g3cd84167b2df #1 2021-04-24T18:03:53.804311Z WARNING kernel: [ 516.876907] Hardware name: Google Volteer2/Volteer2, BIOS Google_Volteer2.13672.76.0 02/22/2021 2021-04-24T18:03:53.804312Z WARNING kernel: [ 516.876911] Workqueue: events_unbound active_work 2021-04-24T18:03:53.804313Z WARNING kernel: [ 516.876914] RIP: 0010:auto_retire+0x1/0x20 2021-04-24T18:03:53.804314Z WARNING kernel: [ 516.876916] Code: e8 01 f2 ff ff eb 02 31 db 48 89 d8 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 f0 ff 87 c8 00 00 00 0f 88 ab 47 4a 00 31 c0 5d c3 0f <1f> 44 00 00 55 48 89 e5 f0 ff 8f c8 00 00 00 0f 88 9a 47 4a 00 74 2021-04-24T18:03:53.804319Z WARNING kernel: [ 516.876918] RSP: 0018:ffff9b4d809fbe38 EFLAGS: 00010286 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876919] RAX: 0000000000000007 RBX: ffff927915079600 RCX: 0000000000000007 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876921] RDX: ffff9b4d809fbe40 RSI: 0000000000000286 RDI: ffff927915079600 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876922] RBP: ffff9b4d809fbe68 R08: 8080808080808080 R09: fefefefefefefeff 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876924] R10: 0000000000000010 R11: ffffffff92e44bd8 R12: ffff9279150796a0 2021-04-24T18:03:53.804322Z WARNING kernel: [ 516.876925] R13: ffff92791c368180 R14: ffff927915079640 R15: 000000001c867605 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876926] FS: 0000000000000000(0000) GS:ffff92791ffc0000(0000) knlGS:0000000000000000 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876928] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2021-04-24T18:03:53.804324Z WARNING kernel: [ 516.876929] CR2: 0000239514955000 CR3: 00000007f82da001 CR4: 0000000000760ee0 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876930] PKRU: 55555554 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876931] Call Trace: 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876935] __active_retire+0x77/0xcf 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876939] process_one_work+0x1da/0x394 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876941] worker_thread+0x216/0x375 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876944] kthread+0x147/0x156 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876946] ? pr_cont_work+0x58/0x58 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876948] ? kthread_blkcg+0x2e/0x2e 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876950] ret_from_fork+0x1f/0x40 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876952] Modules linked in: cdc_mbim cdc_ncm cdc_wdm xt_cgroup rfcomm cmac algif_hash algif_skcipher af_alg xt_MASQUERADE uinput snd_soc_rt5682_sdw snd_soc_rt5682 snd_soc_max98373_sdw snd_soc_max98373 snd_soc_rl6231 regmap_sdw snd_soc_sof_sdw snd_soc_hdac_hdmi snd_soc_dmic snd_hda_codec_hdmi snd_sof_pci snd_sof_intel_hda_common intel_ipu6_psys snd_sof_xtensa_dsp soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof snd_soc_hdac_hda snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core soundwire_bus snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core intel_ipu6_isys videobuf2_dma_contig videobuf2_v4l2 videobuf2_common videobuf2_memops mei_hdcp intel_ipu6 ov2740 ov8856 at24 sx9310 dw9768 v4l2_fwnode cros_ec_typec intel_pmc_mux roles acpi_als typec fuse iio_trig_sysfs cros_ec_light_prox cros_ec_lid_angle cros_ec_sensors cros

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: VMX: deshabilite la preferencia al sondear los MSR devueltos por el usuario. Deshabilite la preferencia al sondear el MSR devuelto por un usuario a través de RDSMR/WRMSR. Si MSR tiene un valor diferente por CPU lógica, WRMSR podría dañar el valor del host si KVM se adelanta entre RDMSR y WRMSR y luego se reprograma en una CPU diferente. De manera oportunista, coloque el asistente en x86 común, SVM usará el asistente en una confirmación futura.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: nVMX: siempre intente asignar eVMCS después de la migración Cuando se utiliza VMCS iluminado y el estado anidado se migra con vmx_get_nested_state()/vmx_set_nested_state() KVM no puede asignar evmcs página de inmediato: evmcs gpa no es 'struct kvm_vmx_nested_state_hdr' y no podemos leerlo desde la página de asistencia de VP porque el espacio de usuario puede decidir restaurar HV_X64_MSR_VP_ASSIST_PAGE después de restaurar el estado anidado (y QEMU, por ejemplo, hace exactamente eso). Para asegurarse de que eVMCS esté asignado, /vmx_set_nested_state() genera la solicitud KVM_REQ_GET_NESTED_STATE_PAGES. el commit f2c7ef3ba955 ("KVM: nSVM: cancelar KVM_REQ_GET_NESTED_STATE_PAGES en vmexit anidado") agregó la limpieza KVM_REQ_GET_NESTED_STATE_PAGES a nested_vmx_vmexit() para asegurarse de que el mapa de bits del permiso MSR no se cambie cuando ocurre una salida inmediata de L2 a L1 justo después de la migración (causada por un evento pendiente, Por ejemplo). Desafortunadamente, en exactamente la misma situación todavía necesitamos tener eVMCS mapeado para que nested_sync_vmcs12_to_shadow() refleje los cambios en VMCS12 a eVMCS. Como curita, restaure nested_get_evmcs_page() al borrar KVM_REQ_GET_NESTED_STATE_PAGES en nested_vmx_vmexit(). La "solución" está lejos de ser ideal, ya que no podemos propagar fácilmente posibles fallas e incluso si pudiéramos, lo más probable es que ya sea demasiado tarde para hacerlo. Toda la idea 'KVM_REQ_GET_NESTED_STATE_PAGES' para mapear eVMCS después de la migración parece ser frágil ya que nos desviamos demasiado de la ruta 'nativa' cuando la carga de vmptr ocurre en vmx_set_nested_state().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: core: arreglar la eliminación de los controladores ioctl Actualmente, los controladores ioctl se eliminan dos veces. Por primera vez durante iio_device_unregister() y luego dentro de iio_device_unregister_eventset() y iio_buffers_free_sysfs_and_mask(). La doble liberación conduce al pánico en el kernel. Para solucionar este problema, no toque directamente la lista de controladores ioctl, sino que permita que el código responsable del registro llame a la rutina de limpieza coincidente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: ucsi: recupera todos los PDO en lugar de solo los primeros 4 commits 4dbc6a4ef06d ("usb: typec: ucsi: guarda objetos de datos de energía en modo PD") introdujo la recuperación de los PDO cuando se conectan a una fuente compatible con PD. Pero solo se reciben los primeros 4 PDO, ya que ese es el número máximo que se puede recuperar a la vez dada la limitación de longitud de MESSAGE_IN (16 bytes). Sin embargo, según las especificaciones de PD, una fuente conectada puede anunciar hasta un máximo de 7 PDO. Si dicha fuente está conectada, es posible que el PPM haya negociado un contrato de energía con uno de los PDO con un índice mayor que 4, y se reflejaría en el campo de posición del objeto del objeto de datos de solicitud (RDO). Esto daría como resultado un acceso fuera de los límites cuando se usa rdo_index() para indexar en la matriz src_pdos en ucsi_psy_get_voltage_now(). Con la ayuda del verificador UBSAN -fsanitize=array-bounds habilitado, este problema exacto se revela cuando se conecta a un adaptador de fuente PD que anuncia 5 PDO y el PPM firma un contrato después de seleccionar el quinto. [ 151.545106][ T70] Excepción inesperada de BRK del kernel en EL1 [ 151.545112][ T70] Error interno: controlador BRK: f2005512 [#1] SMP PREEMPT ... [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507 ] [ T70] lr : power_supply_show_property+0xc0/0x328 ... [ 151.545542][ T70] Rastreo de llamadas: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x 2f0 [151.545550][T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] Process_one_work+0x244/0 x6f0 [ 151.545564][ T70] work_thread+0x3e0/0xa64 Nosotros Puede resolver esto recuperando y almacenando hasta un máximo de 7 PDO en la matriz con->src_pdos. Esto implicaría dos llamadas al comando GET_PDOS.