Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: arm_scpi: Asegurarse de que scpi_info no se asigne si la sonda falla. Cuando la sonda scpi falla, en cualquier momento, debemos asegurarnos de que scpi_info no esté configurado y permanezca nulo hasta que la sonda tenga éxito. Si no se soluciona, podría producirse un error de Use-After-Free, ya que el valor se exporta mediante get_scpi_ops() y podría hacer referencia a una memoria asignada mediante devm_kzalloc(), pero liberada cuando la sonda falla.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: no permitir que el mismo tipo rq_qos se agregue más de una vez En nuestra prueba de iocost, encontramos algunas corrupciones de lista add/del de la lista inner_walk en ioc_timer_fn. La razón puede describirse de la siguiente manera: cpu 0 cpu 1 ioc_qos_write ioc_qos_write ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ... rq_qos_add(q, rqos); } ... rq_qos_add(q, rqos); ... } Cuando dos CPU escriben el archivo io.cost.qos simultáneamente, es posible que se agregue rq_qos a un disco dos veces. En ese caso, habrá dos ioc habilitados y ejecutándose en un disco. Poseen diferentes iocgs en su lista activa. En la función ioc_timer_fn, dado que los iocgs de dos iocs tienen el mismo iocg raíz, la lista walk_list de cada iocg raíz puede sobrescribirse entre sí, lo que provoca errores al agregar o eliminar listas al crear o destruir la lista inner_walk. Hasta ahora, el framework blk-rq-qos funciona con una instancia de un tipo rq_qos por cola por defecto. Este parche lo aclara y corrige el fallo mencionado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm raid: corrección de la advertencia del depuración de direcciones en raid_resume. Se produce una advertencia de KASAN en raid_resume al ejecutar la prueba lvm lvconvert-raid.sh. La advertencia se debe a que mddev->raid_disks es mayor que rs->raid_disks, por lo que el bucle toca una entrada más allá de la longitud asignada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm raid: corrección de la advertencia del depurador de direcciones en raid_status Existe esta advertencia cuando se usa un kernel con el depurador de direcciones y se ejecuta este conjunto de pruebas: https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid ====================================================================== ERROR: KASAN: slab-out-of-bounds en raid_status+0x1747/0x2820 [dm_raid] Lectura de tamaño 4 en la dirección ffff888079d2c7e8 por la tarea lvcreate/13319 CPU: 0 PID: 13319 Comm: lvcreate No contaminado 5.18.0-0.rc3. #1 Nombre del hardware: Red Hat KVM, BIOS 0.5.1 01/01/2011 Seguimiento de llamadas: dump_stack_lvl+0x6a/0x9c print_address_description.constprop.0+0x1f/0x1e0 print_report.cold+0x55/0x244 kasan_report+0xc9/0x100 raid_status+0x1747/0x2820 [dm_raid] dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod] table_load+0x35c/0x630 [dm_mod] ctl_ioctl+0x411/0x630 [dm_mod] dm_ctl_ioctl+0xa/0x10 [dm_mod] __x64_sys_ioctl+0x12a/0x1a0 do_syscall_64+0x5b/0x80La advertencia se debe a la lectura de `conf->max_nr_stripes` en `raid_status`. El código en `raid_status` lee `mddev->private`, lo convierte a `struct r5conf` y lee la entrada `max_nr_stripes`. Sin embargo, si el tipo de raid es diferente al 4/5/6, `mddev->private` no apunta a `struct r5conf`; puede apuntar a `struct r0conf`, `struct r1conf`, `struct r10conf` o `struct mpconf`. Si convertimos un puntero a una de estas estructuras en struct r5conf, leeremos memoria no válida y KASAN emitirá una advertencia. Corrija este error leyendo struct r5conf solo si el tipo de RAID es 4, 5 o 6.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: se corrige la advertencia en ext4_iomap_begin como ejecución entre bmap y escritura Tenemos el problema siguiente: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 3 PID: 9310 en fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0 RIP: 0010:ext4_iomap_begin+0x182/0x5d0 RSP: 0018:ffff88812460fa08 EFLAGS: 00010293 RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20f R10: ffff88812c669077 R11: ffffed10258cd20e R12: 000000000000001 R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691ee FS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioctl+0x952/0xbd0 __x64_sys_ioctl+0xc6/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Above issue may happen as follows: bmap write bmap ext4_bmap iomap_bmap ext4_iomap_begin ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin ext4_prepare_inline_data ext4_create_inline_data ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_on Para resolver el problema anterior, mantenga el bloqueo del inodo en ext4_bamp.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tap: Desreferencia de puntero nulo en dev_parse_header_protocol cuando skb->dev es nulo. Corrige un error de desreferencia de puntero nulo provocado por el controlador tap. Cuando tap_get_user llama a virtio_net_hdr_to_skb, skb->dev es nulo (en tap.c, skb->dev se establece después de la llamada a virtio_net_hdr_to_skb). virtio_net_hdr_to_skb llama a dev_parse_header_protocol, que requiere que el campo skb->dev sea válido. La línea que activa el error está en dev_parse_header_protocol (dev está en el desplazamiento 0x10 desde skb y está almacenado en el registro RAX) if (!dev->header_ops || !dev->header_ops->parse_protocol) 22e1: mov 0x10(%rbx),%rax 22e5: mov 0x230(%rax),%rax Configurar skb->dev antes de la llamada en tap.c soluciona el problema. ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000230 RIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap] Código: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 00000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Rastreo de llamadas: tap_get_user+0x3f1/0x540 [tap] tap_sendmsg+0x56/0x362 [tap] ? get_tx_bufs+0xc2/0x1e0 [vhost_net] handle_tx_copy+0x114/0x670 [vhost_net] handle_tx+0xb0/0xe0 [vhost_net] handle_tx_kick+0x15/0x20 [vhost_net] vhost_worker+0x7b/0xc0 [vhost] ? vhost_vring_call_reset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4/pnfs: corrige un error de Use-After-Free en open Si alguien cancela la llamada RPC open, entonces no debemos intentar liberar ni la ranura abierta ni los argumentos de la operación layoutget, ya que es probable que aún estén en uso por la llamada RPC colgada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Verificar los límites correctos para las instancias del codificador de flujo para DCN303 [Por qué y cómo] El valor eng_id para DCN303 no puede ser mayor que 1, ya que solo tenemos dos instancias de codificadores de flujo. Verificar la condición de límite correcta para el ID del motor para DCN303 previene el posible acceso fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/eprobes: No permitir que las eprobes usen $stack o % para regs. Mientras jugaba con las sondas de eventos (eprobes), intenté ver qué sucedería si intentaba recuperar el puntero de instrucciones (%rip) sabiendo que las sondas de eventos no usan pt_regs. El resultado fue: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000024 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 1847 Comm: trace-cmd No contaminado 5.19.0-rc5-test+ #309 Nombre del hardware: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 14/07/2016 RIP: 0010:get_event_field.isra.0+0x0/0x50 Código: ff 48 c7 c7 c0 8f 74 a1 e8 3d 8b f5 ff e8 88 09 f6 ff 4c 89 e7 e8 50 6a 13 00 48 89 ef 5b 5d 41 5c 41 5d e9 42 6a 13 00 66 90 <48> 63 47 24 8b 57 2c 48 01 c6 8b 47 28 83 f8 02 74 0e 83 f8 04 74 RSP: 0018:ffff916c394bbaf0 EFLAGS: 00010086 RAX: ffff916c854041d8 RBX: ffff916c8d9fbf50 RCX: ffff916c255d2000 RDX: 0000000000000000 RSI: ffff916c255d2008 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff916c3a2a0c08 R09: ffff916c394bbda8 R10: 0000000000000000 R11: 0000000000000000 R12: ffff916c854041d8 R13: ffff916c854041b0 R14: 000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff916c9ea40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000024 CR3: 000000011b60a002 CR4: 00000000001706e0 Seguimiento de llamadas: get_eprobe_size+0xb4/0x640 ? __mod_node_page_state+0x72/0xc0 __eprobe_trace_func+0x59/0x1a0 ? __mod_lruvec_page_state+0xaa/0x1b0 ? page_remove_file_rmap+0x14/0x230 ? page_remove_rmap+0xda/0x170 event_triggers_call+0x52/0xe0 trace_event_buffer_commit+0x18f/0x240 trace_event_raw_event_sched_wakeup_template+0x7a/0xb0 try_to_wakeup+0x260/0x4c0 __wake_up_common+0x80/0x180 __wake_up_common_lock+0x7c/0xc0 do_notify_parent+0x1c9/0x2a0 exit_notify+0x1a9/0x220 do_exit+0x2ba/0x450 do_group_exit+0x2d/0x90 __x64_sys_exit_group+0x14/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Obviamente, este no es el resultado deseado. Mueva la prueba de TPARG_FL_TPOINT, que solo se usa para sondeos de eventos, al principio de la comprobación de la variable "$", ya que las demás variables no se usan para sondeos de eventos. También añada una comprobación en el registro que analiza "%" para que falle si se usa un sondeo de eventos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: apparmor: se corrige una fuga de referencias en aa_pivotroot(). La función aa_pivotroot() presenta un error de conteo de referencias en una ruta específica. Cuando aa_replace_current_label() retorna con éxito, la función olvida decrementar el conteo de referencias de "target", que se incrementa previamente mediante build_pivotroot(), lo que provoca una fuga de referencias. Para solucionarlo, reduzca el conteo de referencias de "target" en esa ruta.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Se corrige la pérdida de memoria en el cierre diferido. xfstests en smb21 informa kmemleak como se muestra a continuación: objeto sin referencia 0xffff8881767d6200 (tamaño 64): comm "xfs_io", pid 1284, jiffies 4294777434 (edad 20,789 s) volcado hexadecimal (primeros 32 bytes): 80 5a d0 11 81 88 ff ff 78 8a aa 63 81 88 ff ff .Z......x..c.... 00 71 99 76 81 88 ff ff 00 00 00 00 00 00 00 00 .qv........... backtrace: [<00000000ad04e6ea>] cifs_close+0x92/0x2c0 [<0000000028b93c82>] __fput+0xff/0x3f0 [<00000000d8116851>] task_work_run+0x85/0xc0 [<0000000027e14f9e>] do_exit+0x5e5/0x1240 [<00000000fb492b95>] do_group_exit+0x58/0xe0 [<00000000129a32d9>] __x64_sys_exit_group+0x28/0x30 [<00000000e3f7d8e9>] do_syscall_64+0x35/0x80 [<00000000102e8a0b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Cuando cancelamos el trabajo de cierre diferido, también debemos limpiar la estructura cifs_deferred_close.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/eprobes: Que las sondas de eventos sean consistentes con kprobes y uprobes. Actualmente, si se intenta usar el símbolo "@" con una sonda de eventos (eprobes), se producirá un fallo por desreferencia de puntero nulo. Tanto kprobes como uprobes pueden referenciar datos distintos a los registros principales, como la dirección inmediata, los símbolos y el nombre de la tarea actual. Que eprobes haga lo mismo. Para "comm", si se usa "comm" y el evento al que se adjunta no tiene el campo "comm", se debe usar "$comm" que tiene kprobes. Esto es consistente con el funcionamiento de los histogramas y filtros.