Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.

Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

Vulnerabilidad en kernel de Linux (CVE-2022-50082)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 18/11/2025
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.
Vulnerabilidad en kernel de Linux (CVE-2022-50084)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 18/11/2025
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.
Vulnerabilidad en kernel de Linux (CVE-2022-50085)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 18/11/2025
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.
Vulnerabilidad en kernel de Linux (CVE-2022-50086)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 18/11/2025
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.
Vulnerabilidad en kernel de Linux (CVE-2022-50087)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 18/11/2025
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.
Vulnerabilidad en kernel de Linux (CVE-2022-50088)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/reclaim: se corrige una posible fuga de memoria en damon_reclaim_init(). damon_reclaim_init() asigna un fragmento de memoria para ctx con damon_new_ctx(). Cuando damon_select_ops() falla, ctx no se libera, lo que provoca una fuga de memoria. Deberíamos liberar ctx con damon_destroy_ctx() cuando damon_select_ops() no solucione la fuga de memoria.
Vulnerabilidad en kernel de Linux (CVE-2022-50089)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: garantizar que las páginas se desbloqueen en caso de fallo de cow_file_range() Hay un informe de hung_task en btrfs zonificados como el que se muestra a continuación. https://github.com/naota/linux/issues/59 [726.328648] INFORMACIÓN: la tarea rocksdb:high0:11085 se bloqueó durante más de 241 segundos. [726.329839] No contaminado 5.16.0-rc1+ #1 [726.330484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" deshabilita este mensaje. [726.331603] tarea:rocksdb:high0 estado:D pila: 0 pid:11085 ppid: 11082 indicadores:0x00000000 [726.331608] Seguimiento de llamadas: [726.331611] [726.331614] __schedule+0x2e5/0x9d0 [726.331622] schedule+0x58/0xd0 [726.331626] io_schedule+0x3f/0x70 [726.331629] __folio_lock+0x125/0x200 [726.331634] ? find_get_entries+0x1bc/0x240 [726.331638] ? filemap_invalidate_unlock_two+0x40/0x40 [726.331642] truncate_inode_pages_range+0x5b2/0x770 [726.331649] truncate_inode_pages_final+0x44/0x50 [726.331653] btrfs_evict_inode+0x67/0x480 [726.331658] evict+0xd0/0x180 [726.331661] iput+0x13f/0x200 [726.331664] do_unlinkat+0x1c0/0x2b0 [726.331668] __x64_sys_unlink+0x23/0x30 [726.331670] do_syscall_64+0x3b/0xc0 [726.331674] entry_SYSCALL_64_after_hwframe+0x44/0xae [726.331677] RIP: 0033:0x7fb9490a171b [726.331681] RSP: 002b:00007fb943ffac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000057 [726.331684] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9490a171b [726.331686] RDX: 00007fb943ffb040 RSI: 000055a6bbe6ec20 RDI: 00007fb94400d300 [726.331687] RBP: 00007fb943ffad00 R08: 0000000000000000 R09: 0000000000000000 [726.331688] R10: 0000000000000031 R11: 0000000000000246 R12: 00007fb943ffb000 [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260 [726.331693] Mientras depurábamos el problema, encontramos que ejecutar fstests generic/551 en un dispositivo null_blk sin zona de 5 GB en el modo de zona emulada también tenía un problema de bloqueo similar. Además, podemos reproducir el mismo síntoma con un error inyectado en la configuración de cow_file_range(). El bloqueo ocurre cuando cow_file_range() falla en medio de la asignación. cow_file_range() llamado desde do_allocation_zoned() puede dividir la región dada ([inicio, fin]) para la asignación dependiendo de los usos actuales del grupo de bloques. Cuando btrfs puede asignar bytes para una parte de las regiones divididas pero falla para la otra región (por ejemplo, debido a -ENOSPC), devolvemos el error dejando bloqueadas las páginas en las regiones exitosas. Técnicamente, esto solo ocurre cuando @unlock == 0. De lo contrario, desbloqueamos las páginas en una región asignada tras crear una extensión ordenada. Dado que quienes llaman a cow_file_range(unlock=0) no escribirán las páginas, podemos desbloquearlas al salir de cow_file_range() en caso de error. Por lo tanto, podemos asegurar que todas las páginas, excepto @locked_page, se desbloqueen en caso de error. En resumen, cow_file_range ahora se comporta así: - page_started == 1 (valor de retorno): todas las páginas están desbloqueadas. Se inicia la E/S. - unlock == 1: todas las páginas, excepto @locked_page, se desbloquean en cualquier caso. - unlock == 0: en caso de éxito, todas las páginas están bloqueadas para su escritura. - en caso de error, todas las páginas, excepto @locked_page, se desbloquean.
Vulnerabilidad en kernel de Linux (CVE-2022-50090)
Severidad: ALTA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 18/11/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: reemplazar BTRFS_MAX_EXTENT_SIZE con fs_info->max_extent_size En el sistema de archivos zonificado, la escritura de datos está limitada por max_zone_append_size, y una extensión ordenada grande se divide según el tamaño de un bio. OTOH, el número de extensiones que se escribirán se calcula utilizando BTRFS_MAX_EXTENT_SIZE, y ese número estimado se utiliza para reservar los bytes de metadatos para actualizar y/o crear los elementos de metadatos. La reserva de metadatos se realiza en, por ejemplo, btrfs_buffered_write() y luego se libera de acuerdo con los cambios de estimación. Por lo tanto, si el número de extensiones aumenta masivamente, los metadatos reservados pueden agotarse. El aumento del número de extensiones ocurre fácilmente en el sistema de archivos zonificado si BTRFS_MAX_EXTENT_SIZE > max_zone_append_size. Y causa la siguiente advertencia en un entorno de RAM pequeño con la deshabilitación de la sobreasignación de metadatos (en el siguiente parche). [75721.498492] ------------[ cortar aquí ]------------ [75721.505624] BTRFS: el bloque rsv 1 devolvió -28 [75721.512230] ADVERTENCIA: CPU: 24 PID: 2327559 en fs/btrfs/block-rsv.c:537 btrfs_use_block_rsv+0x560/0x760 [btrfs] [75721.581854] CPU: 24 PID: 2327559 Comm: kworker/u64:10 Kdump: cargado Tainted: GW 5.18.0-rc2-BTRFS-ZNS+ #109 [75721.597200] Nombre del hardware: Supermicro Super Server/H12SSL-NT, BIOS 2.0 22/02/2021 [75721.607310] Cola de trabajo: btrfs-endio-write btrfs_work_helper [btrfs] [75721.616209] RIP: 0010:btrfs_use_block_rsv+0x560/0x760 [btrfs] [75721.646649] RSP: 0018:ffffc9000fbdf3e0 EFLAGS: 00010286 [75721.654126] RAX: 00000000000000000 RBX: 0000000000004000 RCX: 0000000000000000 [75721.663524] RDX: 0000000000000004 RSI: 0000000000000008 RDI: fffff52001f7be6e [75721.672921] RBP: ffffc9000fbdf420 R08: 0000000000000001 R09: ffff889f8d1fc6c7 [75721.682493] R10: ffffed13f1a3f8d8 R11: 000000000000001 R12: ffff88980a3c0e28 [75721.692284] R13: ffff889b66590000 R14: ffff88980a3c0e40 R15: ffff88980a3c0e8a [75721.701878] FS: 0000000000000000(0000) GS:ffff889f8d000000(0000) knlGS:0000000000000000 [75721.712601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [75721.720726] CR2: 000055d12e05c018 CR3: 0000800193594000 CR4: 0000000000350ee0 [75721.730499] Rastreo de llamadas: [75721.735166] [75721.739886] btrfs_alloc_tree_block+0x1e1/0x1100 [btrfs] [75721.747545] ? btrfs_alloc_logged_file_extent+0x550/0x550 [btrfs] [75721.756145] ? btrfs_get_32+0xea/0x2d0 [btrfs] [75721.762852] ? btrfs_get_32+0xea/0x2d0 [btrfs] [75721.769520] ? push_leaf_left+0x420/0x620 [btrfs] [75721.776431] ? memcpy+0x4e/0x60 [75721.781931] split_leaf+0x433/0x12d0 [btrfs] [75721.788392] ? btrfs_get_token_32+0x580/0x580 [btrfs] [75721.795636] ? push_for_double_split.isra.0+0x420/0x420 [btrfs] [75721.803759] ? leaf_space_used+0x15d/0x1a0 [btrfs] [75721.811156] btrfs_search_slot+0x1bc3/0x2790 [btrfs] [75721.818300] ? lock_downgrade+0x7c0/0x7c0 [75721.824411] ? free_extent_buffer.part.0+0x107/0x200 [btrfs] [75721.832456] ? split_leaf+0x12d0/0x12d0 [btrfs] [75721.839149] ? free_extent_buffer.part.0+0x14f/0x200 [btrfs] [75721.846945] ? free_extent_buffer+0x13/0x20 [btrfs] [75721.853960] ? btrfs_release_path+0x4b/0x190 [btrfs] [75721.861429] btrfs_csum_file_blocks+0x85c/0x1500 [btrfs] [75721.869313] ? rcu_read_lock_sched_held+0x16/0x80 [75721.876085] ? lock_release+0x552/0xf80 [75721.881957] ? btrfs_del_csums+0x8c0/0x8c0 [btrfs] [75721.888886] ? __kasan_check_write+0x14/0x20 [75721.895152] ? do_raw_read_unlock+0x44/0x80 [75721.901323] ? _raw_write_lock_irq+0x60/0x80 [75721.907983] ? btrfs_global_root+0xb9/0xe0 [btrfs] [75721.915166] ? btrfs_csum_root+0x12b/0x180 [btrfs] [75721.921918] ? btrfs_get_global_root+0x820/0x820 [btrfs] [75721.929166] ? _raw_write_unlock+0x23/0x40 [75721.935116] ? unpin_extent_cache+0x1e3/0x390 [btrfs] [75721.942041] btrfs_finish_ordered_io.isra.0+0xa0c/0x1dc0 [btrfs] [75721.949906] ? try_to_wake_up+0x30/0x14a0 [75721.955700] ? btrfs_unlink_subvol+0xda---truncado---
Vulnerabilidad en kernel de Linux (CVE-2022-50091)
Severidad: MEDIA
Fecha de publicación: 18/06/2025
Fecha de última actualización: 18/11/2025
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.