Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mediatek: corrige la posible desreferencia del puntero NULL en el manejo del net_device ficticio. Mueva la liberación del net_device ficticio de mtk_free_dev() a mtk_remove(). Anteriormente, si alloc_netdev_dummy() fallaba en mtk_probe(), eth->dummy_dev sería NULL. La ruta de error luego llamaría a mtk_free_dev(), que a su vez llamaría a free_netdev() suponiendo que dummy_dev estuviera asignado (pero no lo estaba), causando potencialmente una desreferencia del puntero NULL. Al mover free_netdev() a mtk_remove(), nos aseguramos de que solo se llame cuando mtk_probe() haya tenido éxito y dummy_dev esté completamente asignado. Esto soluciona una posible desreferencia de puntero NULL detectada por Smatch[1].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: mm: corrige recorridos sin bloqueo con plegado de tablas de páginas estáticas y dinámicas. Lina informa oopsen aleatorios que se originan en el código GUP rápido cuando se utilizan páginas de 16 KB con tablas de páginas de 4 niveles. el cuarto nivel se pliega en tiempo de ejecución debido a la falta de LPA2. En esta configuración, la implementación genérica de p4d_offset_lockless() devolverá un 'p4d_t *' correspondiente al 'pgd_t' asignado en la pila de la persona que llama, gup_fast_pgd_range(). Esto normalmente está bien, pero cuando el cuarto nivel de la tabla de páginas se pliega en tiempo de ejecución, pud_offset_lockless() se desplazará de la dirección de 'p4d_t' para calcular la dirección del PUD en la misma página de la tabla de páginas. Esto da como resultado una lectura de pila perdida cuando el 'p4d_t' se ha asignado en la pila y puede enviar al caminante hacia la maleza. Solucione el problema proporcionando nuestra propia definición de p4d_offset_lockless() cuando CONFIG_PGTABLE_LEVELS <= 4, que devuelve el puntero de la tabla de páginas real en lugar de la dirección de la variable de pila local.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloquear: soluciona el punto muerto entre sd_remove y sd_release Nuestra prueba informa la siguiente tarea colgada: [ 2538.459400] INFO: task "kworker/0:0":7 blocked for more than 188 seconds. [ 2538.459427] Call trace: [ 2538.459430] __switch_to+0x174/0x338 [ 2538.459436] __schedule+0x628/0x9c4 [ 2538.459442] schedule+0x7c/0xe8 [ 2538.459447] schedule_preempt_disabled+0x24/0x40 [ 2538.459453] __mutex_lock+0x3ec/0xf04 [ 2538.459456] __mutex_lock_slowpath+0x14/0x24 [ 2538.459459] mutex_lock+0x30/0xd8 [ 2538.459462] del_gendisk+0xdc/0x350 [ 2538.459466] sd_remove+0x30/0x60 [ 2538.459470] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459474] device_release_driver+0x18/0x28 [ 2538.459478] bus_remove_device+0x15c/0x174 [ 2538.459483] device_del+0x1d0/0x358 [ 2538.459488] __scsi_remove_device+0xa8/0x198 [ 2538.459493] scsi_forget_host+0x50/0x70 [ 2538.459497] scsi_remove_host+0x80/0x180 [ 2538.459502] usb_stor_disconnect+0x68/0xf4 [ 2538.459506] usb_unbind_interface+0xd4/0x280 [ 2538.459510] device_release_driver_internal+0x1c4/0x2c4 [ 2538.459514] device_release_driver+0x18/0x28 [ 2538.459518] bus_remove_device+0x15c/0x174 [ 2538.459523] device_del+0x1d0/0x358 [ 2538.459528] usb_disable_device+0x84/0x194 [ 2538.459532] usb_disconnect+0xec/0x300 [ 2538.459537] hub_event+0xb80/0x1870 [ 2538.459541] process_scheduled_works+0x248/0x4dc [ 2538.459545] worker_thread+0x244/0x334 [ 2538.459549] kthread+0x114/0x1bc [ 2538.461001] INFO: task "fsck.":15415 blocked for more than 188 seconds. [ 2538.461014] Call trace: [ 2538.461016] __switch_to+0x174/0x338 [ 2538.461021] __schedule+0x628/0x9c4 [ 2538.461025] schedule+0x7c/0xe8 [ 2538.461030] blk_queue_enter+0xc4/0x160 [ 2538.461034] blk_mq_alloc_request+0x120/0x1d4 [ 2538.461037] scsi_execute_cmd+0x7c/0x23c [ 2538.461040] ioctl_internal_command+0x5c/0x164 [ 2538.461046] scsi_set_medium_removal+0x5c/0xb0 [ 2538.461051] sd_release+0x50/0x94 [ 2538.461054] blkdev_put+0x190/0x28c [ 2538.461058] blkdev_release+0x28/0x40 [ 2538.461063] __fput+0xf8/0x2a8 [ 2538.461066] __fput_sync+0x28/0x5c [ 2538.461070] __arm64_sys_close+0x84/0xe8 [ 2538.461073] invoke_syscall+0x58/0x114 [ 2538.461078] el0_svc_common+0xac/0xe0 [ 2538.461082] do_el0_svc+0x1c/0x28 [ 2538.461087] el0_svc+0x38/0x68 [ 2538.461090] el0t_64_sync_handler+0x68/0xbc [ 2538.461093] el0t_64_sync+0x1a8/0x1ac T1: T2: sd_remove del_gendisk __blk_mark_disk_dead blk_freeze_queue_start ++q->mq_freeze_depth bdev_release mutex_lock(&disk->open_mutex) sd_release scsi_execute_cmd blk_queue_enter wait_event(!q->mq_freeze_depth) mutex_lock(&disk->open_mutex) SCSI no configura GD_OWNS_QUEUE, por lo que QUEUE_FLAG_DYING no está configurado en este escenario. Este es un clásico punto muerto de ABBA. Para solucionar el punto muerto, asegúrese de no intentar adquirir disco->open_mutex después de congelar la cola.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: soluciona un problema de segmento al degradar gso_size Lineariza el skb al degradar gso_size porque puede desencadenar un BUG_ON() más adelante cuando el skb se segmenta como se describe en [1,2].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: nexthop: inicializa todos los campos en la estructura nexthops volcada. nexthop_grp contiene dos campos reservados que no son inicializados por nla_put_nh_group() y transporta basura. Esto se puede observar, por ejemplo, con strace (editado para mayor claridad): # ip nexthop add id 1 dev lo # ip nexthop add id 101 group 1 # strace -e recvmsg ip nexthop get id 101 ... recvmsg(... [{nla_len =12, nla_type=NHA_GROUP}, [{id=1, peso=0, resvd1=0x69, resvd2=0x67}]] ...) = 52 Los campos están reservados y, por lo tanto, no se utilizan actualmente. Pero tal como están, pierden memoria del núcleo, y el hecho de que no sean simplemente cero complica la reutilización de los campos para nuevos fines. Inicialice la estructura completa.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: Devuelve un valor distinto de cero desde tipc_udp_addr2str() en caso de error tipc_udp_addr2str() debería devolver un valor distinto de cero si la dirección de medios UDP no es válida. De lo contrario, puede ocurrir un acceso de desbordamiento del búfer en tipc_media_addr_printf(). Solucione este problema devolviendo 1 en una dirección de medios UDP no válida.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/iwcm: corrige un use-after-free relacionado con la destrucción de ID de CM iw_conn_req_handler() asocia una nueva estructura rdma_id_private (conn_id) con una estructura iw_cm_id (cm_id) existente de la siguiente manera: conn_id->cm_id.iw = cm_id; cm_id->context = conn_id; cm_id->cm_handler = cma_iw_handler; rdma_destroy_id() libera tanto cm_id como struct rdma_id_private. Asegúrese de que cm_work_handler() no active un use-after-free liberando solo la estructura rdma_id_private después de que todo el trabajo pendiente haya finalizado.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: validar nvme_local_port correctamente La carga del controlador falló con mensaje de error, qla2xxx [0000:04:00.0]-ffff:0: Register_localport falló: ret=ffffffef y con un kernel bloqueo, ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en 0000000000000070 Cola de trabajo: events_unbound qla_register_fcport_fn [qla2xxx] RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc] RSP: ffffaaa040eb3d98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 00000000000000000 RDX : ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000 RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030 R10: 305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4 R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8 FS: 0000000000000000(0000 ) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0 Seguimiento de llamadas: qla_nvme_register_remote+0xeb/0x1 f0 [qla2xxx] ? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx] qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx] qla_register_fcport_fn+0x54/0xc0 [qla2xxx] Salga de la función qla_nvme_register_remote() cuando qla_nvme_register_hba () falla y valida correctamente nvme_local_port.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qla2xxx: comando completo temprano dentro del bloqueo Se observó un bloqueo al realizar el restablecimiento de NPIV y FW, ERROR: desreferencia del puntero NULL del kernel, dirección: 000000000000001c #PF: acceso de lectura del supervisor en el kernel modo #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Ups: 0000 1 PREEMPT_RT SMP NOPTI RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246 RAX: 000000000000000 RBX: 0000000000000021 RCX: 0000000000000002 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0 RBP: ffff8881041130d0 R08: 00000000000000000 R09: 0000000000000034 R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000 FS: 007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0 DR0: 000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffe0ff0 DR7: 0000000000000400 PKRU: 5555555 4 Seguimiento de llamadas: ? __die_body+0x1a/0x60 ? page_fault_oops+0x16f/0x4a0? do_user_addr_fault+0x174/0x7f0? exc_page_fault+0x69/0x1a0? asm_exc_page_fault+0x22/0x30? dma_direct_unmap_sg+0x51/0x1e0? preempt_count_sub+0x96/0xe0 qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx] qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx] __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx] La finalización del comando se realizó antes de tiempo al cancelar los comandos en la ruta de descarga del controlador pero fuera del bloqueo para evitar el WARN_ON condición de realizar dma_free_attr dentro de la cerradura. Sin embargo, esto provocó una condición de ejecución mientras el comando se completaba a través de múltiples rutas, lo que provocó un bloqueo del sistema. Por lo tanto, complete el comando temprano en la ruta de descarga pero dentro del bloqueo para evitar la condición de ejecución.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Corrección de posible corrupción de la memoria Init Control Block está desreferenciada incorrectamente. Desreferenciar correctamente ICB

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qla2xxx: durante la eliminación de vport, envíe el cierre de sesión asíncrono explícitamente. Durante la eliminación de vport, se observa que durante la descarga sufrimos un bloqueo debido a entradas obsoletas en la matriz de comandos pendientes. Para todas estas entradas de E/S obsoletas, se emitió y canceló eh_abort (fast_fail_io = 2009h), pero las E/S no se pudieron completar mientras la eliminación de vport estaba en proceso de eliminación. ERROR: desreferencia del puntero NULL del kernel, dirección: 000000000000001c #PF: acceso de lectura del supervisor en modo kernel #PF: código_error(0x0000) - página no presente PGD 0 P4D 0 Vaya: 0000 [#1] Cola de trabajo PREEMPT SMP NOPTI: qla2xxx_wq qla_do_work [ qla2xxx] RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 00000000000000000 RBX: 0000000000000021 RCX: 0000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: 10: ffff8ce378aac8a0 R11 : ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 00000000000000000 FS: 0000000000000000(0000) ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 0000000000350ee0 Seguimiento de llamadas: qla2xxx_qpair_sp_free_dma+0x417/0x4e0 ? qla2xxx_qpair_sp_compl+0x10d/0x1a0 ? qla2x00_status_entry+0x768/0x2830? newidle_balance+0x2f0/0x430? dequeue_entity+0x100/0x3c0? qla24xx_process_response_queue+0x6a1/0x19e0? __programación+0x2d5/0x1140 ? qla_do_work+0x47/0x60 ? proceso_one_work+0x267/0x440? proceso_one_work+0x440/0x440? hilo_trabajador+0x2d/0x3d0? proceso_one_work+0x440/0x440? khilo+0x156/0x180? set_kthread_struct+0x50/0x50? ret_from_fork+0x22/0x30 Envía el cierre de sesión asíncrono explícitamente para todos los puertos durante la eliminación de vport.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/imx-irqsteer: manejar correctamente la administración de energía en tiempo de ejecución. El dominio de energía se activa automáticamente desde clk_prepare(). Sin embargo, en ciertas plataformas como i.MX8QM e i.MX8QXP, el manejo de encendido invoca funciones de suspensión, lo que desencadena el error de 'programación mientras es atómico' en la ruta de cambio de contexto durante la prueba del dispositivo: ERROR: programación mientras es atómico: kworker/u13 :1/48/0x00000002 Seguimiento de llamadas: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 Schedule+0x5c/0xc4 Schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0 x20 mutex_lock+0x48/0x54 clk_prepare_lock+ 0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+ 0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0 Solucione esto implementando las devoluciones de llamada del chip de interrupción irq_bus_lock/sync_unlock() y maneje la administración de energía en ellos a medida que se invocan desde un contexto no atómico. [tglx: registro de cambios reescrito, etiqueta de correcciones agregada]