Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: corrige la deref del puntero nulo en dcn20_resource.c. Corrige un bloqueo que se activa cuando se ejecuta MPV en una dGPU DCN401: mpv --hwdec=vaapi --vo= gpu --hwdec-codecs=all y luego habilitar la reproducción en pantalla completa (haga doble clic en el video) Se verá el siguiente seguimiento de llamada: [181.843989] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000000 [181.843997] #PF: búsqueda de instrucciones del supervisor Modo del kernel [181.844003] #PF: ERROR_CODE (0x0010)- Página no presente [181.844009] PGD 0 P4D 0 [181.844020] OOPS: 0010 [ #1] PREEFT SMP NOPTI [181.84028] CPU: 6 PID: 1892 Comm: Gnome- shell contaminado: GW OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 181.844038] Nombre del hardware: Fabricante del sistema Nombre del producto del sistema/CROSSHAIR VI HERO, BIOS 6302 23/10/2018 [ 181.844044] RIP: 0010: 0x0 [181.844079] Código: No se puede acceder a los bytes del código de operación en 0xffffffffffffffd6. [ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246 [ 181.844093] RAX: 00000000000000000 RBX: 0000000000000000 RCX: 000000000000000 4 [ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400 [ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 ffffb593c2b8f96c [ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8 [ 181.844115] R13: 00000000000000001 R14: ffff9e3c88000000 R15: 000000000005 [ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:00000000000000000 [ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0 [ 181.844141] Seguimiento de llamadas: [ 181.844146] [181.844153] ? show_regs+0x6d/0x80 [181.844167]? __die+0x24/0x80 [ 181.844179] ? page_fault_oops+0x99/0x1b0 [181.844192]? do_user_addr_fault+0x31d/0x6b0 [181.844204]? exc_page_fault+0x83/0x1b0 [181.844216]? asm_exc_page_fault+0x27/0x30 [ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu] [ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu] [ 181.8 45985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu] [ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu] [181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu] [181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu] [181.849791]? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu] [ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: corrige el desbordamiento en get_free_elt() "tracing_map->next_elt" en get_free_elt() corre el riesgo de desbordarse. Una vez que se desborda, aún se pueden insertar nuevos elementos en tracing_map aunque se haya alcanzado el número máximo de elementos (`max_elts`). Continuar insertando elementos después del desbordamiento podría dar como resultado que tracing_map contenga elementos "tracing_map->max_size", sin dejar entradas vacías. Si se intenta insertar un elemento en un tracing_map completo usando `__tracing_map_insert()`, se producirá un bucle infinito con la preferencia deshabilitada, lo que provocará un problema de bloqueo de la CPU. Solucione este problema evitando incrementos adicionales en "tracing_map->next_elt" una vez que llegue a "tracing_map->max_elt".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: memcg: protege el acceso simultáneo a mem_cgroup_idr. el commit 73f576c04b94 ("mm: memcontrol: repara el error de creación de cgroup después de muchos trabajos pequeños") desacopla los ID de memcg del espacio de ID de CSS para reparar el cgroup. fracasos de la creación. Introdujo IDR para mantener el espacio de identificación de memcg. El IDR depende de mecanismos externos de sincronización para las modificaciones. Para mem_cgroup_idr, idr_alloc() e idr_replace() ocurren dentro de la devolución de llamada CSS y, por lo tanto, están protegidos a través de cgroup_mutex contra modificaciones simultáneas. Sin embargo, idr_remove() para mem_cgroup_idr no estaba protegido contra la concurrencia y se puede ejecutar simultáneamente para diferentes memcgs cuando alcanzan su referencia a cero. Arregla eso. Hemos estado viendo fallas del kernel basadas en list_lru con baja frecuencia en nuestra flota durante mucho tiempo. Estos fallos se produjeron en diferentes partes del código list_lru, incluidos list_lru_add(), list_lru_del() y el código de reparación. Tras una inspección más detallada, parecía que para un objeto determinado (dentry e inodo), el list_lru del super_block no tenía list_lru_one para el memcg de ese objeto. Las sospechas iniciales fueron que el objeto no estaba asignado a través de kmem_cache_alloc_lru() o de alguna manera memcg_list_lru_alloc() no pudo asignar list_lru_one() para un memcg pero devolvió el éxito. No se encontraron pruebas de estos casos. Mirando más profundamente, comenzamos a ver situaciones en las que la identificación de memcg válida no está presente en mem_cgroup_idr y, en algunos casos, varios memcg válidos tienen la misma identificación y mem_cgroup_idr apunta a uno de ellos. Entonces, la explicación más razonable es que estas situaciones pueden ocurrir debido a la ejecución entre múltiples llamadas idr_remove() o la ejecución entre idr_alloc()/idr_replace() e idr_remove(). Estas ejecuciones están provocando que varios memcgs adquieran el mismo ID y luego desconectar uno de ellos limpiaría list_lrus en el sistema para todos ellos. El acceso posterior desde otros memcgs a list_lru provoca bloqueos debido a que falta list_lru_one.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: core: verifique uartclk en busca de cero para evitar la división por cero. Llamar a ioctl TIOCSSERIAL con un baud_base no válido puede resultar en que uartclk sea cero, lo que resultará en un error de división por cero en uart_get_divisor (). La verificación de que uartclk sea cero en uart_set_info() debe realizarse antes de realizar otras configuraciones, ya que las llamadas posteriores a ioctl TIOCSSERIAL para el mismo puerto se verían afectadas si la verificación de uartclk se realizó donde se establece uartclk. Vaya: error de división: 0000 PREEMPT SMP KASAN PTI RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580) Seguimiento de llamadas: serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576 drivers /tty/serial/8250/8250_port.c:2589) serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502 drivers/tty/serial/8250/8250_port.c:2741) serial8250_set_termios (drivers/tty/serial/ 8250/8250_port.c:2862) uart_change_line_settings (./include/linux/spinlock.h:376 ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222) uart_port_startup (drivers/tty/ serial/serial_core.c:342) uart_startup (drivers/tty/serial/serial_core.c:368) uart_set_info (drivers/tty/serial/serial_core.c:1034) uart_set_info_user (drivers/tty/serial/serial_core.c:1059) tty_set_serial (drivers/tty/tty_io.c:2637) tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791) __x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907 fs /ioctl.c:893 fs/ioctl.c:893) do_syscall_64 (arch/x86/entry/common.c:52 (discriminador 1) arch/x86/entry/common.c:83 (discriminador 1)) Entry_SYSCALL_64_after_hwframe (arch /x86/entry/entry_64.S:130) Regla: agregar

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/client: corrige la desreferencia del puntero nulo en drm_client_modeset_probe En drm_client_modeset_probe(), el valor de retorno de drm_mode_duplicate() se asigna a modeset->mode, lo que conducirá a un posible puntero NULL desreferencia en caso de falla de drm_mode_duplicate(). Agregue una marca para evitar npd.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: elimine gso csum_start incorrecto y offset en virtio_net_hdr. Apriete las comprobaciones de csum_start y csum_offset en virtio_net_hdr_to_skb para paquetes GSO. La función ya comprueba que una suma de comprobación solicitada con VIRTIO_NET_HDR_F_NEEDS_CSUM esté en skb lineal. Pero para los paquetes OSG esto podría no ser válido para los segmentos posteriores a la segmentación. Syzkaller demostró alcanzar esta advertencia en skb_checksum_help offset = skb_checksum_start_offset(skb); ret = -EINVAL; if (WARN_ON_ONCE(offset >= skb_headlen(skb))) Al inyectar un paquete TSO: ADVERTENCIA: CPU: 1 PID: 3539 en net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0 ip_do_fragment+0x209/0x1b20 net/ipv4 /ip_output.c:774 ip_finish_output_gso net/ipv4/ip_output.c:279 [en línea] __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301 iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82 +0x2296 /0x2c70 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [en línea] ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4850 [en línea ] netdev_start_xmit include/linux/netdevice.h:4864 [en línea] xmit_one net/core/dev.c:3595 [en línea] dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611 __dev_queue_xmit+0x1b97/0x3c90 net/core/ dev.c:4261 paquete_snd net/packet/af_packet.c:3073 [en línea] La geometría del paquete de entrada incorrecto en tcp_gso_segment: [ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [ 52.003050] [ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244 [ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(tamaño=1552 tipo=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ip_summed=3 complete_sw=0 valid=0 nivel=0) Mitigar con una validación de entrada más estricta. csum_offset: para paquetes GSO, deduzca el valor correcto de gso_type. Esto ya está hecho para la OSU. Ampliarlo a TSO. Sea UFO: udp[46]_ufo_fragment ignora estos campos y siempre calcula la suma de comprobación en el software. csum_start: encontrar el desplazamiento real requiere analizar el encabezado de transporte. No agregue un analizador, utilice el análisis de segmentación existente. Gracias a SKB_GSO_DODGY, eso también detecta paquetes defectuosos que se descargan correctamente. Nuevamente pruebe tanto TSO como USO. No pruebe UFO por el motivo anterior y no pruebe la descarga del túnel UDP. Los paquetes OSG casi siempre son CHECKSUM_PARTIAL. Los paquetes USO pueden ser CHECKSUM_NONE desde el commit 10154dbded6d6 ("udp: Permitir transmisión GSO desde dispositivos sin descarga de suma de verificación"), pero aún así estos campos se inicializan correctamente en udp4_hwcsum/udp6_hwcsum_outgoing. Por lo tanto, no es necesario probar primero ip_summed == CHECKSUM_PARTIAL. Esto revisa una solución existente mencionada en la etiqueta Correcciones, que rompía paquetes pequeños con la descarga GSO, según lo detectado por kselftests.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: medio: xc2028: evitar el use-after-free en load_firmware_cb() syzkaller informó el use-after-free en load_firmware_cb() [1]. La razón es que el módulo asignó un sintonizador de estructuras en tuner_probe(), y luego la inicialización del módulo falló, se liberó el sintonizador de estructuras. Un trabajador que creó durante la inicialización del módulo accede a este sintonizador de estructuras más tarde, lo que provocó un use-after-free. El proceso es el siguiente: task-6504 trabajador_thread tuner_probe <= alloc dvb_frontend [2]... request_firmware_nowait <= crear un trabajador... tuner_remove <= free dvb_frontend... request_firmware_work_func <= el firmware está listo load_firmware_cb <= pero ahora el dvb_frontend ha sido liberado. Para solucionar el problema, verifique el dvd_frontend en load_firmware_cb(), si es nulo, informe una advertencia y simplemente regrese. [1]: =============================================== ==================== ERROR: KASAN: use-after-free en load_firmware_cb+0x1310/0x17a0 Lectura de tamaño 8 en la dirección ffff8000d7ca2308 por tarea kworker/2:3/ 6504 Rastreo de llamadas: load_firmware_cb+0x1310/0x17a0 request_firmware_work_func+0x128/0x220 Process_one_work+0x770/0x1824 Workers_thread+0x488/0xea0 kthread+0x300/0x430 ret_from_fork+0x10/0x20 Asignado por tarea 650 4: kzalloc tuner_probe+0xb0/0x1430 i2c_device_probe+0x92c/0xaf0 very_probe+0x678/0xcd0 driver_probe_device+0x280/0x370 __device_attach_driver+0x220/0x330 bus_for_each_drv+0x134/0x1c0 __device_attach+0x1f4/0x410 dispositivo_initial_probe+0x20/0x30 bus_probe_device+0x 184/0x200 dispositivo_add+0x924/0x12c0 registro_dispositivo+0x24/0x30 i2c_new_device+0x4e0/0xc44 v4l2_i2c_new_subdev_board+0xbc/0x290 v4l2_i2c_new_subdev+0xc8/0x104 em28xx_v4l2_init+0x1dd0/0x3770 Liberado por la tarea 6504: kfree+0x238/0x4e4 tuner_remove+0x144/0x1c0 vice_remove+0xc8/0x290 __device_release_driver+0x314/0x5fc dispositivo_release_driver+0x30/0x44 bus_remove_device+0x244/0x490 device_del+0x350/0x900 device_unregister+0x28/0xd0 i2c_unregister_device+0x174/0x1d0 v4l2_device_unregister+0x224/0x380 em28xx_v4l2_init+0x1d90/0x3770 La dirección con errores pertenece al objeto en ffff8000d7ca200 0 que pertenece al caché kmalloc-2k de tamaño 2048 La dirección del error se encuentra 776 bytes dentro de la región de 2048 bytes [ffff8000d7ca2000, ffff8000d7ca2800) La dirección con errores pertenece a la página: página:ffff7fe00035f280 recuento:1 mapcount:0 mapeo:ffff8000c001f000 índice:0x0 banderas: 0x7ff800000000100(slab) : 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000 crudo: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 página volcada porque: kasan: mal acceso detectado Estado de la memoria alrededor de la dirección del error: ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb f b fb fb fb ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2400: b fb fb fb fb fb fb fb fb fb fb fb fb fb fb ======================================== ============================ [2] En realidad, está asignado para el sintonizador de estructuras y dvb_frontend está dentro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: agrega un verificador nulo antes de pasar variables Comprueba el puntero nulo antes de pasar variables a funciones. Esto soluciona 3 problemas NULL_RETURNS informados por Coverity.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: agregue comprobaciones nulas para 'stream' y 'plane' antes de eliminar la referencia. Esta confirmación agrega comprobaciones nulas para las variables 'stream' y 'plane' en la función dcn30_apply_idle_power_optimizations . Anteriormente se suponía que estas variables eran nulas en la línea 922, pero se usaron más adelante en el código sin verificar si eran nulas. Potencialmente, esto podría provocar una desreferencia del puntero nulo, lo que provocaría un bloqueo. Las comprobaciones nulas garantizan que 'stream' y 'plane' no sean nulos antes de su uso, evitando posibles accidentes. Corrige el siguiente verificador de coincidencia estática: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:938 Error de dcn30_apply_idle_power_optimizations(): previamente asumimos que 'stream' podría ser nulo (ver línea 922) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:940 Error de dcn30_apply_idle_power_optimizations(): anteriormente asumimos que 'avión' podría ser nulo (consulte la línea 922)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: corrige la desreferencia del puntero nulo para vega10_hwmgr. Verifique el valor de retorno y realice el manejo del puntero nulo para evitar la desreferencia del puntero nulo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: corrige el doble desbloqueo de inodo para escrituras de sincronización de IO directa. Si realizamos una escritura de sincronización de IO directa, en btrfs_sync_file(), y necesitamos omitir el registro de inodo o obtendremos un error al iniciar una transacción o un error al vaciar delalloc, terminamos desbloqueando el inodo cuando no deberíamos bajo la etiqueta 'out_release_extents', y luego lo desbloqueamos nuevamente en btrfs_direct_write(). Solucione eso verificando si tenemos que omitir el desbloqueo de inodos debajo de esa etiqueta.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: agregar verificación nula en Resource_log_pipe_topology_update [POR QUÉ] Al cambiar de "Extender" a "Sólo segunda visualización", a veces llamamos a Resource_get_otg_master_for_stream en una secuencia para eDP, lo que está desconectado. Esto conduce a una desreferencia del puntero nulo. [CÓMO] Se agregó una verificación nula en dc_resource.c/resource_log_pipe_topology_update.