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 HDF5 (CVE-2017-17506)
Severidad: MEDIA
Fecha de publicación: 11/12/2017
Fecha de última actualización: 18/03/2025
En HDF5 1.10.1, hay una vulnerabilidad de lectura fuera de límites en la función H5Opline_pline_decode en H5Opline.c en libhdf5.a. Por ejemplo, h5dump se cerraría inesperadamente cuando alguien abriese un archivo hdf5 manipulado.
Vulnerabilidad en la biblioteca HDF HDF5 (CVE-2018-13873)
Severidad: CRÍTICA
Fecha de publicación: 10/07/2018
Fecha de última actualización: 18/03/2025
Se ha descubierto un problema en la biblioteca HDF HDF5 1.8.20. Hay una sobrelectura de búfer en H5O_chunk_deserialize en H5Ocache.c.
Vulnerabilidad en la función sdb_set_internal de radare2 (CVE-2018-14015)
Severidad: MEDIA
Fecha de publicación: 12/07/2018
Fecha de última actualización: 18/03/2025
La función sdb_set_internal en sdb.c en radare2 2.7.0 permite que atacantes remotos provoquen una denegación de servicio (lectura no válida y cierre inesperado de la aplicación) mediante un archivo ELF manipulado debido a la falta validación de entradas en r_bin_dwarf_parse_comp_unit en libr/bin/dwarf.c.
Vulnerabilidad en un archivo PDF en el archivo contrib/lips4/gdevlips.c en la función GetNumWrongData() en Artifex Software GhostScript (CVE-2020-16296)
Severidad: MEDIA
Fecha de publicación: 13/08/2020
Fecha de última actualización: 18/03/2025
Una vulnerabilidad de desbordamiento del búfer en la función GetNumWrongData() en el archivo contrib/lips4/gdevlips.c de Artifex Software GhostScript versión v9.50, permite a un atacante remoto causar una denegación de servicio por medio de un archivo PDF diseñado. Esto es corregido en la versión v9.51
Vulnerabilidad en un archivo PDF en el archivo contrib/lips4/gdevlips.c en la función GetNumSameData() en Artifex Software GhostScript (CVE-2020-17538)
Severidad: MEDIA
Fecha de publicación: 13/08/2020
Fecha de última actualización: 18/03/2025
Una vulnerabilidad de desbordamiento del búfer en la función GetNumSameData() en el archivo contrib/lips4/gdevlips.c de Artifex Software GhostScript versión v9.50, permite a un atacante remoto causar una denegación de servicio por medio de un archivo PDF diseñado. Esto es corregido en la versión v9.51
Vulnerabilidad en TIANJIE CPE906-3 (CVE-2022-47703)
Severidad: ALTA
Fecha de publicación: 16/02/2023
Fecha de última actualización: 18/03/2025
TIANJIE CPE906-3 es vulnerable a la divulgación de contraseñas. Esto está presente en la versión de software WEB5.0_LCD_20200513, la versión de firmware MV8.003 y la versión de hardware CPF906-V5.0_LCD_20200513.
Vulnerabilidad en la función gf_dump_vrml_dyn_field.isra en gpac (CVE-2021-44923)
Severidad: MEDIA
Fecha de publicación: 21/12/2021
Fecha de última actualización: 18/03/2025
Se presenta una vulnerabilidad de Desreferencia de Puntero Null en gpac versión 1.1.0 en la función gf_dump_vrml_dyn_field.isra, que causa un fallo de segmentación y un bloqueo de la aplicación
Vulnerabilidad en Archer Platform (CVE-2024-26311)
Severidad: MEDIA
Fecha de publicación: 21/02/2024
Fecha de última actualización: 18/03/2025
Archer Platform 6.x anterior a 6.14 P2 HF1 (6.14.0.2.1) contiene una vulnerabilidad XSS reflejada. Un usuario malicioso de Archer autenticado remotamente podría explotar esto engañando al usuario de la aplicación víctima para que proporcione código JavaScript malicioso a la aplicación web vulnerable. Luego, este código se refleja en la víctima y el navegador web lo ejecuta en el contexto de la aplicación web vulnerable.
Vulnerabilidad en Apache DolphinScheduler (CVE-2024-23320)
Severidad: ALTA
Fecha de publicación: 23/02/2024
Fecha de última actualización: 18/03/2025
Vulnerabilidad de validación de entrada incorrecta en Apache DolphinScheduler. Un usuario autenticado puede hacer que se ejecute JavaScript arbitrario y sin espacio aislado en el servidor. Este problema es un legado de CVE-2023-49299. No lo solucionamos por completo en CVE-2023-49299 y agregamos un parche más para solucionarlo. Este problema afecta a Apache DolphinScheduler: hasta 3.2.1. Se recomienda a los usuarios actualizar a la versión 3.2.1, que soluciona el problema.
Vulnerabilidad en Magma (CVE-2023-37027)
Severidad: MEDIA
Fecha de publicación: 21/01/2025
Fecha de última actualización: 18/03/2025
La vulnerabilidad de desreferencia de puntero nulo en la entidad de administración móvil (MME) en Magma <= 1.8.0 (corregida en v1.9 commit 08472ba98b8321f802e95f5622fa90fec2dea486) permite a atacantes adyacentes a la red bloquear la MME a través de un paquete S1AP `E-RAB Modification Indication` que carece de un campo `eNB_UE_S1AP_ID` ??esperado.
Vulnerabilidad en kernel de Linux (CVE-2021-47631)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: davinci: da850-evm: Evitar la desreferencia de puntero NULL Con versiones más nuevas de GCC, hay un pánico en da850_evm_config_emac() al iniciar multi_v5_defconfig en QEMU bajo la máquina palmetto-bmc: No se puede manejar la desreferencia de puntero NULL del kernel en la dirección virtual 00000020 pgd = (ptrval) [00000020] *pgd=00000000 Error interno: Oops: 5 [#1] PREEMPT Módulos ARM vinculados: CPU: 0 PID: 1 Comm: swapper No contaminado 5.15.0 #1 Nombre del hardware: Sistema genérico basado en DT La PC está en da850_evm_config_emac+0x1c/0x120 LR está en El puntero emac_pdata en soc_info es NULL porque davinci_soc_info solo se completa en máquinas davinci, pero se llama a da850_evm_config_emac() en todas las máquinas a través de device_initcall(). Mueva la asignación rmii_en debajo de la verificación de la máquina para que solo se desreferencia cuando se ejecuta en un SoC compatible.
Vulnerabilidad en kernel de Linux (CVE-2021-47632)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/set_memory: Evitar recursión de spinlock en change_page_attr() La confirmación 1f9ad21c3b38 ("powerpc/mm: Implementar rutinas set_memory()") incluyó un spin_lock() en change_page_attr() para realizar de forma segura las operaciones de tres pasos. Pero luego, la confirmación 9f7853d7609d ("powerpc/mm: Arreglar set_memory_*() contra accesos concurrentes") lo modificó para usar pte_update() y realizar la operación de forma segura contra accesos concurrentes. Mientras tanto, Maxime informó de cierta recursión de spinlock. [ 15.351649] ERROR: recursión de spinlock en CPU#0, kworker/0:2/217 [ 15.357540] bloqueo: init_mm+0x3c/0x420, .magic: dead4ead, .owner: kworker/0:2/217, .owner_cpu: 0 [ 15.366563] CPU: 0 PID: 217 Comm: kworker/0:2 No contaminado 5.15.0+ #523 [ 15.373350] Cola de trabajo: events do_free_init [ 15.377615] Call Trace: [ 15.380232] [e4105ac0] [800946a4] do_raw_spin_lock+0xf8/0x120 (unreliable) [ 15.387340] [e4105ae0] [8001f4ec] change_page_attr+0x40/0x1d4 [ 15.393413] [e4105b10] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.400009] [e4105b60] [80169620] free_pcp_prepare+0x1e4/0x4a0 [ 15.406045] [e4105ba0] [8016c5a0] free_unref_page+0x40/0x2b8 [ 15.411979] [e4105be0] [8018724c] kasan_depopulate_vmalloc_pte+0x6c/0x94 [ 15.418989] [e4105c00] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.425451] [e4105c50] [80187834] kasan_release_vmalloc+0xbc/0x134 [ 15.431898] [e4105c70] [8015f7a8] __purge_vmap_area_lazy+0x4e4/0xdd8 [ 15.438560] [e4105d30] [80160d10] _vm_unmap_aliases.part.0+0x17c/0x24c [ 15.445283] [e4105d60] [801642d0] __vunmap+0x2f0/0x5c8 [ 15.450684] [e4105db0] [800e32d0] do_free_init+0x68/0x94 [ 15.456181] [e4105dd0] [8005d094] process_one_work+0x4bc/0x7b8 [ 15.462283] [e4105e90] [8005d614] worker_thread+0x284/0x6e8 [ 15.468227] [e4105f00] [8006aaec] kthread+0x1f0/0x210 [ 15.473489] [e4105f40] [80017148] ret_from_kernel_thread+0x14/0x1c Elimina la secuencia de lectura/modificación/escritura para hacer que la operación sea atómica y elimina el spin_lock() en change_page_attr(). Para hacer la operación de forma atómica, ya no podemos usar ayudantes de modificación de pte. Debido a que todas las plataformas tienen diferentes combinaciones de bits, no es fácil usar esos bits directamente. Pero todas tienen el conjunto de indicadores _PAGE_KERNEL_{RO/ROX/RW/RWX}. Todo lo que necesitamos es comparar dos conjuntos para saber qué bits están configurados o borrados. Por ejemplo, al comparar _PAGE_KERNEL_ROX y _PAGE_KERNEL_RO sabes qué bit se borra y qué bit se configura al cambiar el permiso de ejecución.
Vulnerabilidad en kernel de Linux (CVE-2021-47636)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: Se corrige la lectura fuera de los límites en la función ubifs_wbuf_write_nolock() ubifs_wbuf_write_nolock() puede acceder a buf fuera de los límites en el siguiente proceso: ubifs_wbuf_write_nolock(): classified_len = ALIGN(len, 8); // Supongamos que len = 4089, classified_len = 4096 if (aligned_len <= wbuf->avail) ... // No satisface if (wbuf->used) { ubifs_leb_write() // Complete algunos datos en avail wbuf len -= wbuf->avail; // len aún no está alineado a 8 bytes classified_len -= wbuf->avail; } n = classified_len >> c->max_write_shift; if (n) { n <<= c->max_write_shift; err = ubifs_leb_write(c, wbuf->lnum, buf + escrito, wbuf->offs, n); // n > len, lectura fuera de los límites menor a 8(n-len) bytes }, lo cual puede ser detectado por KASAN: =========================================================== ERROR: KASAN: slab fuera de los límites en ecc_sw_hamming_calculate+0x1dc/0x7d0 Lectura de tamaño 4 en la dirección ffff888105594ff8 por la tarea kworker/u8:4/128 Cola de trabajo: escritura diferida wb_workfn (flush-ubifs_0_0) Rastreo de llamadas: kasan_report.cold+0x81/0x165 nand_write_page_swecc+0xa9/0x160 ubifs_leb_write+0xf2/0x1b0 [ubifs] ubifs_wbuf_write_nolock+0x421/0x12c0 [ubifs] write_head+0xdc/0x1c0 [ubifs] ubifs_jnl_write_inode+0x627/0x960 [ubifs] wb_workfn+0x8af/0xb80 La función ubifs_wbuf_write_nolock() acepta que el parámetro 'len' no esté alineado con 8 bytes, 'len' representa la longitud verdadera de buf (que está asignada en 'ubifs_jnl_xxx', p. ej. ubifs_jnl_write_inode), por lo que ubifs_wbuf_write_nolock() debe manejar la longitud leída de 'buf' con cuidado para escribir leb de forma segura. Obtenga un reproductor en [Enlace].
Vulnerabilidad en Kernel de Linux (CVE-2021-47637)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: Se corrige interbloqueo en concurrencia de un renombrado con whiteout simultáneo a la escritura del inodo. Tareas colgadas: [ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132 [ 77.028820] Call Trace: [ 77.029027] schedule+0x8c/0x1b0 [ 77.029067] mutex_lock+0x50/0x60 [ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs] [ 77.029117] __writeback_single_inode+0x43c/0x570 [ 77.029128] writeback_sb_inodes+0x259/0x740 [ 77.029148] wb_writeback+0x107/0x4d0 [ 77.029163] wb_workfn+0x162/0x7b0 [ 92.390442] task:aa state:D stack: 0 pid: 1506 [ 92.390448] Call Trace: [ 92.390458] schedule+0x8c/0x1b0 [ 92.390461] wb_wait_for_completion+0x82/0xd0 [ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110 [ 92.390472] writeback_inodes_sb_nr+0x14/0x20 [ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs] [ 92.390503] do_rename.cold+0x7f/0x187 [ubifs] [ 92.390549] ubifs_rename+0x8b/0x180 [ubifs] [ 92.390571] vfs_rename+0xdb2/0x1170 [ 92.390580] do_renameat2+0x554/0x770 , ocasionado por procesos simultáneos de renombrado con whiteout y escritura del inodo: rename_whiteout(Thread 1) wb_workfn(Thread2) ubifs_rename do_rename lock_4_inodes (Hold ui_mutex) ubifs_budget_space make_free_space shrink_liability __writeback_inodes_sb_nr bdi_split_work_to_wbs (Queue new wb work) wb_do_writeback(wb work) __writeback_single_inode ubifs_write_inode LOCK(ui_mutex) ? wb_wait_for_completion (Wait wb work) <-- ¡interbloqueo! Caso de prueba: 1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT) 2. Consumir todo el espacio antes de que kernel(mdelay) planifique el whiteout Arreglado calculando el espacio de whiteout antes de bloquear los inodos de ubifs. También soluciona etiqueta la etiqueta goto errónea 'out_release' en el flujo de errores de la planificación del whiteout (al menos debería recuperar el directorio i_size y desbloquear 4 inodos de ubifs).
Vulnerabilidad en kernel de Linux (CVE-2021-47638)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: rename_whiteout: Se corrige la doble liberación para whiteout_ui->data 'whiteout_ui->data' se liberará dos veces si el presupuesto de espacio falla para la operación de cambio de nombre de whiteout como el siguiente proceso: rename_whiteout dev = kmalloc whiteout_ui->data = dev kfree(whiteout_ui->data) // Libera la primera vez iput(whiteout) ubifs_free_inode kfree(ui->data) // ¡Doble liberación! KASAN informa: ==================================================================== ERROR: KASAN: liberación doble o liberación no válida en ubifs_free_inode+0x4f/0x70 Seguimiento de llamadas: kfree+0x117/0x490 ubifs_free_inode+0x4f/0x70 [ubifs] i_callback+0x30/0x60 rcu_do_batch+0x366/0xac0 __do_softirq+0x133/0x57f Asignado por la tarea 1506: kmem_cache_alloc_trace+0x3c2/0x7a0 do_rename+0x9b7/0x1150 [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 Liberado por la tarea 1506: kfree+0x117/0x490 do_rename.cold+0x53/0x8a [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 La dirección con errores pertenece al objeto en ffff88810238bed8 que pertenece al caché kmalloc-8 de tamaño 8 ===================================================================== Deje que ubifs_free_inode() libere 'whiteout_ui->data'. Por cierto, elimine la asignación no utilizada 'whiteout_ui->data_len = 0', el proceso 'ubifs_evict_inode() -> ubifs_jnl_delete_inode() -> ubifs_jnl_write_inode()' no lo necesita (porque 'inc_nlink(whiteout)' no será ejecutado por 'goto out_release', y el nlink del inodo whiteout es 0).
Vulnerabilidad en kernel de Linux (CVE-2021-47640)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/kasan: Se solucionó que la región temprana no se actualizara correctamente La tabla de páginas de shadow no se actualiza cuando PTE_RPN_SHIFT es 24 y PAGE_SHIFT es 12. No solo causa falsos positivos sino también falsos negativos como se muestra en el siguiente texto. Arréglelo trayendo la lógica de kasan_early_shadow_page_entry aquí. 1. Falso positivo: ==================================================================== ERROR: KASAN: vmalloc fuera de los límites en pcpu_alloc+0x508/0xa50 Escritura de tamaño 16 en la dirección f57f3be0 por la tarea swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 No contaminado 5.15.0-12267-gdebe436e77c7 #1 Seguimiento de llamadas: [c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (no confiable) [c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300 [c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200 [c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0 [c80d1cc0] [c03018a4] memset+0x34/0x90 [c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50 [c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570 [c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0 [c80d1db0] [c2036580] init_sd+0xc4/0x1d0 [c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c [c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384 [c80d1ef0] [c0004b14] kernel_init+0x24/0x170 [c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64 Estado de la memoria alrededor de la dirección con errores: f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ===================================================================== 2. Falso negativo (con pruebas KASAN): ==================================================================== Antes de la corrección: ok 45 - kmalloc_double_kzfree # vmalloc_oob: EXPECTATIVA FALLÓ en lib/test_kasan.c:1039 Se esperaba una falla de KASAN en "((volatile char *)area)[3100]", pero no ocurrió ninguna no ok 46 - vmalloc_oob no ok 1 - kasan ======================================================================== Después de la corrección: ok 1 - kasan
Vulnerabilidad en kernel de Linux (CVE-2021-47641)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: cirrusfb: comprobar pixclock para evitar la división por cero Realice una comprobación de la depuración del valor de pixclock para evitar la división por cero. Si el valor de pixclock es cero, el controlador cirrusfb redondeará el valor de pixclock para obtener la frecuencia derivada lo más cercana posible a maxclock. Syzkaller informó un error de división en cirrusfb_check_pixclock. Error de división: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 14938 Comm: cirrusfb_test No contaminado 5.15.0-rc6 #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.11.0-2 RIP: 0010:cirrusfb_check_var+0x6f1/0x1260 Seguimiento de llamadas: fb_set_var+0x398/0xf90 do_fb_ioctl+0x4b8/0x6f0 fb_ioctl+0xeb/0x130 __x64_sys_ioctl+0x19d/0x220 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae
Vulnerabilidad en kernel de Linux (CVE-2021-47644)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: staging: media: zoran: move videodev alloc Mueva parte del código de zr36057_init() y cree nuevas funciones para manejar zr->video_dev. Esto permite facilitar la lectura del código y reparar una pérdida de memoria en zr->video_dev.
Vulnerabilidad en kernel de Linux (CVE-2021-47645)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: staging: media: zoran: calcula el número de búfer correcto para zoran_reap_stat_com En el caso tmp_dcim=1, el índice del búfer se calcula mal. Esto genera una desreferencia de puntero NULL más adelante. Por lo tanto, arreglemos el cálculo y agreguemos una verificación para evitar que esto vuelva a aparecer.
Vulnerabilidad en kernel de Linux (CVE-2021-47648)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpu: host1x: Se corrige una pérdida de memoria en 'host1x_remove()'. Se agrega una llamada 'host1x_channel_list_free()' faltante en la función de eliminación, como ya se hizo en la ruta de manejo de errores de la función de sonda.
Vulnerabilidad en kernel de Linux (CVE-2021-47651)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: rpmpd: Verificar el retorno nulo de devm_kcalloc Debido al posible fallo de la asignación, data->domains podría ser un puntero NULL y provocará la desreferencia del puntero NULL más adelante. Por lo tanto, podría ser mejor verificarlo y devolver directamente -ENOMEM sin liberar los datos manualmente si falla, porque el comentario de devm_kmalloc() dice "La memoria asignada con esta función se libera automáticamente al desconectar el controlador".
Vulnerabilidad en kernel de Linux (CVE-2021-47652)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: video: fbdev: smscufx: Corregir null-ptr-deref en ufx_usb_probe() Recibí un informe de null-ptr-deref: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000000 ... RIP: 0010:fb_destroy_modelist+0x38/0x100 ... Seguimiento de llamadas: ufx_usb_probe.cold+0x2b5/0xac1 [smscufx] usb_probe_interface+0x1aa/0x3c0 [usbcore] really_probe+0x167/0x460 ... ret_from_fork+0x1f/0x30 Si fb_alloc_cmap() falla en ufx_usb_probe(), fb_destroy_modelist() Se llamará a modelist para destruirlo en la ruta de manejo de errores. Pero modelist aún no se ha inicializado, por lo que dará como resultado null-ptr-deref. Inicialice modelist antes de llamar a fb_alloc_cmap() para corregir este error.
Vulnerabilidad en kernel de Linux (CVE-2021-47654)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: samples/landlock: Se corrige la pérdida de memoria de path_list El análisis estático de Clang informa este error sandboxer.c:134:8: advertencia: Posible pérdida de memoria señalada por 'path_list' ret = 0; ^ path_list se asigna en parse_path() pero nunca se libera.
Vulnerabilidad en kernel de Linux (CVE-2021-47655)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: vdec: se ha corregido un posible problema de pérdida de memoria La implementación de venus_helper_alloc_dpb_bufs() permite un retorno temprano a una ruta de error al verificar el id de ida_alloc_min(), lo que no liberaría la asignación de búfer anterior. Mueva el kfree() directo de la verificación de errores de dma_alloc_attrs() a la ruta de error común para garantizar que se liberen las asignaciones en todas las rutas de error en esta función. Addresses-Coverity: 1494120 ("Fuga de recursos")
Vulnerabilidad en kernel de Linux (CVE-2021-47657)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/virtio: Asegúrese de que objs no sea NULL en virtio_gpu_array_put_free() Si virtio_gpu_object_shmem_init() falla (por ejemplo, debido a la inyección de fallos, como sucedió en el informe de error de syzbot), se podría llamar a virtio_gpu_array_put_free() con objs igual a NULL. Asegúrese de que objs no sea NULL en virtio_gpu_array_put_free() o, de lo contrario, regrese de la función.
Vulnerabilidad en kernel de Linux (CVE-2021-47660)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Se han solucionado algunas fugas de memoria en una ruta de manejo de errores de 'log_replay()'. Todas las rutas de manejo de errores conducen a 'out', donde se liberan muchos recursos. Hágalo también aquí en lugar de un retorno directo, de lo contrario, se producirán fugas de 'log', 'ra' y 'log->one_page_buf' (al menos).
Vulnerabilidad en kernel de Linux (CVE-2021-4453)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: se corrige una posible pérdida de memoria en gpu_metrics_table La memoria está asignada para gpu_metrics_table en renoir_init_smc_tables(), pero no se libera en int smu_v12_0_fini_smc_tables(). ¡Libérenla!
Vulnerabilidad en kernel de Linux (CVE-2022-49046)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: dev: verificar el valor de retorno al llamar a dev_set_name() Si dev_set_name() falla, dev_name() es nulo, verifique el valor de retorno de dev_set_name() para evitar el null-ptr-deref.
Vulnerabilidad en kernel de Linux (CVE-2022-49055)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: comprobar si kmalloc_array() puede devolver un valor nulo. Como kmalloc_array() puede devolver un valor nulo, 'event_waiters[i].wait' provocaría una desreferencia de puntero nulo. Por lo tanto, es mejor comprobar el valor de retorno de kmalloc_array() para evitar esta confusión.
Vulnerabilidad en kernel de Linux (CVE-2022-49058)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: desbordamiento de búfer potencial al manejar enlaces simbólicos Smatch imprimió una advertencia: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' demasiado pequeño (16 vs u32max) Esto se debe a que Smatch marca 'link_len' como no confiable ya que proviene de sscanf(). Agregue una verificación para asegurarse de que 'link_len' no sea más grande que el tamaño del búfer 'link_str'.
Vulnerabilidad en kernel de Linux (CVE-2022-49060)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: Se ha corregido la desreferencia de puntero NULL en smc_pnet_find_ib(). Se llamaba a dev_name() con dev.parent como argumento, pero sin comprobarlo antes. Se soluciona comprobando el puntero antes de llamar a dev_name().
Vulnerabilidad en kernel de Linux (CVE-2022-49061)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: stmmac: corregir la función altr_tse_pcs al usar un enlace fijo Al usar un enlace fijo, el controlador altr_tse_pcs se bloquea debido a la desreferencia de puntero nulo ya que no se proporciona ningún phy_device a la función tse_pcs_fix_mac_speed. Solucione esto agregando una verificación para phy_dev antes de llamar a la función tse_pcs_fix_mac_speed(). También limpie un poco la función tse_pcs_fix_mac_speed. No es necesario verificar splitter_base y sgmii_adapter_base porque el controlador fallará si estas 2 variables no se derivan del árbol de dispositivos.
Vulnerabilidad en kernel de Linux (CVE-2022-49062)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: corrige el error KASAN slab-out-of-bounds en cachefiles_set_volume_xattr. Usa la longitud real de los datos de coherencia del volumen al configurar xattr para evitar el siguiente informe KASAN. ERROR: KASAN: slab-out-of-bounds en cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] Escritura de tamaño 4 en la dirección ffff888101e02af4 por la tarea kworker/6:0/1347 CPU: 6 PID: 1347 Comm: kworker/6:0 Kdump: cargado No contaminado 5.18.0-rc1-nfs-fscache-netfs+ #13 Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014 Cola de trabajo: eventos fscache_create_volume_work [fscache] Seguimiento de llamadas: dump_stack_lvl+0x45/0x5a print_report.cold+0x5e/0x5db ? __lock_text_start+0x8/0x8 ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] kasan_report+0xab/0x120 ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] kasan_check_range+0xf5/0x1d0 memcpy+0x39/0x60 cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles] cachefiles_acquire_volume+0x2be/0x500 [cachefiles] ? __cachefiles_free_volume+0x90/0x90 [cachefiles] fscache_create_volume_work+0x68/0x160 [fscache] process_one_work+0x3b7/0x6a0 worker_thread+0x2c4/0x650 ? process_one_work+0x6a0/0x6a0 kthread+0x16c/0x1a0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 Asignado por la tarea 1347: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 cachefiles_set_volume_xattr+0x76/0x350 [archivos de caché] cachefiles_acquire_volume+0x2be/0x500 [archivos de caché] fscache_create_volume_work+0x68/0x160 [fscache] process_one_work+0x3b7/0x6a0 worker_thread+0x2c4/0x650 kthread+0x16c/0x1a0 ret_from_fork+0x22/0x30 La dirección con errores pertenece a el objeto en ffff888101e02af0 que pertenece al caché kmalloc-8 de tamaño 8 La dirección con errores se encuentra 4 bytes dentro de la región de 8 bytes [ffff888101e02af0, ffff888101e02af8) La dirección con errores pertenece a la página física: page:00000000a2292d70 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x101e02 flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff) raw: 0017ffffc0000200 0000000000000000 dead000000000001 ffff888100042280 raw: 0000000000000000 0000000080660066 00000001ffffffff 00000000000000000 página volcada porque: kasan: se detectó mal acceso Estado de la memoria alrededor de la dirección con errores: ffff888101e02980: FC 00 FC FC FC FC 00 FC FC FC FC 00 FC FC FC FC ffff888101e02a00: 00 FC FC FC FC 00 FC FC FC FC 00 FC FC FC FC 00 >ffff888101e02a80: FC FC FC FC 00 FC FC fc fc 00 fc fc fc fc 04 fc ^ ffff888101e02b00: fc fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc ffff888101e02b80: fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc =====================================================================
Vulnerabilidad en kernel de Linux (CVE-2022-49065)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: SUNRPC: Arreglar la clase de seguimiento svc_deferred_event Arreglar un fallo de desreferencia NULL que ocurre cuando se aplaza un svc_rqst mientras el subsistema de seguimiento sunrpc está habilitado. svc_revisit() establece dr->xprt en NULL, por lo que no se puede confiar en él en el punto de seguimiento para proporcionar la dirección del control remoto. Desafortunadamente, no podemos revertir el trozo "svc_deferred_class" en el commit ece200ddd54b ("sunrpc: Guardar la dirección de presentación remota en svc_xprt para eventos de seguimiento") porque ahora hay una comprobación específica de especificadores de formato de evento para desreferencias inseguras. La advertencia que emite la comprobación es: el evento svc_defer_recv tiene una desreferencia insegura del argumento 1 Un especificador de formato "%pISpc" con un "struct sockaddr *" está marcado por esta comprobación. En su lugar, adopte el enfoque de fuerza bruta utilizado por el punto de seguimiento svcrdma_qp_error. Convierta el campo dr::addr en una dirección de presentación en el brazo TP_fast_assign() del evento de seguimiento y almacénelo como una cadena. Esta corrección se puede implementar en kernels estables. Mientras tanto, el commit c6ced22997ad ("seguimiento: Actualizar la comprobación de impresión fmt para manejar la nueva macro __get_sockaddr()") ahora está en v5.18, por lo que esta corrección complicada se puede reemplazar con __sockaddr() y similares correctamente durante la ventana de fusión de v5.19.
Vulnerabilidad en kernel de Linux (CVE-2022-49070)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: Se corrige la anulación del registro de los framebuffers sin dispositivo. Los framebuffers OF no tienen un dispositivo subyacente en la jerarquía de dispositivos de Linux. Se realiza una llamada de anulación del registro normal en lugar de desconectar en caliente un dispositivo inexistente. Se corrige una desreferencia NULL. A continuación se muestra un mensaje de error de ejemplo en ppc64le. ERROR: Desreferencia de puntero NULL del kernel en lectura en 0x00000060 Dirección de instrucción con error: 0xc00000000080dfa4 Oops: Acceso del kernel al área defectuosa, firma: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [...] CPU: 2 PID: 139 Comm: systemd-udevd No contaminado 5.17.0-ae085d7f9365 #1 NIP: c00000000080dfa4 LR: c00000000080df9c CTR: c000000000797430 REGS: c000000004132fe0 TRAP: 0300 No contaminado (5.17.0-ae085d7f9365) MSR: 8000000002009033 CR: 28228282 XER: 20000000 CFAR: c00000000000c80c DAR: 0000000000000060 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000080df9c c000000004133280 c00000000169d200 0000000000000029 GPR04: 00000000fffffff c000000004132f90 c000000004132f88 00000000000000000 GPR08: c0000000015658f8 c0000000015cd200 c0000000014f57d0 0000000048228283 GPR12: 000000000000000 c0000003fffe300 000000002000000 000000000000000 GPR16: 000000000000000 0000000113fc4a40 000000000000005 0000000113fcfb80 GPR20: 000001000f7283b0 0000000000000000 c000000000e4a588 c000000000e4a5b0 GPR24: 0000000000000001 00000000000a000 c008000000db0168 c0000000021f6ec0 GPR28: c0000000016d65a8 c000000004b36460 000000000000000 c0000000016d64b0 PIP [c00000000080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0 [c000000004133280] [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (no confiable) [c000000004133350] [c00000000080e4d0] remove_conflicting_framebuffers+0x60/0x150 [c0000000041333a0] [c00000000080e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0 [c000000004133450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm] [c000000004133490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs] [...] [c000000004133db0] [c00000000002aaa0] system_call_exception+0x170/0x2d0 [c000000004133e10] [c00000000000c3cc] system_call_common+0xec/0x250 El error [1] fue introducido por el commit 27599aacbaef ("fbdev: Desconexión en caliente dispositivos fb de firmware en caso de eliminación forzada"). La mayoría de los framebuffers de firmware tienen un dispositivo de plataforma subyacente, que se puede desconectar en caliente antes de cargar el controlador de gráficos nativo. Los framebuffers de OF no tienen (todavía) ese dispositivo. Corrija el código anulando el registro del framebuffer como antes sin una desconexión en caliente. Probado con 5.17 en emulación qemu ppc64le.
Vulnerabilidad en kernel de Linux (CVE-2022-49071)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panel: ili9341: se corrige la gestión del regulador opcional. Si la búsqueda del regulador opcional falla, restablece el puntero a NULL. Otras funciones como mipi_dbi_poweron_reset_conditional() solo realizan una verificación del puntero NULL y, de lo contrario, desreferenciarán el puntero de error.
Vulnerabilidad en kernel de Linux (CVE-2022-49190)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kernel/resource: fix kfree() of bootmem memory again Desde el commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem memory"), podríamos obtener un recurso asignado durante el arranque a través de alloc_resource(). Y es necesario liberar el recurso utilizando free_resource(). Sin embargo, muchas personas utilizan kfree directamente, lo que dará como resultado un ERROR del kernel. Para solucionar esto sin reparar cada sitio de llamada, simplemente filtre un par de bytes en ese caso especial.
Vulnerabilidad en kernel de Linux (CVE-2022-49201)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ibmvnic: se corrige la ejecución entre xmit y reset Existe una ejecución entre reset y las rutas de transmisión que puede provocar que ibmvnic_xmit() acceda a un scrq después de que se haya liberado en la ruta de reset. Puede provocar un bloqueo como: El kernel intentó leer la página del usuario (0): ¿intento de explotación? (uid: 0) ERROR: Desreferencia de puntero NULL del kernel en lectura en 0x00000000 Dirección de instrucción con error: 0xc0080000016189f8 Oops: Acceso del kernel al área defectuosa, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 Rastreo de llamadas: [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (no confiable) [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c9cfcc] sch_direct_xmit+0xec/0x330 [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0 [c000000000c00ad4] __dev_queue_xmit+0x394/0x730 [c008000002db813c] __bond_start_xmit+0x254/0x450 [enlace] [c008000002db8378] bond_start_xmit+0x40/0xc0 [enlace] [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c00ca4] __dev_queue_xmit+0x564/0x730 [c000000000cf97e0] neigh_hh_output+0xd0/0x180 [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0 [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0 [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0 [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0 [c000000000d2d984] tcp_retransmit_skb+0x34/0x130 [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0 [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330 [c000000000d317bc] tcp_write_timer+0x5c/0x200 [c000000000243270] call_timer_fn+0x50/0x1c0 [c000000000243704] __run_timers.part.0+0x324/0x460 [c000000000243894] run_timer_softirq+0x54/0xa0 [c000000000ea713c] __do_softirq+0x15c/0x3e0 [c000000000166258] __irq_exit_rcu+0x158/0x190 [c000000000166420] irq_exit+0x20/0x40 [c00000000002853c] timer_interrupt+0x14c/0x2b0 [c000000000009a00] decrementer_common_virt+0x210/0x220 --- interrupción: 900 La causa inmediata del bloqueo es el acceso a tx_scrq en el siguiente fragmento durante un reinicio, donde tx_scrq puede ser NULL o una dirección que pronto será inválida: ibmvnic_xmit() { ... tx_scrq = adaptador->tx_scrq[queue_num]; txq = netdev_get_tx_queue(netdev, queue_num); ind_bufp = &tx_scrq->ind_buf; if (test_bit(0, &adapter->resetting)) { ... } Pero más allá de eso, la llamada a ibmvnic_xmit() en sí no es segura durante un reinicio y la ruta de reinicio intenta evitar esto deteniendo la cola en ibmvnic_cleanup(). Sin embargo, justo después de que se detuviera la cola, una ibmvnic_complete_tx() en curso podría haber reiniciado la cola incluso mientras el reinicio estaba en progreso. Dado que la cola se reinició, podríamos recibir una llamada a ibmvnic_xmit() que luego puede acceder al tx_scrq incorrecto (u otros campos). Sin embargo, no podemos simplemente hacer que ibmvnic_complete_tx() verifique el bit ->resetting y omita el inicio de la cola. Esto puede funcionar en el "back-end" de un reinicio correcto que simplemente reinició la cola pero aún no borró el bit ->resetting. Si omitimos el reinicio de la cola debido a que ->resetting es verdadero, la cola permanecería detenida indefinidamente, lo que podría provocar tiempos de espera de transmisión. IOW ->resetting es demasiado amplio para este propósito. En su lugar, use un nuevo indicador que indique si las colas están activas o no. Solo las rutas de apertura/reinicio controlan cuándo están activas las colas. ibmvnic_complete_tx() y otros activan la cola solo si la cola está marcada como activa. Por lo tanto, tendremos: A. restablecer/abrir subproceso en ibmvnic_cleanup() y __ibmvnic_open() ->resetting = true ->tx_queues_active = false deshabilitar colas de transmisión ... ->tx_queues_active = true iniciar colas de transmisión B. Interrupción de transmisión en ibmvnic_complete_tx(): if (->tx_queues_active) netif_wake_subqueue(); Para garantizar que ->tx_queues_active y el estado de las colas sean cons ---truncado---
Vulnerabilidad en kernel de Linux (CVE-2022-49203)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Arreglar doble liberación durante el reinicio de la GPU en flujos de DC [Por qué] El problema solo ocurre durante la ruta del código de reinicio de la GPU. Primero hacemos una copia de seguridad del estado actual antes de confirmar 0 flujos internamente desde DM a DC. Esta copia de seguridad del estado contiene asignaciones de codificador de enlace válidas. DC borrará las asignaciones de codificador de enlace como parte del estado actual (pero no la copia de seguridad, ya que se copió antes de el commit) y liberará la referencia de flujo adicional que tenía. DC requiere que las asignaciones de codificador de enlace permanezcan borradas/inválidas antes de el commit. Dado que la copia de seguridad aún tiene asignaciones válidas, llamamos a la interfaz post reset para borrarlas. Esta rutina también libera la referencia adicional que tenía la interfaz de codificador de enlace, lo que da como resultado una doble liberación (y eventualmente una desreferencia de puntero NULL). [Cómo] Tendremos que hacer una confirmación de DC completa de todos modos después de reiniciar la GPU porque el conteo de transmisiones anteriormente llegó a 0. No necesitamos conservar la asignación que habíamos respaldado, así que simplemente copiamos la asignación del estado actual ahora limpio después de que se haya producido el reinicio con la nueva interfaz link_enc_cfg_copy().
Vulnerabilidad en kernel de Linux (CVE-2022-49206)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/mlx5: Se corrige la pérdida de memoria en el flujo de error para la rutina de evento de suscripción. En caso de que falle el segundo xa_insert(), no se libera el obj_event. Corrija el flujo de desenrollado de error para liberar esa memoria y evitar una pérdida de memoria.
CVE-2022-49207
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Corregir pérdida de memoria en sk_psock_queue_msg Si tcp_bpf_sendmsg se está ejecutando durante una operación de desmontaje, podemos poner en cola datos en la cola de mensajes de entrada mientras el desmontaje intenta liberarlos. sk1 (redireccionar sk2) sk2 ------------------- --------------- tcp_bpf_sendmsg() tcp_bpf_send_verdict() tcp_bpf_sendmsg_redir() bpf_tcp_ingress() sock_map_close() lock_sock() lock_sock() ... bloqueando sk_psock_stop sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED); release_sock(sk); lock_sock() sk_mem_charge() get_page() sk_psock_queue_msg() sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED); drop_sk_msg() release_sock() Mientras se usa drop_sk_msg(), el mensaje ha cargado la memoria del formulario sk mediante sk_mem_charge y tiene páginas sg que se deben colocar. Para solucionarlo, usamos sk_msg_free() y luego kfee() msg. Este problema puede causar la siguiente información: ADVERTENCIA: CPU: 0 PID: 9202 en net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0 Rastreo de llamadas: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xe5f/0xe90 ? sk_filter_trim_cap+0x10d/0x230 ? tcp_v4_do_rcv+0x161/0x250 tcp_v4_do_rcv+0x161/0x250 tcp_v4_rcv+0xc3a/0xce0 ip_protocol_deliver_rcu+0x3d/0x230 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0xfd/0x110 ? ip_protocol_deliver_rcu+0x230/0x230 ip_rcv+0xd6/0x100 ? ip_local_deliver+0x110/0x110 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0xa4/0x160 __napi_poll+0x29/0x1b0 net_rx_action+0x287/0x300 __do_softirq+0xff/0x2fc do_softirq+0x79/0x90 WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0 Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30
Vulnerabilidad en kernel de Linux (CVE-2022-49208)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/irdma: Evitar algunos desbordamientos de enteros Mi verificador estático se queja de que: drivers/infiniband/hw/irdma/ctrl.c:3605 irdma_sc_ceq_init() warn: can subtract underflow 'info->dev->hmc_fpm_misc.max_ceqs'? Parece que "info->dev->hmc_fpm_misc.max_ceqs" proviene del firmware en irdma_sc_parse_fpm_query_buf() así que, sí, existe la posibilidad de que sea cero. Incluso si confiamos en el firmware, es bastante fácil cambiar la condición como una medida de endurecimiento.
Vulnerabilidad en kernel de Linux (CVE-2022-49209)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: Se corrige la pérdida de memoria en tcp_bpf_sendmsg mientras sk msg está lleno Si tcp_bpf_sendmsg() se está ejecutando mientras sk msg está lleno. Cuando sk_msg_alloc() devuelve el error -ENOMEM, tcp_bpf_sendmsg() va a wait_for_memory. Si sk_msg_alloc() ha asignado memoria parcial, es decir, msg_tx->sg.size es mayor que osize después de sk_msg_alloc(), se produce una pérdida de memoria. Para solucionarlo, utilizamos sk_msg_trim() para liberar la memoria asignada y luego vamos a esperar memoria. Otras rutas de llamada de sk_msg_alloc() tienen un problema similar, como tls_sw_sendmsg(), así que maneje la lógica de sk_msg_trim dentro de sk_msg_alloc(), como sugirió Cong Wang. Este problema puede generar la siguiente información: ADVERTENCIA: CPU: 3 PID: 7950 en net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Seguimiento de llamadas: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae ADVERTENCIA: CPU: 3 PID: 2094 en net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Rastreo de llamadas: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30
Vulnerabilidad en kernel de Linux (CVE-2022-49210)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: MIPS: pgalloc: reparar pérdida de memoria causada por pgd_free() La página pgd es liberada por la implementación genérica pgd_free() desde el commit f9cb654cb550 ("asm-generic: pgalloc: proporcionar pgd_free() genérico"), sin embargo, hay escenarios en los que el sistema usa más de una página como la tabla pgd, en tales casos la implementación genérica pgd_free() ya no será aplicable. Por ejemplo, cuando PAGE_SIZE_4KB está habilitado y MIPS_VA_BITS_48 no está habilitado en un sistema de 64 bits, la macro "PGD_ORDER" se establecerá como "1", lo que provocará la asignación de dos páginas como la tabla pgd. Bueno, al mismo tiempo, la implementación genérica pgd_free() solo libera una página pgd, lo que provocará la pérdida de memoria. La pérdida de memoria se puede detectar fácilmente ejecutando el comando de shell: "while true; do ls > /dev/null; grep MemFree /proc/meminfo; done"
Vulnerabilidad en kernel de Linux (CVE-2022-49211)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mips: cdmm: Se corrige la pérdida de recuento de referencias en mips_cdmm_phys_base La función of_find_compatible_node() devuelve un puntero de nodo con el recuento de referencias incrementado. Deberíamos usar of_node_put() en él cuando termine. Agregue el of_node_put() faltante para liberar el recuento de referencias.
Vulnerabilidad en kernel de Linux (CVE-2022-49212)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mtd: rawnand: atmel: soluciona el problema de recuento de referencias en atmel_nand_controller_init El problema de recuento de referencias ocurre en varias rutas de manejo de errores en un objeto con recuento de referencias "nc->dmac". En estas rutas, la función simplemente devuelve el código de error, olvidando equilibrar el recuento de referencias de "nc->dmac", aumentado anteriormente por dma_request_channel(), lo que puede causar fugas de recuento de referencias. Arréglelo disminuyendo el recuento de referencias de un objeto específico en esas rutas de error.
Vulnerabilidad en kernel de Linux (CVE-2022-49213)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath10k: Se ha corregido la gestión de errores en ath10k_setup_msa_resources El puntero device_node es devuelto por of_parse_phandle() con refcount incrementado. Deberíamos usar of_node_put() en él cuando haya terminado. Esta función solo llama a of_node_put() en la ruta normal. Y provocará una fuga de refcount en la ruta de error.
Vulnerabilidad en kernel de Linux (CVE-2022-49215)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xsk: Corregir ejecución en el desmontaje del socket Corrige una ejecución en el código de desmontaje del socket xsk que puede provocar un splat de desreferencia de puntero NULL. El código de desvinculación xsk actual en xsk_unbind_dev() comienza estableciendo xs->state en XSK_UNBOUND, establece xs->dev en NULL y luego espera a que finalice cualquier procesamiento NAPI utilizandosynchronous_net(). Después de eso, el código de lanzamiento comienza a desmantelar el estado del socket y a liberar la memoria asignada. ERROR: desreferencia de puntero NULL del núcleo, dirección: 00000000000000c0 PGD 8000000932469067 P4D 8000000932469067 PUD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Contaminado: GI 5.16.0+ #2 Nombre del hardware: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 09/03/2015 RIP: 0010:__xsk_sendmsg+0x2c/0x690 [...] RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246 RAX: 00000000000000000 RBX: 00000000000000040 RCX: ffff8d5fc632d258 RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800 RBP: ffffa2348bd13db0 R08: 000000000000000 R09: 00007ffffffff000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800 R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000 FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0 Seguimiento de llamadas: ? aa_sk_perm+0x43/0x1b0 xsk_sendmsg+0xf0/0x110 sock_sendmsg+0x65/0x70 __sys_sendto+0x113/0x190 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x23/0x50 ? exit_to_user_mode_prepare+0xa5/0x1d0 __x64_sys_sendto+0x29/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Hay dos problemas con el código actual. Primero, establecer xs->dev en NULL antes de esperar a que todos los usuarios dejen de usar el socket no es correcto. La entrada a las funciones del plano de datos xsk_poll(), xsk_sendmsg() y xsk_recvmsg() están todas protegidas por una prueba de que xs->state está en el estado XSK_BOUND y, si no, regresa de inmediato. Pero un proceso podría haber pasado esta prueba pero aún no haber llegado al punto en el que usa xs->dev en el código. Mientras tanto, un segundo proceso que ejecuta xsk_unbind_dev() podría haber establecido xs->dev en NULL, lo que provocará un bloqueo para el primer proceso. La solución aquí es simplemente deshacerse de esta asignación NULL ya que ya no se usa. Antes de el commit 42fddcc7c64b ("xsk: usar miembro de estado para sincronización de socket"), xs->dev era el guardián para admitir procesos en las funciones del plano de datos, pero fue reemplazado por la variable de estado xs->state en el commit mencionada anteriormente. El segundo problema es quesynchronous_net() no espera a que se complete ningún proceso en xsk_poll(), xsk_sendmsg() o xsk_recvmsg(), lo que significa que el estado en el que se basan podría limpiarse prematuramente. Esto puede suceder cuando se llama al notificador (por ejemplo, al descargar el controlador) ya que utiliza xsk_unbind_dev(). Resuelva esto extendiendo la región crítica de RCU desde solo ndo_xsk_wakeup a todas las funciones mencionadas anteriormente, de modo que tanto la prueba de xs->state == XSK_BOUND como el último uso de cualquier miembro de xs estén cubiertos por la sección crítica de RCU. Esto garantizará que cuando se completesynchronous_net(), no habrá procesos restantes ejecutando xsk_poll(), xsk_sendmsg() o xsk_recvmsg() y el estado se puede limpiar de forma segura. Tenga en cuenta que debemos eliminar el bloqueo de RCU para la ruta de transmisión de skb, ya que utiliza funciones que podrían estar inactivas. Debido a esto, tenemos que volver a probar xs->state después de obtener el mutex que protege el código xmit de skb de, entre varias cosas, un xsk_unbind_dev() que se ejecuta desde el notificador al mismo tiempo.
CVE-2022-49216
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/tegra: Se corrige la pérdida de referencia en tegra_dsi_ganged_probe La referencia tomada por 'of_find_device_by_node()' debe liberarse cuando ya no se necesita. Agregue la llamada put_device() para corregir esto.
Vulnerabilidad en kernel de Linux (CVE-2022-49218)
Severidad: ALTA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/dp: Se corrige la lectura OOB al manejar el registro Post Cursor2 La matriz link_status no era lo suficientemente grande para leer el registro Post Cursor2 de solicitud de ajuste, por lo que se debe eliminar la función auxiliar común para evitar una lectura OOB, que se encontró con una compilación -Warray-bounds: drivers/gpu/drm/drm_dp_helper.c: En la función 'drm_dp_get_adjust_request_post_cursor': drivers/gpu/drm/drm_dp_helper.c:59:27: error: el subíndice 10 de la matriz está fuera de los límites de la matriz 'const u8[6]' {también conocido como 'const unsigned char[6]'} [-Werror=array-bounds] 59 | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/drm_dp_helper.c:147:51: nota: al hacer referencia a 'link_status' 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE], | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reemplace el único usuario del ayudante con una búsqueda y decodificación de código abierto, similar a drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.
Vulnerabilidad en kernel de Linux (CVE-2022-49219)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio/pci: se corrige la pérdida de memoria durante la transición de D3hot a D0 Si se establece 'vfio_pci_core_device::needs_pm_restore' (el dispositivo PCI no tiene el bit No_Soft_Reset establecido en su registro de configuración PMCSR), entonces el estado PCI actual se guardará localmente en 'vfio_pci_core_device::pm_save' durante la transición de D0 a D3hot y el mismo se restaurará durante la transición de D3hot a D0. Para guardar el estado PCI localmente, se utiliza pci_store_saved_state() y pci_load_and_free_saved_state() liberará la memoria asignada. Pero para los IOCTL relacionados con el reinicio, el controlador vfio llama a las API relacionadas con el reinicio de PCI que cambiarán internamente el estado de energía de PCI a D0. Por lo tanto, cuando el invitado se reanude, obtendrá el estado actual como D0 y omitirá la llamada a vfio_pci_set_power_state() para cambiar el estado de energía a D0 explícitamente. En este caso, la memoria apuntada por 'pm_save' nunca se liberará. En una secuencia maliciosa, el cambio de estado a D3hot seguido de VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET se puede ejecutar en un bucle y puede causar una situación de OOM. Este parche libera primero la memoria asignada anteriormente antes de sobrescribir 'pm_save' para evitar la pérdida de memoria mencionada.
Vulnerabilidad en kernel de Linux (CVE-2022-49221)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/dp: rellenar el conector de struct dp_panel DP CTS caso de prueba 4.2.2.6 tiene un edid válido con suma de comprobación incorrecta a propósito y espera que la fuente DP devuelva la suma de comprobación correcta. Durante la lectura del edid de drm, se calcula la suma de comprobación del edid correcta y se almacena en connector::real_edid_checksum. El problema es que struct dp_panel::connector nunca se asigna, en su lugar el conector se almacena en struct msm_dp::connector. Cuando ejecutamos el caso de prueba de prueba de cumplimiento 4.2.2.6 dp_panel_handle_sink_request() no tendrá un edid válido establecido en struct dp_panel::edid, por lo que intentaremos usar el conector real_edid_checksum y nos encontraremos con un error de desreferencia de puntero NULL porque el puntero del conector nunca se asigna. Cambios en V2: -- rellenar el conector del panel en msm_dp_modeset_init() en lugar de en dp_panel_read_sink_caps() Cambios en V3: -- eliminar el texto de confirmación de seguimiento de fallos del núcleo que no es de ayuda -- eliminar el cambio de nombre del parámetro dp_display a dp Cambios en V4: -- añadir más detalles al texto de confirmación Cambios en v10: -- agrupar en una serie Cambios en v11: -- eliminar drm/msm/dp: dp_link_parse_sink_count() retorna inmediatamente si se lee aux. Firmado por: Kuogee Hsieh
Vulnerabilidad en kernel de Linux (CVE-2022-49224)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: power: supply: ab8500: Se corrige la pérdida de memoria en ab8500_fg_sysfs_init kobject_init_and_add() toma la referencia incluso cuando falla. Según la documentación de kobject_init_and_add(): Si esta función devuelve un error, se debe llamar a kobject_put() para limpiar correctamente la memoria asociada con el objeto. Corrija la pérdida de memoria llamando a kobject_put().
Vulnerabilidad en kernel de Linux (CVE-2022-49225)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7921s: corrige una posible pérdida de memoria en mt7921_load_patch. Siempre libera datos de firmware al final de la rutina mt7921_load_patch.
Vulnerabilidad en kernel de Linux (CVE-2022-49230)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mt76: mt7915: corrige una posible pérdida de memoria en mt7915_mcu_add_sta. Libera skb asignado en la rutina mt7915_mcu_add_sta en caso de fallo.
Vulnerabilidad en kernel de Linux (CVE-2022-49231)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtw88: se corrige el desbordamiento de memoria y la pérdida de memoria durante hw_scan Anteriormente, asignábamos menos memoria de la que realmente se requería, la sobrescritura en el búfer hace que el módulo mm se queje y genere fallos de violación de acceso. Junto con posibles pérdidas de memoria cuando se devuelve antes. Solucione estos problemas pasando el tamaño correcto y el flujo de deinit adecuado.
Vulnerabilidad en kernel de Linux (CVE-2022-49232)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Corrige una desreferencia de puntero NULL en amdgpu_dm_connector_add_common_modes() En amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode() se asigna a mode y se pasa a drm_mode_probed_add() directamente después de eso. drm_mode_probed_add() pasa &mode->head a list_add_tail(), y hay una desreferencia de este en list_add_tail() sin recuperaciones, lo que podría provocar una desreferencia de puntero NULL en caso de fallo de amdgpu_dm_create_common_mode(). Corrige esto agregando una comprobación NULL de mode. Este error fue encontrado por un analizador estático. Las compilaciones con 'make allyesconfig' no muestran nuevas advertencias y nuestro analizador estático ya no advierte sobre este código.
Vulnerabilidad en kernel de Linux (CVE-2022-49233)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Llamar a dc_stream_release para eliminar la asignación de enc de enlace [Por qué] Un error de portabilidad provocó que la asignación de flujo para el enlace se mantuviera sin liberarse: una pérdida de memoria. [Cómo] Corrija el error de portabilidad agregando nuevamente dc_stream_release() previsto como parte del parche original.
Vulnerabilidad en kernel de Linux (CVE-2022-49235)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath9k_htc: corregir errores de valores no inicializados Syzbot informó de 2 errores de KMSAN en ath9k. Todos ellos son causados por la falta de inicialización de campos. En htc_connect_service(), svc_meta_len y pad no se inicializan. Según el código, parece que en el skb actual no hay datos de servicio, por lo que simplemente inicialice svc_meta_len a 0. htc_issue_send() no inicializa la matriz htc_frame_hdr::control. Basado en el código del firmware, lo inicializará por sí mismo, así que simplemente ponga a cero toda la matriz para que KMSAN esté contento Registros de errores: ERROR: KMSAN: kernel-usb-infoleak en usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [en línea] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [en línea] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit se creó en: slab_post_alloc_hook mm/slab.h:524 [en línea] slab_alloc_node mm/slub.c:3251 [en línea] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [en línea] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [en línea] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Los bytes 4-7 de 18 no están inicializados El acceso a la memoria de tamaño 18 comienza en ffff888027377e00 ERROR: KMSAN: kernel-usb-infoleak en usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [en línea] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [en línea] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit se creó en: slab_post_alloc_hook mm/slab.h:524 [en línea] slab_alloc_node mm/slub.c:3251 [en línea] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [en línea] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [en línea] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Los bytes 16-17 de 18 no están inicializados. El acceso a la memoria de tamaño 18 comienza en ffff888027377e00
Vulnerabilidad en kernel de Linux (CVE-2022-49237)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ath11k: agregar la función of_node_put() faltante para evitar fugas El puntero de nodo es devuelto por of_find_node_by_type() o por of_parse_phandle() con refcount incrementado. Llamar a of_node_put() para evitar la fuga de refcount.
Vulnerabilidad en kernel de Linux (CVE-2022-49239)
Severidad: MEDIA
Fecha de publicación: 26/02/2025
Fecha de última actualización: 18/03/2025
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: codecs: wcd934x: Agregar la falta de of_node_put() en wcd934x_codec_parse_data El puntero device_node es devuelto por of_parse_phandle() con refcount incrementado. Deberíamos usar of_node_put() en él cuando haya terminado. Esto es similar a el commit 64b92de9603f ("ASoC: wcd9335: corregir una referencia filtrada agregando la falta de of_node_put")
Vulnerabilidad en stesvis Frontpage category filter (CVE-2025-28867)
Severidad: MEDIA
Fecha de publicación: 11/03/2025
Fecha de última actualización: 18/03/2025
La vulnerabilidad de Cross-Site Request Forgery (CSRF) en stesvis Frontpage category filter permite Cross-Site Request Forgery. Este problema afecta al filtro de categorías de Frontpage desde n/d hasta la versión 1.0.2.
Vulnerabilidad en amocrm amoCRM WebForm (CVE-2025-28870)
Severidad: MEDIA
Fecha de publicación: 11/03/2025
Fecha de última actualización: 18/03/2025
Vulnerabilidad de neutralización incorrecta de la entrada durante la generación de páginas web ('Cross-site Scripting') en amocrm amoCRM WebForm permite XSS basado en DOM. Este problema afecta al formulario web de amoCRM desde n/d hasta la versión 1.1.