Vulnerabilidades

Con el objetivo de informar, advertir y ayudar a los profesionales sobre las ultimas vulnerabilidades de seguridad en sistemas tecnológicos, ponemos a disposición de los usuarios interesados en esta información una base de datos con información en castellano sobre cada una de las ultimas vulnerabilidades documentadas y conocidas.

Este repositorio con más de 75.000 registros esta basado en la información de NVD (https://nvd.nist.gov/) (National Vulnerability Database) – en función de un acuerdo de colaboración – por el cual desde INCIBE realizamos la traducción al castellano de la información incluida. En ocasiones este listado mostrará vulnerabilidades que aún no han sido traducidas debido a que se recogen en el transcurso del tiempo en el que el equipo de INCIBE realiza el proceso de traducción.

Se emplea el estándar de nomenclatura de vulnerabilidades CVE (https://cve.mitre.org/) (Common Vulnerabilities and Exposures), con el fin de facilitar el intercambio de información entre diferentes bases de datos y herramientas. Cada una de las vulnerabilidades recogidas enlaza a diversas fuentes de información así como a parches disponibles o soluciones aportadas por los fabricantes y desarrolladores. Es posible realizar búsquedas avanzadas teniendo la opción de seleccionar diferentes criterios como el tipo de vulnerabilidad, fabricante, tipo de impacto entre otros, con el fin de acortar los resultados.

Mediante suscripción RSS (https://www.incibe.es/feed/vulnerabilities) o Boletines (https://www.incibe.es//incibe/suscripciones) podemos estar informados diariamente de las ultimas vulnerabilidades incorporadas al repositorio.

CVE-2021-46964

Fecha de publicación:
27/02/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: reservar vectores IRQ adicionales el commit a6dcfe08487e ("scsi: qla2xxx: limitar los vectores de interrupción al número de CPU") reduce el número de vectores MSI-X asignados al número de CPU. Eso rompe los supuestos de asignación de vectores en qla83xx_iospace_config(), qla24xx_enable_msix() y qla2x00_iospace_config(). Cualquiera de las funciones calcula el número máximo de qpairs como: ha->max_qpairs = ha->msix_count - 1 (interrupción de MB) - 1 (cola de respuesta predeterminada) - 1 (ATIO, en modo de destino dual o puro) max_qpairs se establece en cero en caso de dos CPU y modo iniciador. Luego, el número se usa para asignar ha->queue_pair_map dentro de qla2x00_alloc_queues(). No se produce ninguna asignación y ha->queue_pair_map se deja NULL pero el controlador cree que hay pares de colas disponibles. qla2xxx_queuecommand() intenta encontrar un qpair en el mapa y falla: if (ha->mqenable) { uint32_t tag; uint16_t hwq; estructura qla_qpair *qpair = NULL; etiqueta = blk_mq_unique_tag(cmd->solicitud); hwq = blk_mq_unique_tag_to_hwq(etiqueta); qpair = ha->queue_pair_map[hwq]; # <- AQUÍ si (qpair) return qla2xxx_mqueuecommand(host, cmd, qpair); } ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 #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] CPU SMP PTI: 0 PID: 72 Comunicaciones: kworker/u4:3 Contaminado: GW 5.10.0-rc1+ #25 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 01/04/2014 Cola de trabajo : scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc] RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx] Seguimiento de llamadas: scsi_queue_rq+0x58c/0xa60 blk_mq_dispatch_rq_list+0x2b7/0x6f0? __sbitmap_get_word+0x2a/0x80 __blk_mq_sched_dispatch_requests+0xb8/0x170 blk_mq_sched_dispatch_requests+0x2b/0x50 __blk_mq_run_hw_queue+0x49/0xb0 __blk_mq_delay_run_hw_queue+0xfb/0 x150 blk_mq_sched_insert_request+0xbe/0x110 blk_execute_rq+0x45/0x70 __scsi_execute+0x10e/0x250 scsi_probe_and_add_lun+0x228/0xda0 __scsi_scan_target+0xf4/0x620 ? __pm_runtime_resume+0x4f/0x70 scsi_scan_target+0x100/0x110 fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc] Process_one_work+0x1ea/0x3b0 trabajador_thread+0x28/0x3b0 ? proceso_one_work+0x3b0/0x3b0 kthread+0x112/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30 El controlador debe asignar suficientes vectores para proporcionar a cada CPU su propia cola de hardware y aún manejar interrupciones reservadas (MB, RSP, ATIO). El cambio corrige el fallo en la máquina virtual de doble núcleo y evita la asignación de QP desequilibrada donde nr_hw_queues es dos menos que la cantidad de CPU.
Severidad: Pendiente de análisis
Última modificación:
28/02/2024

CVE-2021-46970

Fecha de publicación:
27/02/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bus: mhi: pci_generic: Eliminar el indicador WQ_MEM_RECLAIM de la cola de trabajo de estado Un cambio reciente creó una cola de trabajo dedicada para el trabajo de cambio de estado con los indicadores WQ_HIGHPRI (sin ninguna razón importante para ello) y WQ_MEM_RECLAIM. pero el trabajo de cambio de estado (mhi_pm_st_worker) no garantiza el progreso hacia adelante bajo presión de la memoria, e incluso esperará varias asignaciones de memoria cuando, por ejemplo, se crean dispositivos, se carga firmware, etc... El trabajo entonces no forma parte de una ruta de recuperación de memoria. .. Además, esto provoca una advertencia en check_flush_dependency() ya que terminamos en un código que vacía una cola de trabajo que no es de recuperación: [ 40.969601] cola de trabajo: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] está descargando !WQ_MEM_RECLAIM events_highpri:flush_backlog [ 40.969612] ADVERTENCIA : CPU: 4 PID: 158 en kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140 [40.969733] Seguimiento de llamadas: [40.969740] __flush_work+0x97/0x1d0 [40.969745]? proceso_despertador+0x15/0x20 [40.969749]? insertar_trabajo+0x70/0x80 [40.969750]? __queue_work+0x14a/0x3e0 [ 40.969753] Flush_work+0x10/0x20 [ 40.969756] rollback_registered_many+0x1c9/0x510 [ 40.969759] unregister_netdevice_queue+0x94/0x120 [ 40.969761] anular el registro _netdev+0x1d/0x30 [ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net] [ 40.969770 ] mhi_driver_remove+0x124/0x250 [mhi] [ 40.969776] dispositivo_release_driver_internal+0xf0/0x1d0 [ 40.969778] dispositivo_release_driver+0x12/0x20 [ 40.969782] bus_remove_device+0xe1/0x150 [ 40.9 69786] dispositivo_del+0x17b/0x3e0 [ 40.969791] mhi_destroy_device+0x9a/0x100 [ mhi] [40.969796]? mhi_unmap_single_use_bb+0x50/0x50 [mhi] [ 40.969799] dispositivo_para_cada_niño+0x5e/0xa0 [ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi]
Severidad: Pendiente de análisis
Última modificación:
28/02/2024

CVE-2021-46972

Fecha de publicación:
27/02/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ovl: corrige la dentry filtrada Desde el commit 6815f479ca90 ("ovl: usa solo el estado de metacopia superior en ovl_lookup()"), overlayfs no coloca la dentry temporal cuando hay un error de metacopia, lo que conduce a fugas de dentry al cerrar el superbloque relacionado: overlayfs: se niega a seguir el origen de la metacopia para (/file0)... ERROR: Dentry (____ptrval____){i=3f33,n=file3} todavía está en uso (1) [desmontaje de superposición superpuesta]... ADVERTENCIA: CPU: 1 PID: 432 en umount_check.cold+0x107/0x14d CPU: 1 PID: 432 Comm: unmount-overlay No contaminado 5.12.0-rc5 #1... RIP: 0010:umount_check .cold+0x107/0x14d... Seguimiento de llamadas: d_walk+0x28c/0x950 ? dentry_lru_isolate+0x2b0/0x2b0? __kasan_slab_free+0x12/0x20 do_one_tree+0x33/0x60 encogimiento_dcache_for_umount+0x78/0x1d0 generic_shutdown_super+0x70/0x440 kill_anon_super+0x3e/0x70 deactivate_locked_super+0xc4/0x160 deactivate_super+0xfa/0x140 clean up_mnt+0x22e/0x370 __cleanup_mnt+0x1a/0x30 task_work_run+0x139/0x210 do_exit+0xb0c/0x2820? __kasan_check_read+0x1d/0x30 ? find_held_lock+0x35/0x160? lock_release+0x1b6/0x660? mm_update_next_owner+0xa20/0xa20? ¿reaquirir_held_locks+0x3f0/0x3f0? __sanitizer_cov_trace_const_cmp4+0x22/0x30 do_group_exit+0x135/0x380 __do_sys_exit_group.isra.0+0x20/0x20 __x64_sys_exit_group+0x3c/0x50 do_syscall_64+0x45/0x70 entrada_SYSCALL_64 _after_hwframe+0x44/0xae... VFS: Inodos ocupados después de desmontar la superposición. Autodestrucción en 5 segundos. Que tengas un buen día... Esta solución ha sido probada con un reproductor syzkaller.
Severidad: Pendiente de análisis
Última modificación:
28/02/2024

Go top