Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: locking/csd_lock: Cambiar csdlock_debug de early_param a __setup El parámetro csdlock_debug kernel-boot es analizado por la función early_param() csdlock_debug(). Si se establece, csdlock_debug() invoca static_branch_enable() para habilitar la función csd_lock_wait, que desencadena un pánico en arm64 para kernels compilados con CONFIG_SPARSEMEM=y y CONFIG_SPARSEMEM_VMEMMAP=n. Con CONFIG_SPARSEMEM_VMEMMAP=n, se llama a __nr_to_section en static_key_enable() y devuelve NULL, lo que resulta en una desreferencia NULL porque mem_section se inicializa solo más tarde en sparse_init(). Esto también representa un problema para PowerPC, ya que las funciones early_param() se invocan antes que jump_label_init(), lo que también provoca fallos en static_key_enable(). Estos fallos generan la advertencia "Clave estática 'xxx' usada antes de la llamada a jump_label_init()". Por lo tanto, early_param es demasiado pronto para que csd_lock_wait ejecute static_branch_enable(), por lo que se cambia a __setup para solucionarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm thin: corrección del fallo de uso tras liberación en dm_sm_register_threshold_callback Se informa de un fallo por inyección en el dispositivo de metadatos del grupo: ERROR: KASAN: uso tras liberación en dm_pool_register_metadata_threshold+0x40/0x80 Lectura de tamaño 8 en la dirección ffff8881b9d50068 por la tarea dmsetup/950 CPU: 7 PID: 950 Comm: dmsetup Contaminado: GW 5.19.0-rc6 #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x34/0x44 print_address_description.constprop.0.cold+0xeb/0x3f4 kasan_report.cold+0xe6/0x147 dm_pool_register_metadata_threshold+0x40/0x80 pool_ctr+0xa0a/0x1150 dm_table_add_target+0x2c8/0x640 table_load+0x1fd/0x430 ctl_ioctl+0x2c4/0x5a0 dm_ctl_ioctl+0xa/0x10 __x64_sys_ioctl+0xb3/0xd0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Esto se puede reproducir fácilmente usando: echo offline > /sys/block/sda/device/state dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10 dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0" Si falla una confirmación de metadatos, la transacción se cancelará y los mapas de espacio de metadatos se destruirán. Si se recarga la tabla DM para este thin-pool fallido, se ejecutará un "use after-free" en dm_sm_register_threshold_callback (llamado desde dm_pool_register_metadata_threshold). Solucione esto en dm_pool_register_metadata_threshold() devolviendo el error -EINVAL si el thin-pool está en modo de fallo. También se produce un error en pool_ctr() con un nuevo mensaje de error: "Error al registrar el umbral de metadatos".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: evitar acceso no válido a memoria mediante node_online(NUMA_NO_NODE) KASAN informa: [ 4.668325][ T0] ERROR: KASAN: acceso a memoria salvaje en dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) [ 4.676149][ T0] Lectura de tamaño 8 en la dirección 1fffffff85115558 por el intercambiador de tareas/0/0 [ 4.683454][ T0] [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 No contaminado 5.19.0-rc3-00004-g0e862838f290 #1 [ 4.694331][ T0] Nombre del hardware: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 02/03/2016 [ 4.703196][ T0] Rastreo de llamadas: [ 4.706334][ T0] [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) después de convertir el tipo del primer argumento (@nr, número de bit) de arch_test_bit() de `long` a `unsigned long`[0]. Bajo ciertas condiciones (por ejemplo, cuando ACPI NUMA está deshabilitado a través de la línea de comandos), pxm_to_node() puede devolver %NUMA_NO_NODE (-1). Es un número 'mágico' válido de nodo NUMA, pero no un número de bit válido para usar en bitops. node_online() finalmente desciende a test_bit() sin verificar la entrada, asumiendo que está del lado del llamador (lo cual podría ser útil para tareas críticas para el rendimiento). Allí, -1 se convierte en %ULONG_MAX, lo que genera un índice de matriz desproporcionado al calcular la posición del bit en memoria. Por ahora, agregue una verificación explícita de que @node no sea %NUMA_NO_NODE antes de llamar a test_bit(). La lógica real no cambió en absoluto. [0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spmi: trace: se corrige el acceso fuera de los límites de la pila en las funciones de seguimiento de SPMI. Las funciones trace_spmi_write_begin() y trace_spmi_read_end() llaman a memcpy() con una longitud de "len + 1". Esto provoca la lectura de un byte adicional más allá del final del búfer especificado. Corrija este acceso fuera de los límites de la pila utilizando una longitud de "len". Aquí hay un registro de KASAN que muestra el problema: ERROR: KASAN: pila fuera de los límites en trace_event_raw_event_spmi_read_end+0x1d0/0x234 Lectura de tamaño 2 en la dirección ffffffc0265b7540 por la tarea thermal@2.0-ser/1314 ... Seguimiento de llamadas: dump_backtrace+0x0/0x3e8 show_stack+0x2c/0x3c dump_stack_lvl+0xdc/0x11c print_address_description+0x74/0x384 kasan_report+0x188/0x268 kasan_check_range+0x270/0x2b0 memcpy+0x90/0xe8 trace_event_raw_event_spmi_read_end+0x1d0/0x234 spmi_read_cmd+0x294/0x3ac spmi_ext_register_readl+0x84/0x9c regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi] _regmap_raw_read+0x40c/0x754 regmap_raw_read+0x3a0/0x514 regmap_bulk_read+0x418/0x494 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3] ... __arm64_sys_read+0x4c/0x60 invoke_syscall+0x80/0x218 el0_svc_common+0xec/0x1c8 ... la dirección ffffffc0265b7540 se encuentra en la pila de tareas thermal@2.0-ser/1314 en el desplazamiento 32 en el marco: adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3] este marco tiene 1 objeto: [32, 33) 'status' Estado de la memoria alrededor de la dirección con errores: ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 fffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >fffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00 ^ ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00 ====================================================================

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: posix-cpu-timers: Limpiar los temporizadores de CPU antes de liberarlos durante la ejecución. el commit 55e8c8eb2c7b ("posix-cpu-timers: Almacenar una referencia a un PID, no a una tarea") comenzó a buscar tareas por PID al eliminar un temporizador de CPU. Cuando un subproceso no líder llama a execve, intercambia los PID con el proceso líder. Luego, al llamar a exit_itimers, posix_cpu_timer_del no puede encontrar la tarea porque el temporizador aún apunta al PID anterior. Esto significa que los temporizadores armados no se desarmarán; es decir, no se eliminarán de timerqueue_list. exit_itimers liberará su memoria y, cuando esa lista se procese posteriormente, se generará un Use-After-Free. Limpie los temporizadores de la tarea desprovista de subprocesos antes de liberarlos. Esto evita un Use-After-Free reportado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/kprobes: Actualización del indicador de estado de kcb tras el paso único. Se corrigió que kprobes actualizara el indicador de estado de kcb (bloque de control de kprobes) a KPROBE_HIT_SSDONE incluso si kp->post_handler no está configurado. Este error puede causar un pánico del kernel si otro usuario INT3 se ejecuta justo después de kprobes, ya que kprobe_int3_handler() malinterpreta que INT3 es el INT3 de paso único de kprobe.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: s3fb: Verifique el tamaño de la pantalla antes de memset_io() En la función s3fb_set_par(), el valor de 'screen_size' se calcula mediante la entrada del usuario. Si el usuario proporciona un valor incorrecto, el valor de 'screen_size' puede ser mayor que 'info->screen_size', lo que puede causar el siguiente error: [ 54.083733] ERROR: no se puede manejar el error de página para la dirección: ffffc90003000000 [ 54.083742] #PF: acceso de escritura del supervisor en modo kernel [ 54.083744] #PF: error_code(0x0002) - página no presente [ 54.083760] RIP: 0010:memset_orig+0x33/0xb0 [ 54.083782] Rastreo de llamadas: [ 54.083788] s3fb_set_par+0x1ec6/0x4040 [ 54.083806] fb_set_var+0x604/0xeb0 [ 54.083836] do_fb_ioctl+0x234/0x670 Solucione este problema comprobando el valor de 'screen_size' antes de memset_io().

Motivo del rechazo: esta autoridad de numeración CVE ha rechazado o retirado esta ID CVE.

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: ext4: añadir la macro EXT4_INODE_HAS_XATTR_SPACE en xattr.h. Al añadir un xattr a un inodo, debemos asegurarnos de que el inode_size no sea menor que EXT4_GOOD_OLD_INODE_SIZE + extra_isize + pad. De lo contrario, la posición final podría ser mayor que la inicial, lo que provocaría un UAF.

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: 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.