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 Linux (CVE-2026-23084)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: be2net: Corrección de desreferencia de puntero NULL en be_cmd_get_mac_from_list Cuando el argumento del parámetro pmac_id_valid de be_cmd_get_mac_from_list() se establece en falso, el controlador puede solicitar el PMAC_ID del firmware de la tarjeta de red, y esta función almacenará ese PMAC_ID en la dirección pmac_id proporcionada. Este es el contrato de esta función. Sin embargo, existe una ubicación dentro del controlador donde se están pasando tanto pmac_id_valid == false como pmac_id == NULL. Esto podría resultar en la desreferencia de un puntero NULL. Para resolver este problema, es necesario pasar la dirección de una variable auxiliar a la función.
Vulnerabilidad en Linux (CVE-2026-23085)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: irqchip/gic-v3-its: Evitar la truncación de direcciones de memoria En máquinas de 32 bits con CONFIG_ARM_LPAE, es posible que las asignaciones de memoria baja estén respaldadas por direcciones de memoria física por encima del límite de direcciones de 32 bits, como se descubrió al experimentar con configuraciones VMSPLIT más grandes. Esto causó que el modelo virt de qemu colapsara en el controlador GICv3, que asigna el objeto 'itt' usando GFP_KERNEL. Dado que toda la memoria por debajo del límite de direcciones físicas de 4 GB está en ZONE_DMA en esta configuración, kmalloc() por defecto utiliza direcciones más altas para ZONE_NORMAL, y el controlador ITS almacena la dirección física en una variable 'unsigned long' de 32 bits. Cambiar la variable itt_addr al tipo correcto phys_addr_t en su lugar, junto con todas las demás variables en este controlador que contienen una dirección física. El controlador gicv5 utiliza correctamente variables u64, mientras que todos los demás controladores irqchip no llaman a virt_to_phys o interfaces similares. Se espera que otros controladores de dispositivos tengan problemas similares, pero solucionar este es suficiente para arrancar un invitado basado en virtio.
Vulnerabilidad en Linux (CVE-2026-23086)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: vsock/virtio: limitar el crédito TX al tamaño del búfer local Los transportes virtio derivan su crédito TX directamente de peer_buf_alloc, que se establece a partir del valor SO_VM_SOCKETS_BUFFER_SIZE del punto final remoto. En el lado del host, esto significa que la cantidad de datos que estamos dispuestos a encolar para una conexión se escala por un tamaño de búfer elegido por el invitado, en lugar de la propia configuración vsock del host. Un invitado malicioso puede anunciar un búfer grande y leer lentamente, haciendo que el host asigne una cantidad correspondientemente grande de memoria sk_buff. Lo mismo ocurriría en el invitado con un host malicioso, ya que los transportes virtio comparten la misma base de código. Introducir una pequeña función auxiliar, virtio_transport_tx_buf_size(), que devuelve min(peer_buf_alloc, buf_alloc), y usarla dondequiera que consumamos peer_buf_alloc. Esto asegura que la ventana TX efectiva esté limitada tanto por el búfer anunciado del par como por nuestro propio buf_alloc (ya ajustado a buffer_max_size a través de SO_VM_SOCKETS_BUFFER_MAX_SIZE), de modo que un par remoto no pueda forzar al otro a encolar más datos de los permitidos por su propia configuración vsock. En un host Ubuntu 22.04 sin parchear (~64 GiB de RAM), ejecutar una PoC con 32 conexiones vsock de invitado anunciando 2 GiB cada una y leyendo lentamente llevó Slab/SUnreclaim de ~0.5 GiB a ~57 GiB; el sistema solo se recuperó después de terminar el proceso QEMU. Dicho esto, si la memoria de QEMU está limitada con cgroups, la memoria máxima utilizada estará limitada. Con este parche aplicado: Antes: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB Después de 32 conexiones de alto crédito: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB Solo un aumento de ~35 MiB en Slab/SUnreclaim, sin OOM del host, y el invitado permanece receptivo. Compatibilidad con transportes no virtio: - VMCI utiliza los controles de búfer AF_VSOCK para dimensionar sus pares de cola por socket basándose en los valores locales vsk->buffer_*; el lado remoto no puede ampliar esas colas más allá de lo que configuró el punto final local. - El transporte vsock de Hyper-V utiliza búferes de anillo VMBus de tamaño fijo y un límite de MTU; no hay un campo de crédito controlado por el par comparable a peer_buf_alloc, y el punto final remoto no puede impulsar la memoria del kernel en tránsito por encima de esos tamaños de anillo. - La ruta de bucle invertido reutiliza virtio_transport_common.c, por lo que naturalmente sigue la misma semántica que el transporte virtio. Este cambio se limita a virtio_transport_common.c y por lo tanto afecta a virtio-vsock, vhost-vsock y loopback, poniéndolos en línea con el comportamiento de 'ventana remota intersectada con política local' que VMCI y Hyper-V ya tienen efectivamente. [Stefano: pequeños ajustes después de cambiar el parche anterior] [Stefano: ajustar el mensaje de commit]
Vulnerabilidad en Linux (CVE-2026-23087)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: scsi: xen: scsiback: Corrección de posible fuga de memoria en scsiback_remove() La memoria asignada para la estructura vscsiblk_info en scsiback_probe() no es liberada en scsiback_remove(), lo que lleva a posibles fugas de memoria al eliminar, así como en las rutas de error de scsiback_probe(). Esto se corrige liberándola en scsiback_remove().
Vulnerabilidad en Linux (CVE-2026-23088)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: tracing: Corrección de un fallo al usar un campo de rastreo de pila sintético Al crear un evento sintético basado en un evento sintético existente que tenía un campo de rastreo de pila y el nuevo evento sintético usaba ese campo, ocurrió un fallo del kernel: ~# cd /sys/kernel/tracing ~# echo 's:stack unsigned long stack[];' > dynamic_events ~# echo 'hist:keys=prev_pid:s0=common_stacktrace if prev_state & 3' >> events/sched/sched_switch/trigger ~# echo 'hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)' >> events/sched/sched_switch/trigger Lo anterior crea un evento sintético que toma un rastreo de pila cuando una tarea se desprograma en un estado no en ejecución y pasa ese rastreo de pila al evento sched_switch cuando esa tarea se vuelve a programar. Activa el evento sintético 'stack' que tiene un rastreo de pila como su campo (llamado 'stack'). ~# echo 's:syscall_stack s64 id; unsigned long stack[];' >> dynamic_events ~# echo 'hist:keys=common_pid:s2=stack' >> events/synthetic/stack/trigger ~# echo 'hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)' >> events/raw_syscalls/sys_exit/trigger Lo anterior crea otro evento sintético llamado 'syscall_stack' que adjunta el primer evento sintético (stack) al evento de rastreo sys_exit y registra el rastreo de pila del evento stack con el ID de la llamada al sistema que está saliendo. Al habilitar este evento (o al usarlo en un histograma): ~# echo 1 > events/synthetic/syscall_stack/enable ¡Produce un fallo del kernel! BUG: unable to handle page fault for address: 0000000000400010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy) Debian 6.16.3-1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:trace_event_raw_event_synth+0x90/0x380 Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 <49> 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f RSP: 0018:ffffd2670388f958 EFLAGS: 00010202 RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0 RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50 R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010 R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90 FS: 00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0 Call Trace: ? __tracing_map_insert+0x208/0x3a0 action_trace+0x67/0x70 event_hist_trigger+0x633/0x6d0 event_triggers_call+0x82/0x130 trace_event_buffer_commit+0x19d/0x250 trace_event_raw_event_sys_exit+0x62/0xb0 syscall_exit_work+0x9d/0x140 do_syscall_64+0x20a/0x2f0 ? trace_event_raw_event_sched_switch+0x12b/0x170 ? save_fpregs_to_fpstate+0x3e/0x90 ? _raw_spin_unlock+0xe/0x30 ? finish_task_switch.isra.0+0x97/0x2c0 ? __rseq_handle_notify_resume+0xad/0x4c0 ? __schedule+0x4b8/0xd00 ? restore_fpregs_from_fpstate+0x3c/0x90 ? switch_fpu_return+0x5b/0xe0 ? do_syscall_64+0x1ef/0x2f0 ? do_fault+0x2e9/0x540 ? __handle_mm_fault+0x7d1/0xf70 ? count_memcg_events+0x167/0x1d0 ? handle_mm_fault+0x1d7/0x2e0 ? do_user_addr_fault+0x2c3/0x7f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e La razón es que el campo de rastreo de pila no está etiquetado como tal, y es tratado como un campo normal y no como un evento dinámico, que es lo que es. En trace_event_raw_ev
Vulnerabilidad en Linux (CVE-2026-23089)
Severidad: ALTA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: Corrección de uso después de liberación en snd_usb_mixer_free() Cuando snd_usb_create_mixer() falla, snd_usb_mixer_free() libera mixer->id_elems, pero los controles ya añadidos a la tarjeta siguen referenciando la memoria liberada. Más tarde, cuando se ejecuta snd_card_register(), la capa del mezclador OSS llama a sus retrollamadas y se produce una lectura de uso después de liberación. Traza de llamada: get_ctl_value+0x63f/0x820 sound/usb/mixer.c:411 get_min_max_with_quirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixer_ctl_feature_info+0x26b/0x490 sound/usb/mixer.c:1381 snd_mixer_oss_build_test+0x174/0x3a0 sound/core/oss/mixer_oss.c:887 ... snd_card_register+0x4ed/0x6d0 sound/core/init.c:923 usb_audio_probe+0x5ef/0x2a90 sound/usb/card.c:1025 Se corrige llamando a snd_ctl_remove() para todos los controles del mezclador antes de liberar id_elems. Guardamos el siguiente puntero primero porque snd_ctl_remove() libera el elemento actual.
Vulnerabilidad en Linux (CVE-2026-23090)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: slimbus: core: soluciona fuga de referencia de dispositivo al informar presencia Los dispositivos Slimbus pueden asignarse dinámicamente tras la recepción de mensajes de informe de presencia. Asegúrese de liberar la referencia tomada al buscar dispositivos ya registrados. Tenga en cuenta que esto requiere tomar una referencia adicional en caso de que el dispositivo aún no haya sido registrado y deba asignarse.
Vulnerabilidad en Linux (CVE-2026-23091)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: intel_th: corrige la fuga de dispositivo al abrir la salida Asegúrese de liberar la referencia tomada al buscar el dispositivo th durante la apertura del dispositivo de salida en caso de errores y al cerrar. Tenga en cuenta que una confirmación reciente corrigió la fuga en un par de rutas de error de open(), pero no en todas ellas, y la referencia sigue fugándose en una apertura exitosa.
Vulnerabilidad en Linux (CVE-2026-23092)
Severidad: ALTA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: iio: dac: ad3552r-hs: corrección de escritura fuera de límites en ad3552r_hs_write_data_source Cuando simple_write_to_buffer() tiene éxito, devuelve el número de bytes realmente copiados al búfer. El código usa incorrectamente 'count' como índice para la terminación nula en lugar de los bytes realmente copiados. Si count excede el tamaño del búfer, esto lleva a una escritura fuera de límites. Añadir una comprobación para count y usar el valor de retorno como índice. El error fue validado usando un módulo de demostración que refleja el código original y fue probado bajo QEMU. Patrón del error: - Un búfer de pila fijo de 64 bytes se llena usando count. - Si count > 64, el código aún hace buf[count] = '\0', causando una - escritura fuera de límites en la pila. Pasos para reproducir: - Abre el nodo del dispositivo. - Escribe 128 bytes de A en él. - Esto desborda el búfer de pila de 64 bytes y KASAN reporta el OOB. Encontrado mediante análisis estático. Esto es similar al commit da9374819eb3 ('iio: backend: corrección de escritura fuera de límites')
Vulnerabilidad en Linux (CVE-2026-23093)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ksmbd: smbd: corrección de dma_unmap_sg() nents Las funciones dma_unmap_sg() deben ser llamadas con los mismos nents que la dma_map_sg(), no el valor que la función de mapeo devolvió.
Vulnerabilidad en Linux (CVE-2026-23094)
Severidad: MEDIA
Fecha de publicación: 04/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: uacce: corregir la condición de verificación de sysfs de aislamiento uacce soporta la característica de aislamiento de dispositivos. Si el controlador implementa las funciones de callback isolate_err_threshold_read e isolate_err_threshold_write, uacce creará archivos sysfs ahora. Los usuarios pueden leer y configurar la política de aislamiento a través de sysfs. Actualmente, los archivos sysfs se crean siempre que estén presentes las funciones de callback isolate_err_threshold_read o isolate_err_threshold_write. Sin embargo, acceder a una función de callback inexistente puede causar que el sistema falle. Por lo tanto, interceptar la creación de sysfs si no existe ni lectura ni escritura; crear sysfs si se soporta cualquiera de los dos, pero interceptar las operaciones no soportadas en el sitio de la llamada.
Vulnerabilidad en Linux (CVE-2026-23130)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: solucionar interbloqueo al vaciar tramas de gestión El commit [1] convirtió el elemento de trabajo de transmisión de gestión en un trabajo wiphy. Dado que un trabajo wiphy solo puede ejecutarse bajo la protección del bloqueo wiphy, ocurre una condición de carrera en el siguiente escenario: 1. una trama de gestión se pone en cola para transmisión. 2. se llama a ath12k_mac_op_flush() para vaciar las tramas pendientes asociadas con el hardware (es decir, vif es NULL). Luego, en ath12k_mac_flush(), el proceso espera a que la transmisión finalice. 3. Dado que el bloqueo wiphy ha sido tomado por el proceso de vaciado, el elemento de trabajo de transmisión no tiene oportunidad de ejecutarse, de ahí el interbloqueo. Desde la perspectiva del usuario, este interbloqueo resulta en el siguiente problema: wlp8s0: autenticar con xxxxxx (dirección local=xxxxxx) wlp8s0: enviar autenticación a xxxxxx (intento 1/3) wlp8s0: autenticar con xxxxxx (dirección local=xxxxxx) wlp8s0: enviar autenticación a xxxxxx (intento 1/3) wlp8s0: autenticado wlp8s0: asociar con xxxxxx (intento 1/3) wlp8s0: abortando asociación con xxxxxx por elección local (Razón: 3=DEAUTH_LEAVING) ath12k_pci 0000:08:00.0: falló al vaciar la cola de transmisión de gestión, paquetes de gestión pendientes 1 El interbloqueo puede evitarse invocando wiphy_work_flush() para ejecutar proactivamente el elemento de trabajo en cola. Nótese que en realidad ya está presente en ath12k_mac_op_flush(), sin embargo, no protege el caso en que vif es NULL. Por lo tanto, se mueve hacia adelante para cubrir también este caso. Probado en: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Vulnerabilidad en Linux (CVE-2026-23131)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: platform/x86: hp-bioscfg: Corrección de advertencias de kobject para nombres de atributos vacíos El controlador hp-bioscfg intenta registrar kobjects con nombres vacíos cuando la BIOS de HP devuelve atributos con cadenas de nombre vacías. Esto causa múltiples advertencias del kernel: kobject: (00000000135fb5e6): ¡se intentó registrar con nombre vacío! WARNING: CPU: 14 PID: 3336 en lib/kobject.c:219 kobject_add_internal+0x2eb/0x310 Añadir validación en hp_init_bios_buffer_attribute() para verificar si el nombre del atributo está vacío después de analizarlo desde el búfer WMI. Si está vacío, registrar un mensaje de depuración y omitir el registro de ese atributo, permitiendo que el módulo continúe procesando otros atributos válidos.
Vulnerabilidad en Linux (CVE-2025-71201)
Severidad: ALTA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: netfs: Solución para el desbloqueo temprano de lectura de página con EOF en el medio La recopilación de resultados de lectura para lecturas en búfer parece adelantarse a la finalización de las subpeticiones bajo algunas circunstancias, como se puede ver en el siguiente fragmento de registro: 9p_client_res: cliente 18446612686390831168 response P9_TREAD tag 0 err 0 ... netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0 ... netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2 netfs_folio: i=157f3 ix=00004-00004 read-done netfs_folio: i=157f3 ix=00004-00004 read-unlock netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2 netfs_folio: i=157f3 ix=00005-00005 read-done netfs_folio: i=157f3 ix=00005-00005 read-unlock ... netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8 ... netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0 netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0 El 'cto=5fb2' indica la posición de archivo recopilada a la que hemos recogido resultados hasta ahora, pero aún nos quedan 0x4e bytes más, por lo que no deberíamos haber recopilado el folio ix=00005 todavía. La subpetición 'ZERO' que borra la cola ocurre después de que desbloqueamos el folio, permitiendo que la aplicación vea la cola no borrada a través de mmap. El problema es que netfs_read_unlock_folios() desbloqueará un folio en el que la cantidad de resultados de lectura recopilados alcanza la posición EOF, pero la subpetición ZERO se encuentra más allá de eso y, por lo tanto, ocurre después. Solucione esto cambiando la comprobación de fin para que siempre sea el fin del folio y nunca el fin del archivo. En el futuro, debería considerar borrar hasta el final del folio aquí en lugar de añadir una subpetición ZERO para hacer esto. Por otro lado, la subpetición ZERO puede ejecutarse en paralelo con una subpetición READ asíncrona. Además, la subpetición ZERO aún puede ser necesaria para, por ejemplo, manejar extensiones en un archivo ceph que no tienen ningún almacenamiento de respaldo y, por lo tanto, son implícitamente todo ceros. Esto se puede reproducir creando un archivo cuyo tamaño no se alinea con un límite de página, por ejemplo, 24998 (0x5fb2) bytes, y luego haciendo algo como: xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \ -c "mread -v 0 0x6000" /xfstest.test/x Los últimos 0x4e bytes deberían ser todos 00, pero si la cola no ha sido borrada todavía, es posible que vea basura allí. Esto se puede reproducir con kafs modificando el kernel para deshabilitar la llamada a netfs_read_subreq_progress() y para evitar que afs_issue_read() realice la llamada asíncrona para NETFS_READAHEAD. La reproducción se puede facilitar insertando un mdelay(100) en netfs_issue_read() para el caso de la subpetición ZERO. AFS y CIFS normalmente no suelen mostrar esto, ya que despachan operaciones READ de forma asíncrona, lo que permite que la subpetición ZERO termine primero. La operación READ de 9P es completamente síncrona, por lo que la subpetición ZERO siempre ocurrirá después. Sin embargo, no se ve todo el tiempo, porque la recopilación puede realizarse en un hilo de trabajo.
Vulnerabilidad en Linux (CVE-2025-71202)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: iommu/sva: invalidar entradas IOTLB obsoletas para el espacio de direcciones del kernel Se introduce una nueva interfaz IOMMU para vaciar las entradas de la caché de paginación IOTLB para el espacio de direcciones del kernel de la CPU. Esta interfaz se invoca desde el código de arquitectura x86 que gestiona las tablas de páginas combinadas de usuario y kernel, específicamente antes de que cualquier página de tabla de páginas del kernel sea liberada y reutilizada. Esto aborda el problema principal con vfree(), que es una ocurrencia común y puede ser activado por usuarios no privilegiados. Si bien esto resuelve el problema principal, no aborda un caso extremadamente raro relacionado con la desconexión de memoria que estaba presente como memoria reservada en el arranque, que no puede ser activado por usuarios no privilegiados. La discusión se puede encontrar en el enlace a continuación. Habilitar SVA en la arquitectura x86 ya que la IOMMU ahora puede recibir notificación para vaciar la caché de paginación antes de liberar las páginas de la tabla de páginas del kernel de la CPU.
Vulnerabilidad en Linux (CVE-2026-23132)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: drm/bridge: synopsys: dw-dp: corregir rutas de error de dw_dp_bind Corregir varios problemas en el manejo de errores de dw_dp_bind(): 1. Retorno faltante después de un fallo de drm_bridge_attach(): la función continuó la ejecución en lugar de devolver un error. 2. Fuga de recursos: drm_dp_aux_register() no es una función devm, por lo que drm_dp_aux_unregister() debe ser llamada en todas las rutas de error después de que el registro auxiliar tenga éxito. Esto afecta a los errores de: - drm_bridge_attach() - phy_init() - devm_add_action_or_reset() - platform_get_irq() - devm_request_threaded_irq() 3. Corrección de error: platform_get_irq() devuelve el número IRQ o un código de error negativo, pero la ruta de error estaba devolviendo ERR_PTR(ret) en lugar de ERR_PTR(dp->irq). Usar una etiqueta goto para la limpieza para asegurar un manejo de errores consistente.
Vulnerabilidad en Linux (CVE-2026-23133)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: wifi: ath10k: corrección del puntero dma_free_coherent() dma_alloc_coherent() asigna un búfer mapeado por DMA y almacena las direcciones en campos XXX_unaligned. Esas deberían ser reutilizadas al liberar el búfer en lugar de las direcciones alineadas.
Vulnerabilidad en Linux (CVE-2026-23134)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: slab: corrección de la verificación de contexto de kmalloc_nolock() para PREEMPT_RT En kernels PREEMPT_RT, local_lock se convierte en un bloqueo de suspensión. La verificación actual en kmalloc_nolock() solo verifica que no estamos en un contexto NMI o de IRQ dura, pero omite el caso en que la preemption está deshabilitada. Cuando un programa BPF se ejecuta desde un tracepoint con la preemption deshabilitada (preempt_count > 0), kmalloc_nolock() procede a llamar a local_lock_irqsave(), que intenta adquirir un bloqueo de suspensión, lo que desencadena: BUG: función de suspensión llamada desde contexto inválido in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6128 preempt_count: 2, esperado: 0 Solucione esto verificando !preemptible() en PREEMPT_RT, lo que expresa directamente la restricción de que no podemos tomar un bloqueo de suspensión cuando la preemption está deshabilitada. Esto abarca las verificaciones anteriores para contextos NMI e IRQ dura, al mismo tiempo que detecta casos en los que la preemption está deshabilitada.
Vulnerabilidad en Linux (CVE-2026-23135)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: wifi: ath12k: corrección del puntero dma_free_coherent() dma_alloc_coherent() asigna un búfer mapeado por DMA y almacena las direcciones en campos XXX_unaligned. Esas deberían ser reutilizadas al liberar el búfer en lugar de las direcciones alineadas.
Vulnerabilidad en Linux (CVE-2026-23136)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: libceph: restablecer el estado de lectura dispersa en osd_fault() Cuando ocurre un fallo, la conexión es abandonada, restablecida, y cualquier operación pendiente es reintentada. El cliente OSD rastrea el progreso de una respuesta de lectura dispersa usando una máquina de estados separada, en gran medida independiente del estado del mensajero. Si se pierde una conexión a mitad de la carga útil o la máquina de estados de lectura dispersa devuelve un error, el estado de lectura dispersa no se restablece. El cliente OSD interpretará entonces el comienzo de una nueva respuesta como la continuación de la antigua. Si esto hace que la maquinaria de lectura dispersa entre en un estado de fallo, puede que nunca se recupere, produciendo bucles como: libceph: [0] got 0 extents libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read libceph: data len 142248331 != extent len 0 libceph: osd0 (1)...:6801 socket error on read Por lo tanto, restablecer el estado de lectura dispersa en osd_fault(), asegurando que los reintentos comiencen desde un estado limpio.
Vulnerabilidad en Linux (CVE-2026-23137)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: of: unittest: Corrección de fuga de memoria en unittest_data_add() En unittest_data_add(), si of_resolve_phandles() falla, el unittest_data asignado no se libera, lo que provoca una fuga de memoria. Esto se soluciona usando un ayudante de limpieza basado en el ámbito __free(kfree) para la limpieza automática de recursos. Esto asegura que unittest_data se libera automáticamente cuando sale del ámbito en rutas de error. Para la ruta de éxito, use retain_and_null_ptr() para transferir la propiedad de la memoria al árbol de dispositivos y evitar la doble liberación.
Vulnerabilidad en Linux (CVE-2026-23138)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: rastreo: Añadir protección contra recursión en la grabación de trazas de pila del kernel Se informó de un error sobre una recursión infinita causada por el rastreo de los eventos rcu con el disparador de traza de pila del kernel habilitado. El código de traza de pila volvió a llamar a RCU, que luego volvió a llamar a la traza de pila. Expandir la protección contra recursión de ftrace para añadir un conjunto de bits para proteger los eventos de la recursión. Cada bit representa el contexto en el que se encuentra el evento (normal, softirq, interrupción y NMI). Hacer que el código de traza de pila use el contexto de interrupción para proteger contra la recursión. Nota, el error mostró un problema tanto en el código RCU como en el código de traza de pila de rastreo. Esto solo aborda el lado de la traza de pila de rastreo del error. La corrección de RCU se manejará por separado.
Vulnerabilidad en Linux (CVE-2026-23139)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: netfilter: nf_conncount: actualizar last_gc solo cuando se ha realizado la GC Actualmente, last_gc se actualiza cada vez que se rastrea una nueva conexión, lo que significa que se actualiza incluso si no se realizó una GC. Con una tasa de paquetes suficientemente alta, es posible eludir siempre la GC, haciendo que la lista crezca infinitamente. Actualizar el valor de last_gc solo cuando se ha realizado realmente una GC.
Vulnerabilidad en Linux (CVE-2026-23140)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: bpf, test_run: Restar el tamaño de xdp_frame del tamaño de metadatos permitido La estructura xdp_frame ocupa parte del headroom del frame XDP, limitando el tamaño de los metadatos. Sin embargo, en bpf_test_run, no tenemos esto en cuenta, lo que hace posible que el userspace suministre un tamaño de metadatos que es demasiado grande (ocupando todo el headroom). Si el userspace suministra un tamaño de metadatos tan grande en modo de paquete en vivo, la llamada a xdp_update_frame_from_buff() en la llamada a xdp_test_run_init_page() fallará, después de lo cual la transmisión de paquetes procede con una estructura de frame no inicializada, lo que lleva a las 'Cosas Malas' habituales. El commit en la etiqueta Fixes corrigió un error relacionado donde la segunda comprobación en xdp_update_frame_from_buff() podría fallar, pero no añadió ninguna restricción adicional sobre el tamaño de los metadatos. Completar la corrección añadiendo una comprobación adicional sobre el tamaño de los metadatos. Reordenar ligeramente las comprobaciones para hacer la lógica más clara y añadir un comentario.
Vulnerabilidad en Linux (CVE-2026-23141)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: btrfs: send: verificar extents en línea en range_is_hole_in_parent() Antes de acceder al campo disk_bytenr de un elemento de extent de archivo, necesitamos verificar si estamos tratando con un extent en línea. Esto se debe a que para los extents en línea, sus datos comienzan en el desplazamiento del campo disk_bytenr. Así que acceder al disk_bytenr significa que estamos accediendo a datos en línea o, en caso de que los datos en línea sean menores de 8 bytes, podemos realmente causar un acceso a memoria inválido si este elemento de extent en línea es el primer elemento en la hoja o acceder a metadatos de otros elementos.
Vulnerabilidad en Linux (CVE-2026-23142)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: mm/damon/sysfs-scheme: limpieza de los subdirectorios de access_pattern en caso de fallo en la configuración del directorio del esquema Cuando la configuración de un directorio sysfs de DAMON con esquema DAMOS falla después de la configuración del directorio access_pattern/, los subdirectorios del directorio access_pattern/ no se limpian. Como resultado, la interfaz sysfs de DAMON queda casi rota hasta que el sistema se reinicia, y la memoria del directorio no eliminado se fuga. Limpiar los directorios en caso de tales fallos.
Vulnerabilidad en Linux (CVE-2026-23143)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: virtio_net: Corrige un error de desalineación en la estructura virtnet_info Usa el nuevo ayudante TRAILING_OVERLAP() para corregir un error de desalineación junto con la siguiente advertencia: drivers/net/virtio_net.c:429:46: advertencia: la estructura que contiene un miembro de array flexible no está al final de otra estructura [-Wflex-array-member-not-at-end] Este ayudante crea una unión entre un miembro de array flexible (FAM) y un conjunto de miembros que de otro modo lo seguirían (en este caso 'u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];'). Esto superpone los miembros finales (rss_hash_key_data) sobre el FAM (hash_key_data) mientras mantiene el FAM y el inicio de los MIEMBROS alineados. El static_assert() asegura que esta alineación se mantenga. Nótese que debido al relleno de cola en la estructura flexible 'struct virtio_net_rss_config_trailer', 'rss_trailer.hash_key_data' (en el desplazamiento 83 en la estructura virtnet_info) y 'rss_hash_key_data' (en el desplazamiento 84 en la estructura virtnet_info) están desalineados por un byte. Ver a continuación: ``` struct virtio_net_rss_config_trailer { __le16 max_tx_vq; /* 0 2 */ __u8 hash_key_length; /* 2 1 */ __u8 hash_key_data[]; /* 3 0 */ /* size: 4, cachelines: 1, members: 3 */ /* padding: 1 */ /* last cacheline: 4 bytes */ }; ``` ``` struct virtnet_info { ... struct virtio_net_rss_config_trailer rss_trailer; /* 80 4 */ /* XXX last struct has 1 byte of padding */ u8 rss_hash_key_data[40]; /* 84 40 */ ... /* size: 832, cachelines: 13, members: 48 */ /* sum members: 801, holes: 8, sum holes: 31 */ /* paddings: 2, sum paddings: 5 */ }; ``` Después de los cambios, esos miembros están correctamente alineados en el desplazamiento 795: ``` struct virtnet_info { ... union { struct virtio_net_rss_config_trailer rss_trailer; /* 792 4 */ struct { unsigned char __offset_to_hash_key_data[3]; /* 792 3 */ u8 rss_hash_key_data[40]; /* 795 40 */ }; /* 792 43 */ }; /* 792 44 */ ... /* size: 840, cachelines: 14, members: 47 */ /* sum members: 801, holes: 8, sum holes: 35 */ /* padding: 4 */ /* paddings: 1, sum paddings: 4 */ /* last cacheline: 8 bytes */ }; ``` Como resultado, la clave RSS pasada al dispositivo se desplaza 1 byte: el último byte se corta y, en su lugar, se añade un byte (posiblemente no inicializado) al principio. Como última nota, 'struct virtio_net_rss_config_hdr *rss_hdr;' también se mueve al final, ya que parece que esos tres miembros deberían permanecer juntos. :)
Vulnerabilidad en Linux (CVE-2026-23144)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: mm/damon/sysfs: limpieza de subdirectorios de attrs en caso de fallo en la configuración del directorio de contexto Cuando la configuración de un directorio sysfs de DAMON de contexto falla después de la configuración del directorio attrs/, los subdirectorios del directorio attrs/ no se limpian. Como resultado, la interfaz sysfs de DAMON queda casi rota hasta que el sistema se reinicia, y la memoria para el directorio no eliminado se fuga. Limpiar los directorios en caso de tales fallos.
Vulnerabilidad en Linux (CVE-2026-23145)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corregir la fuga de iloc.bh en ext4_xattr_inode_update_ref La rama de error para ext4_xattr_inode_update_ref olvidó liberar el refcount para iloc.bh. Esto se encontró al revisar el código.
Vulnerabilidad en Linux (CVE-2026-23146)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: Bluetooth: hci_uart: corrección de desreferencia de puntero nulo en hci_uart_write_work hci_uart_set_proto() establece HCI_UART_PROTO_INIT antes de llamar a hci_uart_register_dev(), que llama a proto->open() para inicializar hu->priv. Sin embargo, si una activación de escritura TTY ocurre durante esta ventana, hci_uart_tx_wakeup() puede programar write_work antes de que hu->priv sea inicializado, lo que lleva a una desreferencia de puntero NULL en hci_uart_write_work() cuando proto->dequeue() accede a hu->priv. La condición de carrera es: CPU0 CPU1 ---- ---- hci_uart_set_proto() set_bit(HCI_UART_PROTO_INIT) hci_uart_register_dev() activación de escritura tty hci_uart_tty_wakeup() hci_uart_tx_wakeup() schedule_work(&hu->write_work) proto->open(hu) // inicializa hu->priv hci_uart_write_work() hci_uart_dequeue() proto->dequeue(hu) // accede a hu->priv (¡NULL!) Esto se soluciona moviendo set_bit(HCI_UART_PROTO_INIT) después de que proto->open() se complete con éxito, asegurando que hu->priv esté inicializado antes de que se pueda programar cualquier trabajo.
Vulnerabilidad en Linux (CVE-2026-23147)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: btrfs: zlib: corregir la fuga de folio en la aceleración de hardware S390 [BUG] Después del commit aa60fe12b4f4 ('btrfs: zlib: refactorizar la preparación del búfer de aceleración de hardware S390x'), ya no liberamos el folio de la caché de páginas del folio devuelto por btrfs_compress_filemap_get_folio() para la ruta de aceleración de hardware S390. [CAUSA] Antes de ese commit, llamábamos a kumap_local() y folio_put() después de manejar cada folio. Aunque el momento no es ideal (libera el folio anterior al principio del bucle y depende de una limpieza adicional fuera del bucle), al menos maneja la liberación del folio correctamente. Mientras que el código refactorizado es más fácil de leer, carece de la llamada para liberar el folio del filemap. [SOLUCIÓN] Añadir el folio_put() faltante para copy_data_into_buffer().
Vulnerabilidad en Linux (CVE-2026-23148)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: nvmet: corregir condición de carrera en nvmet_bio_done() que lleva a una desreferencia de puntero NULL Existe una condición de carrera en nvmet_bio_done() que puede causar una desreferencia de puntero NULL en blk_cgroup_bio_start(): 1. nvmet_bio_done() es llamada cuando un bio se completa 2. nvmet_req_complete() es llamada, lo que invoca req->ops->queue_response(req) 3. La devolución de llamada queue_response puede volver a encolar y volver a enviar la misma solicitud 4. El reenvío reutiliza el mismo inline_bio de nvmet_req 5. Mientras tanto, nvmet_req_bio_put() (llamada después de nvmet_req_complete) invoca bio_uninit() para inline_bio, lo que establece bio->bi_blkg en NULL 6. El bio reenviado entra en submit_bio_noacct_nocheck() 7. blk_cgroup_bio_start() desreferencia bio->bi_blkg, causando un fallo: ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000028 #PF: acceso de lectura de supervisor en modo kernel RIP: 0010:blk_cgroup_bio_start+0x10/0xd0 Rastro de Llamada: submit_bio_noacct_nocheck+0x44/0x250 nvmet_bdev_execute_rw+0x254/0x370 [nvmet] process_one_work+0x193/0x3c0 worker_thread+0x281/0x3a0 Corregir esto reordenando nvmet_bio_done() para llamar a nvmet_req_bio_put() ANTES de nvmet_req_complete(). Esto asegura que el bio se limpie antes de que la solicitud pueda ser reenviada, previniendo la condición de carrera.
Vulnerabilidad en Linux (CVE-2026-23149)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: drm: No permitir que el espacio de usuario active advertencias del kernel en drm_gem_change_handle_ioctl() Dado que los identificadores GEM bo son u32 en la uapi y la implementación interna utiliza idr_alloc() que usa rangos int, pasar un nuevo identificador mayor que INT_MAX desencadena trivialmente una advertencia del kernel: idr_alloc(): ... if (WARN_ON_ONCE(start < 0)) return -EINVAL; ... Se soluciona rechazando los nuevos identificadores superiores a INT_MAX y al mismo tiempo haciendo más obvio el cálculo del límite final al moverlo al dominio int.
Vulnerabilidad en Linux (CVE-2026-23150)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: nfc: llcp: Corrección de fuga de memoria en nfc_llcp_send_ui_frame(). syzbot informó de varias fugas de memoria relacionadas con NFC, struct nfc_llcp_sock, sk_buff, nfc_dev, etc. [0] El registro principal sugirió que nfc_llcp_send_ui_frame() falló al asignar skb debido a que sock_error(sk) era -ENXIO. ENXIO es establecido por nfc_llcp_socket_release() cuando struct nfc_llcp_local es destruido por local_cleanup(). El problema es que no hay sincronización entre nfc_llcp_send_ui_frame() y local_cleanup(), y skb podría ser puesto en local->tx_queue después de que fuera purgado en local_cleanup(): CPU1 CPU2 ---- ---- nfc_llcp_send_ui_frame() local_cleanup() |- do { ' |- pdu = nfc_alloc_send_skb(..., &err) | . | |- nfc_llcp_socket_release(local, false, ENXIO); | |- skb_queue_purge(&local->tx_queue); | | ' | |- skb_queue_tail(&local->tx_queue, pdu); | ... | |- pdu = nfc_alloc_send_skb(..., &err) | ^._________________________________.' local_cleanup() es llamado para struct nfc_llcp_local solo después de que nfc_llcp_remove_local() lo desvincula de llcp_devices. Si mantenemos local->tx_queue.lock entonces, podemos sincronizar el hilo y nfc_llcp_send_ui_frame(). Hagamos eso y verifiquemos list_empty(&local->list) antes de encolar skb en local->tx_queue en nfc_llcp_send_ui_frame(). [0]: [ 56.074943][ T6096] llcp: nfc_llcp_send_ui_frame: Could not allocate PDU (error=-6) [ 64.318868][ T5813] kmemleak: 6 new suspected memory leaks (see /sys/kernel/debug/kmemleak) BUG: memory leak unreferenced object 0xffff8881272f6800 (size 1024): comm 'syz.0.17', pid 6096, jiffies 4294942766 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 27 00 03 40 00 00 00 00 00 00 00 00 00 00 00 00 '..@............ backtrace (crc da58d84d): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] __do_kmalloc_node mm/slub.c:5645 [inline] __kmalloc_noprof+0x3e3/0x6b0 mm/slub.c:5658 kmalloc_noprof include/linux/slab.h:961 [inline] sk_prot_alloc+0x11a/0x1b0 net/core/sock.c:2239 sk_alloc+0x36/0x360 net/core/sock.c:2295 nfc_llcp_sock_alloc+0x37/0x130 net/nfc/llcp_sock.c:979 llcp_sock_create+0x71/0xd0 net/nfc/llcp_sock.c:1044 nfc_sock_create+0xc9/0xf0 net/nfc/af_nfc.c:31 __sock_create+0x1a9/0x340 net/socket.c:1605 sock_create net/socket.c:1663 [inline] __sys_socket_create net/socket.c:1700 [inline] __sys_socket+0xb9/0x1a0 net/socket.c:1747 __do_sys_socket net/socket.c:1761 [inline] __se_sys_socket net/socket.c:1759 [inline] __x64_sys_socket+0x1b/0x30 net/socket.c:1759 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f BUG: memory leak unreferenced object 0xffff88810fbd9800 (size 240): comm 'syz.0.17', pid 6096, jiffies 4294942850 hex dump (first 32 bytes): 68 f0 ff 08 81 88 ff ff 68 f0 ff 08 81 88 ff ff h.......h....... 00 00 00 00 00 00 00 00 00 68 2f 27 81 88 ff ff .........h/'.... backtrace (crc 6cc652b1): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4979 [inline] slab_alloc_node mm/slub.c:5284 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5336 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/sk ---truncated---
Vulnerabilidad en Linux (CVE-2026-23151)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: Bluetooth: MGMT: Corrección de fuga de memoria en set_ssp_complete Corrige la fuga de memoria en set_ssp_complete() donde las estructuras mgmt_pending_cmd no son liberadas después de ser eliminadas de la lista de pendientes. El commit 302a1f674c00 ('Bluetooth: MGMT: Corrige posibles UAFs') reemplazó las llamadas a mgmt_pending_foreach() con el manejo individual de comandos, pero omitió añadir llamadas a mgmt_pending_free() tanto en las rutas de error como de éxito de set_ssp_complete(). Otras funciones de completado como set_le_complete() fueron corregidas correctamente en el mismo commit. Esto causa una fuga de memoria de la estructura mgmt_pending_cmd y sus datos de parámetros asociados para cada comando SSP que se completa. Añade las llamadas faltantes a mgmt_pending_free(cmd) en ambas rutas de código para corregir la fuga de memoria. También corrige el mismo problema en set_advertising_complete().
Vulnerabilidad en Linux (CVE-2026-23152)
Severidad: MEDIA
Fecha de publicación: 14/02/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: wifi: mac80211: decodificar correctamente TTLM con mapa de enlace predeterminado Los elementos de Mapeo de TID a Enlace (TTLM) no contienen ningún indicador de presencia de mapeo de enlace si se utiliza un mapeo predeterminado y el análisis debe omitirse. Tenga en cuenta que los puntos de acceso no deberían informar explícitamente un TTLM anunciado con un mapeo predeterminado, ya que ese es el mapeo implícito si el elemento no está incluido; este es incluso el caso al volver al mapeo predeterminado. Sin embargo, mac80211 analizaría incorrectamente la trama y también leería un byte más allá del final del elemento.
Vulnerabilidad en el kernel de Linux (CVE-2026-23230)
Severidad: MEDIA
Fecha de publicación: 18/02/2026
Fecha de última actualización: 17/03/2026
Se ha resuelto la siguiente vulnerabilidad en el kernel de Linux: smb: cliente: dividir los campos de bits de cached_fid para evitar condiciones de carrera RMW de bytes compartidos is_open, has_lease y on_list se almacenan en el mismo byte de campo de bits en la estructura cached_fid, pero se actualizan en diferentes rutas de código que pueden ejecutarse concurrentemente. Las asignaciones de campos de bits generan operaciones de lectura-modificación-escritura de bytes (p. ej., 'orb $mask, addr' en x86_64), por lo que al actualizar una bandera (flag) se puede restaurar valores obsoletos de las otras. Una posible intercalación es: CPU1: carga el byte antiguo (has_lease=1, on_list=1) CPU2: borra ambas banderas (almacena 0) CPU1: almacena RMW (old | IS_OPEN) -> reintroduce los bits borrados Para evitar esta clase de condiciones de carrera, hay que convertir estas banderas a campos bool separados.
Vulnerabilidad en Red Hat (CVE-2025-13327)
Severidad: MEDIA
Fecha de publicación: 27/02/2026
Fecha de última actualización: 17/03/2026
Se encontró una falla en uv. Esta vulnerabilidad permite a un atacante ejecutar código malicioso durante la resolución o instalación de paquetes a través de archivos ZIP (Paquete de Información Comprimida) especialmente manipulados que explotan diferenciales de análisis, requiriendo interacción del usuario para instalar un paquete controlado por el atacante.
Vulnerabilidad en Red Hat (CVE-2025-9572)
Severidad: MEDIA
Fecha de publicación: 27/02/2026
Fecha de última actualización: 17/03/2026
Una falla de autorización en la API GraphQL de Foreman permite a usuarios con bajos privilegios acceder a metadatos más allá de sus permisos asignados. A diferencia de la API REST, que aplica correctamente los controles de acceso, el endpoint GraphQL no aplica un filtrado adecuado, lo que lleva a una omisión de autorización.
Vulnerabilidad en Linux (CVE-2026-23231)
Severidad: ALTA
Fecha de publicación: 04/03/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: netfilter: nf_tables: corrige uso después de liberación en nf_tables_addchain() nf_tables_addchain() publica la cadena en table->chains a través de list_add_tail_rcu() (en nft_chain_add()) antes de registrar los ganchos. Si nf_tables_register_hook() falla entonces, la ruta de error llama a nft_chain_del() (list_del_rcu()) seguido de nf_tables_chain_destroy() sin un período de gracia RCU intermedio. Esto crea dos condiciones de uso después de liberación: 1) Plano de control: nf_tables_dump_chains() recorre table->chains bajo rcu_read_lock(). Un volcado concurrente aún puede estar recorriendo la cadena cuando la ruta de error la libera. 2) Ruta de paquetes: para NFPROTO_INET, nf_register_net_hook() instala brevemente el gancho IPv4 antes de que falle el registro de IPv6. Los paquetes que entran en nft_do_chain() a través del gancho IPv4 transitorio aún pueden estar desreferenciando chain->blob_gen_X cuando la ruta de error libera la cadena. Añadir synchronize_rcu() entre nft_chain_del() y la destrucción de la cadena para que todos los lectores RCU -- tanto los hilos de volcado como la evaluación de paquetes en curso -- hayan terminado antes de que la cadena sea liberada.
Vulnerabilidad en Linux (CVE-2025-71238)
Severidad: ALTA
Fecha de publicación: 04/03/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: scsi: qla2xxx: Solución para bsg_done() que causa doble liberación Kernel panic observado en el sistema, [5353358.825191] BUG: unable a handle page fault para address: ff5f5e897b024000 [5353358.825194] #PF: supervisor write access in kernel mode [5353358.825195] #PF: error_code(0x0002) - not-present page [5353358.825196] PGD 100006067 P4D 0 [5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI [5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G W L ------- --- 5.14.0-503.34.1.el9_5.x86_64 #1 [5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025 [5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10 [5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246 [5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000 [5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000 [5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000 [5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090 [5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000 [5353358.825218] FS: 00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000 [5353358.825219] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0 [5353358.825221] PKRU: 55555554 [5353358.825222] Call Trace: [5353358.825223] [5353358.825224] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825229] ? show_trace_log_lvl+0x1c4/0x2df [5353358.825232] ? sg_copy_buffer+0xc8/0x110 [5353358.825236] ? __die_body.cold+0x8/0xd [5353358.825238] ? page_fault_oops+0x134/0x170 [5353358.825242] ? kernelmode_fixup_or_oops+0x84/0x110 [5353358.825244] ? exc_page_fault+0xa8/0x150 [5353358.825247] ? asm_exc_page_fault+0x22/0x30 [5353358.825252] ? memcpy_erms+0x6/0x10 [5353358.825253] sg_copy_buffer+0xc8/0x110 [5353358.825259] qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx] [5353358.825317] qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx] La mayoría de las rutinas en qla_bsg.c llaman a bsg_done() solo para casos de éxito. Sin embargo, algunas la invocan también para casos de fallo, lo que lleva a una doble liberación. Validar antes de llamar a bsg_done().
Vulnerabilidad en Linux (CVE-2026-23232)
Severidad: MEDIA
Fecha de publicación: 04/03/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revertir «f2fs: bloqueo de caché/escritura dio durante f2fs_enable_checkpoint()». Esto revierte la confirmación 196c81fdd438f7ac429d5639090a9816abb9760a. El parche original puede causar el siguiente bloqueo, reviertelo. write remount - write_begin - lock_page --- lock A - prepare_write_begin - f2fs_map_lock - f2fs_enable_checkpoint - down_write (cp_enable_rwsem) --- bloqueo B - sync_inode_sb - writepages - lock_page --- bloqueo A - down_read(cp_enable_rwsem) --- bloqueo A
Vulnerabilidad en Linux (CVE-2026-23233)
Severidad: ALTA
Fecha de publicación: 04/03/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: f2fs: corrección para evitar mapear un bloque físico incorrecto para el archivo de intercambio Xiaolong Guo informó de un error de f2fs en bugzilla [1] [1] HTTPS://bugzilla.kernel.org/show_bug.cgi?id=220951 Citado: Cuando se utiliza la prueba de estrés de intercambio de stress-ng en el sistema de archivos F2FS con kernel 6.6+, el sistema experimenta corrupción de datos que lleva a una de las siguientes situaciones: 1 errores de corrupción de dm-verity y reinicio del dispositivo 2 errores de corrupción de nodo F2FS y cuelgues de arranque El problema ocurre específicamente cuando: 1 Se utiliza el sistema de archivos F2FS (ext4 no se ve afectado) 2 El tamaño del archivo de intercambio es menor que el tamaño de sección de F2FS (2MB) 3 El archivo de intercambio tiene un diseño físico fragmentado (múltiples extensiones no contiguas) 4 La versión del kernel es 6.6+ (6.1 no se ve afectada) La causa raíz está en la función check_swap_activate() en fs/f2fs/data.c. Cuando la primera extensión de un archivo de intercambio pequeño (< 2MB) no está alineada con los límites de sección, la función lo trata incorrectamente como la última extensión, fallando en mapear extensiones subsiguientes. Esto resulta en una creación incorrecta de swap_extent donde solo la primera extensión es mapeada, causando que las escrituras de intercambio subsiguientes sobrescriban ubicaciones físicas incorrectas (datos de otros archivos). Pasos para Reproducir 1 Configurar un dispositivo con una partición de datos de usuario formateada en F2FS 2 Compilar stress-ng desde HTTPS://github.com/ColinIanKing/stress-ng 3 Ejecutar la prueba de estrés de intercambio: (dispositivos Android) adb shell 'cd /data/stressng; ./stress-ng-64 --metrics-brief --timeout 60 --swap 0' Registro: 1 Ftrace muestra que en el kernel 6.6, solo la primera extensión se mapea durante la segunda llamada a f2fs_map_blocks en check_swap_activate(): stress-ng-swap-8990: f2fs_map_blocks: ino=11002, file offset=0, start blkaddr=0x43143, len=0x1 (Solo 4KB mapeados, no el archivo de intercambio completo) 2 en el kernel 6.1, ambas extensiones se mapean correctamente: stress-ng-swap-5966: f2fs_map_blocks: ino=28011, file offset=0, start blkaddr=0x13cd4, len=0x1 stress-ng-swap-5966: f2fs_map_blocks: ino=28011, file offset=1, start blkaddr=0x60c84b, len=0xff El código problemático está en check_swap_activate(): if ((pblock - SM_I(sbi)->main_blkaddr) % blks_per_sec || nr_pblocks % blks_per_sec || !f2fs_valid_pinned_area(sbi, pblock)) { bool last_extent = false; not_aligned++; nr_pblocks = roundup(nr_pblocks, blks_per_sec); if (cur_lblock + nr_pblocks > sis->max) nr_pblocks -= blks_per_sec; /* esta extensión es la última */ if (!nr_pblocks) { nr_pblocks = last_lblock - cur_lblock; last_extent = true; } ret = f2fs_migrate_blocks(inode, cur_lblock, nr_pblocks); if (ret) { if (ret == -ENOENT) ret = -EINVAL; goto out; } if (!last_extent) goto retry; } Cuando la primera extensión no está alineada y roundup(nr_pblocks, blks_per_sec) excede sis->max, restamos blks_per_sec resultando en nr_pblocks = 0. El código asume incorrectamente que esta es la última extensión, establece nr_pblocks = last_lblock - cur_lblock (archivo de intercambio completo), y realiza la migración. Después de la migración, no reintenta el mapeo, por lo que las extensiones subsiguientes nunca se procesan. Para solucionar este problema, necesitamos buscar la información de mapeo de bloques después de migrar todos los bloques en la cola del archivo de intercambio.
Vulnerabilidad en Linux (CVE-2026-23234)
Severidad: ALTA
Fecha de publicación: 04/03/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: f2fs: corrección para evitar UAF en f2fs_write_end_io() Como syzbot informó un problema de uso después de liberación en f2fs_write_end_io(). Es causado por la siguiente condición de carrera: loop device umount - worker_thread - loop_process_work - do_req_filebacked - lo_rw_aio - lo_rw_aio_complete - blk_mq_end_request - blk_update_request - f2fs_write_end_io - dec_page_count - folio_end_writeback - kill_f2fs_super - kill_block_super - f2fs_put_super : free(sbi) : get_pages(, F2FS_WB_CP_DATA) accedió a sbi que está liberado En kill_f2fs_super(), descartaremos todas las cachés de página de los inodos f2fs antes de llamar a free(sbi), esto garantiza que todos los folios deberían finalizar su writeback, por lo tanto, debería ser seguro acceder a sbi antes del último folio_end_writeback(). Reubicaremos el flujo de activación del hilo ckpt antes de folio_end_writeback() para resolver este problema.
Vulnerabilidad en Linux (CVE-2026-23235)
Severidad: ALTA
Fecha de publicación: 04/03/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: f2fs: corrige el acceso fuera de límites en la lectura/escritura de atributos sysfs Algunos atributos sysfs de f2fs sufren de acceso a memoria fuera de límites y manejo incorrecto de valores enteros cuyo tamaño no es de 4 bytes. Por ejemplo: vm:~# echo 65537 > /sys/fs/f2fs/vde/carve_out vm:~# cat /sys/fs/f2fs/vde/carve_out 65537 vm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgc_age_threshold vm:~# cat /sys/fs/f2fs/vde/atgc_age_threshold 1 carve_out se mapea a {struct f2fs_sb_info}->carve_out, que es un entero de 8 bits. Sin embargo, la interfaz sysfs permite establecerlo a un valor mayor que 255, lo que resulta en una actualización fuera de rango. atgc_age_threshold se mapea a {struct atgc_management}->age_threshold, que es un entero de 64 bits, pero su interfaz sysfs no puede establecer correctamente valores mayores que UINT_MAX. Las causas raíz son: 1. __sbi_store() trata todos los valores predeterminados como unsigned int, lo que impide actualizar enteros mayores de 4 bytes y causa escrituras fuera de límites para enteros menores de 4 bytes. 2. f2fs_sbi_show() también asume que todos los valores predeterminados son unsigned int, lo que lleva a lecturas fuera de límites y acceso incorrecto a enteros mayores de 4 bytes. Este parche introduce {struct f2fs_attr}->size para registrar el tamaño real del entero asociado con cada atributo sysfs. Con esta información, las operaciones de lectura y escritura de sysfs pueden acceder y actualizar valores correctamente según su tamaño de datos real, evitando la corrupción de memoria y la truncación.
Vulnerabilidad en Linux (CVE-2026-23236)
Severidad: MEDIA
Fecha de publicación: 04/03/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: fbdev: smscufx: copiar correctamente la memoria ioctl al espacio del kernel El ioctl UFX_IOCTL_REPORT_DAMAGE no copia correctamente los datos desde el espacio de usuario al espacio del kernel, y en su lugar referencia directamente la memoria, lo que puede causar problemas si se pasan datos inválidos desde el espacio de usuario. Soluciona todo esto copiando correctamente la memoria antes de acceder a ella dentro del kernel.
Vulnerabilidad en Linux (CVE-2026-23237)
Severidad: MEDIA
Fecha de publicación: 04/03/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: platform/x86: classmate-laptop: Añadir comprobaciones de puntero NULL faltantes En algunos lugares del controlador del portátil Classmate, el código que utiliza el objeto accel puede ejecutarse antes de que la dirección de ese objeto se almacene en los datos del controlador del dispositivo de entrada que lo utiliza. Por ejemplo, cmpc_accel_sensitivity_store_v4() es el método 'show' de cmpc_accel_sensitivity_attr_v4 que se añade en cmpc_accel_add_v4(), antes de llamar a dev_set_drvdata() para inputdev->dev. Si el atributo sysfs se accede prematuramente, la llamada a dev_get_drvdata(&inputdev->dev) en cmpc_accel_sensitivity_store_v4() devuelve NULL, lo que lleva a una desreferencia de puntero NULL en adelante. Además, los atributos sysfs que utilizan el dispositivo de entrada se añaden antes de inicializar ese dispositivo por cmpc_add_acpi_notify_device() y si se accede a uno de ellos antes de ejecutar esa función, ocurrirá una desreferencia de puntero NULL. Por ejemplo, cmpc_accel_sensitivity_attr_v4 se añade antes de llamar a cmpc_add_acpi_notify_device() y si se lee prematuramente, la llamada a dev_get_drvdata(&acpi->dev) en cmpc_accel_sensitivity_show_v4() devuelve NULL, lo que lleva a una desreferencia de puntero NULL en adelante. Solucionar esto añadiendo comprobaciones de puntero NULL en todos los lugares relevantes.
Vulnerabilidad en Linux (CVE-2026-23238)
Severidad: MEDIA
Fecha de publicación: 04/03/2026
Fecha de última actualización: 17/03/2026
En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: romfs: verificar el valor de retorno de sb_set_blocksize() romfs_fill_super() ignora el valor de retorno de sb_set_blocksize(), lo cual puede fallar si el tamaño de bloque solicitado es incompatible con la configuración del dispositivo de bloques. Esto puede ser activado al establecer el tamaño de bloque de un dispositivo de bucle mayor que PAGE_SIZE usando ioctl(LOOP_SET_BLOCK_SIZE, 32768), y luego montando un sistema de archivos romfs en ese dispositivo. Cuando se llama a sb_set_blocksize(sb, ROMBSIZE) con ROMBSIZE=4096 pero el dispositivo tiene logical_block_size=32768, bdev_validate_blocksize() falla porque el tamaño solicitado es menor que el tamaño de bloque lógico del dispositivo. sb_set_blocksize() devuelve 0 (falla), pero romfs ignora esto y continúa el montaje. El tamaño de bloque del superbloque permanece en el tamaño de bloque lógico del dispositivo (32768). Más tarde, cuando sb_bread() intenta E/S con este tamaño de bloque sobredimensionado, activa un BUG del kernel en folio_set_bh(): BUG del kernel en fs/buffer.c:1582! BUG_ON(size > PAGE_SIZE); Solución al verificar el valor de retorno de sb_set_blocksize() y fallar el montaje con -EINVAL si devuelve 0.
Vulnerabilidad en Emlog (CVE-2026-31954)
Severidad: Pendiente de análisis
Fecha de publicación: 11/03/2026
Fecha de última actualización: 17/03/2026
Emlog es un sistema de creación de sitios web de código abierto. En 2.6.6 y versiones anteriores, la acción delete_async (eliminación asíncrona) carece de una llamada a LoginAuth::checkToken(), lo que permite ataques CSRF.