Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: Se corrige use-after-free en i40e_client_subtask() Actualmente la llamada a i40e_client_del_instance libera el objeto pf->cinst, sin embargo se accede a pf->cinst->lan_info después de gratis. Solucione este problema agregando la declaración que falta. Direcciones-Cobertura: ("Leer desde el puntero después de estar libre")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nftables: evitar desbordamientos en nft_hash_buckets() Número de depósitos almacenados en variables de 32 bits, debemos asegurarnos de que no se produzcan desbordamientos en nft_hash_buckets() syzbot inyectó un tamaño == 0x40000000 e informó: UBSAN: desplazamiento fuera de los límites en ./include/linux/log2.h:57:13 el exponente de desplazamiento 64 es demasiado grande para el tipo de 64 bits 'long unsigned int' CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:79 [en línea] dump_stack +0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 __roundup_pow_of_two include/linux/log2.h:57 [en línea] nft_hash_buckets net/netfilter/nft_set_hash.c:411 [en línea] nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652 nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [en línea] nf_tables_newset+0xe62 /0x3110 net/filtro de red /nf_tables_api.c:4322 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [en línea] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630 netlink_unicast_kernel net/ netlink/af_netlink.c:1312 [en línea] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [en línea] sock_sendmsg +0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_sys llamada_64+0x2d /0x70 arco/x86/entry/common.c:46

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched: corrige el acceso fuera de los límites en uclamp Util-clamp coloca las tareas en diferentes depósitos según sus valores de fijación por razones de rendimiento. Sin embargo, el tamaño de los depósitos se calcula actualmente mediante una división de redondeo, lo que puede provocar un error de uno por uno en algunas configuraciones. Por ejemplo, con 20 depósitos, el tamaño del depósito será 1024/20=51. Una tarea con una abrazadera de 1024 se asignará al ID del depósito 1024/51=20. Lamentablemente, los índices correctos están en el rango [0,19], lo que provoca un acceso a la memoria fuera de los límites. Sujete la identificación del depósito para solucionar el problema.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: can: mcp251x: corregir la reanudación desde la suspensión antes de que se activara la interfaz. Desde 8ce8c0abcba3, las colas de controladores funcionan a través de priv->restart_work cuando se reanudan después de la suspensión, incluso cuando la interfaz no estaba habilitada previamente. Esto provoca un error de desreferencia nula ya que la cola de trabajo solo se asigna e inicializa en mcp251x_open(). Para solucionar este problema, movemos el inicio de la cola de trabajo a mcp251x_can_probe() ya que no hay razón para hacerlo más tarde y repetirlo cada vez que se llama a mcp251x_open(). [mkl: corregir el manejo de errores en mcp251x_stop()]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: mcp251xfd: mcp251xfd_probe(): corrige una desreferencia de puntero de error en la sonda Cuando convertimos este código para usar dev_err_probe() eliminamos accidentalmente un retorno. Significa que si devm_clk_get() generará un Ups cuando llamemos a clk_get_rate() en la siguiente línea.

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.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nbd: corrija el puntero NULL en flush_workqueue Abra /dev/nbdX primero, config_refs será 1 y los punteros en nbd_device seguirán siendo nulos. Desconecte /dev/nbdX, luego haga referencia a un recv_workq nulo. La protección de config_refs en nbd_genl_disconnect es inútil. [656.366194] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000020 [656.368943] #PF: acceso de escritura del supervisor en modo kernel [656.369844] #PF: código_error(0x0002) - página no presente [656.370717] PGD 10cc87067 P 4D 10cc87067 PUD 1074b4067 PMD 0 [656.371693] Ups: 0002 [#1] SMP [656.372242] CPU: 5 PID: 7977 Comm: nbd-client No contaminado 5.11.0-rc5-00040-g76c057c84d28 #1 [656.373661] Nombre de hardware: PC estándar QEMU (i 440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 01/04/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 656.376627] Código: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 48 0f b1 55 d [ 656.378934 ] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 00000000000000000 RCX: 0000000000000000 [ 656.379915 ] RDX: ffff888104cf2600 RSI: fffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 00000000000000020 R08: 00000000000000000 R09: ffff88813bd6b31 8 [656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.3821 66] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0 : 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Seguimiento de llamadas : [656.385111] flux_workqueue+0x92 /0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656 .386422] genl_rcv_msg+0xfc/0x2b0 [656.386685]? nbd_ioctl+0x490/0x490 [656.386954]? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0 [ 656.387354] netlink_rcv_skb+0x62/0x180 [ 656.387638] genl_rcv+0x34/0x60 [ 656.387874] netlink_unicast+0x26d/0x590 [ 6 56.388162] netlink_sendmsg+0x398/0x6c0 [656.388451]? netlink_rcv_skb+0x180/0x180 [656.388750] ____sys_sendmsg+0x1da/0x320 [656.389038] ? ____sys_recvmsg+0x130/0x220 [ 656.389334] ___sys_sendmsg+0x8e/0xf0 [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0 [656.389889] ? handle_mm_fault+0x1671/0x21d0 [ 656.390201] __sys_sendmsg+0x6d/0xe0 [ 656.390464] __x64_sys_sendmsg+0x23/0x30 [ 656.390751] do_syscall_64+0x45/0x70 [656.391017] Entry_SYSCALL_64_after_hwframe+0x44/0xa9 Para solucionarlo, simplemente agregue if (nbd->recv_workq) a nbd_disconnect_and_put().