Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

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

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

Vulnerabilidad en kernel de Linux (CVE-2021-46988)
Severidad: MEDIA
Fecha de publicación: 28/02/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: userfaultfd: publicar página en ruta de error para evitar BUG_ON Considere la siguiente secuencia de eventos: 1. Userspace emite un ioctl UFFD, que termina llamando a shmem_mfill_atomic_pte(). Contamos con éxito los bloques, usamos shmem_alloc_page(), pero luego copy_from_user() falla. Volvemos -ENOENT. No publicamos la página que asignamos. 2. Nuestra persona que llama detecta este código de error, intenta copiar_from_user() después de descartar mmap_lock y vuelve a intentarlo, volviendo a llamar a shmem_mfill_atomic_pte(). 3. Mientras tanto, digamos que otro proceso llenó los tmpfs que se estaban utilizando. 4. Entonces shmem_mfill_atomic_pte() no logra bloquear la cuenta esta vez y regresa inmediatamente, sin liberar la página. Esto desencadena un BUG_ON en nuestra persona que llama, que afirma que la página siempre debe consumirse, a menos que se devuelva -ENOENT. Para solucionar este problema, detectar si tenemos esa página "colgante" cuando falla la contabilidad y, en caso afirmativo, liberarla antes de regresar.
Vulnerabilidad en kernel de Linux (CVE-2021-46990)
Severidad: MEDIA
Fecha de publicación: 28/02/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/64s: soluciona fallas al alternar la barrera de descarga de entrada. La mitigación de descarga de entrada se puede habilitar/deshabilitar en tiempo de ejecución a través de un archivo debugfs (entry_flush), lo que hace que el kernel se parchee a sí mismo. habilitar/deshabilitar las mitigaciones relevantes. Sin embargo, dependiendo de la mitigación que estemos usando, puede que no sea seguro aplicar ese parche mientras otras CPU están activas. Por ejemplo, el siguiente bloqueo: durmiente[15639]: segfault (11) en c000000000004c20 nip c000000000004c20 lr c000000000004c20 Muestra que regresamos al espacio de usuario con un LR corrupto que apunta al kernel, debido a la ejecución de la llamada parcialmente parcheada a la entrada de respaldo descarga ( es decir, nos perdimos la restauración de LR). Arréglelo haciendo el parche debajo de detener la máquina. Las CPU que no estén aplicando los parches girarán en el núcleo de la lógica de detención de la máquina. Actualmente, eso es suficiente para nuestros propósitos, porque ninguno de los parches que hacemos se aplica a ese código ni a ningún lugar cercano.
Vulnerabilidad en kernel de Linux (CVE-2021-46992)
Severidad: ALTA
Fecha de publicación: 28/02/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nftables: evitar desbordamientos en nft_hash_buckets() Número de depósitos almacenados en variables de 32 bits, debemos asegurarnos de que no se produzcan desbordamientos en nft_hash_buckets() syzbot inyectó un tamaño == 0x40000000 e informó: UBSAN: desplazamiento fuera de los límites en ./include/linux/log2.h:57:13 el exponente de desplazamiento 64 es demasiado grande para el tipo de 64 bits 'long unsigned int' CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:79 [en línea] dump_stack +0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 __roundup_pow_of_two include/linux/log2.h:57 [en línea] nft_hash_buckets net/netfilter/nft_set_hash.c:411 [en línea] nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652 nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [en línea] nf_tables_newset+0xe62 /0x3110 net/filtro de red /nf_tables_api.c:4322 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [en línea] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630 netlink_unicast_kernel net/ netlink/af_netlink.c:1312 [en línea] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [en línea] sock_sendmsg +0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_sys llamada_64+0x2d /0x70 arco/x86/entry/common.c:46
Vulnerabilidad en kernel de Linux (CVE-2021-46993)
Severidad: ALTA
Fecha de publicación: 28/02/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched: corrige el acceso fuera de los límites en uclamp Util-clamp coloca las tareas en diferentes depósitos según sus valores de fijación por razones de rendimiento. Sin embargo, el tamaño de los depósitos se calcula actualmente mediante una división de redondeo, lo que puede provocar un error de uno por uno en algunas configuraciones. Por ejemplo, con 20 depósitos, el tamaño del depósito será 1024/20=51. Una tarea con una abrazadera de 1024 se asignará al ID del depósito 1024/51=20. Lamentablemente, los índices correctos están en el rango [0,19], lo que provoca un acceso a la memoria fuera de los límites. Sujete la identificación del depósito para solucionar el problema.
Vulnerabilidad en kernel de Linux (CVE-2021-46997)
Severidad: MEDIA
Fecha de publicación: 28/02/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64: entrada: configure siempre GIC_PRIO_PSR_I_SET durante la entrada Zenghui informa que al iniciar un kernel con "irqchip.gicv3_pseudo_nmi=1" en la línea de comando aparece una advertencia durante la entrada del kernel, debido a la forma manipulamos el PMR. Al principio de la secuencia de entrada, llamamos a lockdep_hardirqs_off() para informar a lockdep que las interrupciones han sido enmascaradas (ya que el HW configura DAIF cuando ingresa una excepción). Desde el punto de vista arquitectónico, PMR_EL1 no se ve afectado por la entrada de excepción y no configuramos GIC_PRIO_PSR_I_SET en el PMR al principio de la secuencia de entrada de excepción, por lo que al principio de la entrada de excepción el PMR puede indicar que las interrupciones están desenmascaradas aunque estén enmascaradas por DAIF. Si se selecciona DEBUG_LOCKDEP, lockdep_hardirqs_off() verificará que las interrupciones estén enmascaradas, antes de configurar GIC_PRIO_PSR_I_SET en cualquiera de las rutas de entrada de excepción y, por lo tanto, lockdep_hardirqs_off() ADVERTENCIA() que algo anda mal. Podemos evitar esto configurando consistentemente GIC_PRIO_PSR_I_SET durante la entrada de excepciones para que el código del kernel vea un entorno consistente. También debemos actualizar local_daif_inherit() para deshacer esto, ya que actualmente solo toca DAIF. Para otras rutas, local_daif_restore() actualizará tanto DAIF como PMR. Una vez hecho esto, podemos eliminar los casos especiales existentes que configuran esto más adelante en el código de entrada. Siempre usamos (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) para mantener la coherencia con local_daif_save(), ya que esto avisará si alguna vez encuentra (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), y nunca lo configura por sí mismo. Esto coincide con gic_prio_kentry_setup que debemos conservar para ret_to_user. El símbolo original del informe de Zenghui fue: | DEBUG_LOCKS_WARN_ON(!irqs_disabled()) | ADVERTENCIA: CPU: 3 PID: 125 en kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8 | Módulos enlazados en: | CPU: 3 PID: 125 Comunicaciones: modprobe Contaminado: GW 5.12.0-rc8+ #463 | Nombre del hardware: Máquina virtual QEMU KVM, BIOS 0.0.0 06/02/2015 | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--) | ordenador personal: lockdep_hardirqs_off+0xd4/0xe8 | lr: lockdep_hardirqs_off+0xd4/0xe8 | sp: ffff80002a39bad0 | pmr_save: 000000e0 | x29: ffff80002a39bad0 x28: ffff0000de214bc0 | x27: ffff0000de1c0400 x26: 000000000049b328 | x25: 0000000000406f30 x24: ffff0000de1c00a0 | x23: 0000000020400005 x22: ffff8000105f747c | x21: 0000000096000044 x20: 0000000000498ef9 | x19: ffff80002a39bc88 x18: ffffffffffffffff | x17: 0000000000000000 x16: ffff800011c61eb0 | x15: ffff800011700a88 x14: 0720072007200720 | x13: 0720072007200720 x12: 0720072007200720 | x11: 0720072007200720 x10: 0720072007200720 | x9: ffff80002a39bad0 x8: ffff80002a39bad0 | x7: ffff8000119f0800 x6: c0000000ffff7fff | x5: ffff8000119f07a8 x4: 0000000000000001 | x3: 9bcdab23f2432800 x2: ffff800011730538 | x1: 9bcdab23f2432800 x0: 0000000000000000 | Rastreo de llamadas: | lockdep_hardirqs_off+0xd4/0xe8 | enter_from_kernel_mode.isra.5+0x7c/0xa8 | el1_abort+0x24/0x100 | el1_sync_handler+0x80/0xd0 | el1_sync+0x6c/0x100 | __arch_clear_user+0xc/0x90 | load_elf_binary+0x9fc/0x1450 | bprm_execve+0x404/0x880 | kernel_execve+0x180/0x188 | call_usermodehelper_exec_async+0xdc/0x158 | ret_from_fork+0x10/0x18
Vulnerabilidad en kernel de Linux (CVE-2021-47260)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFS: corrija una posible desreferencia NULL en nfs_get_client() Ninguna de las personas que llaman espera retornos NULL de nfs_get_client(), por lo que este código generará un error ¡Oops! Es mejor devolver un puntero de error. Supongo que se trata de un código inactivo, así que espero que nadie se vea afectado.
Vulnerabilidad en kernel de Linux (CVE-2021-47264)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: core: corrige la desreferencia de punto nulo en fmt_single_name(). Verifique el valor de retorno de devm_kstrdup() en caso de dereferencia de punto nulo.
Vulnerabilidad en kernel de Linux (CVE-2021-47269)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: ep0: corrige excepción de puntero NULL. No hay validación del índice desde dwc3_wIndex_to_dep() y podríamos estar haciendo referencia a un ep inexistente y desencadenar una excepción de puntero NULL. En ciertas configuraciones, podríamos usar menos eps y el índice podría indicar erróneamente un índice ep mayor que el existente. Al agregar esta validación del parche, podemos informar un índice incorrecto a la persona que llama. En nuestro caso de uso, estamos usando un dispositivo compuesto en un kernel más antiguo, pero el nivel superior también podría usar esta solución. Desafortunadamente, no puedo describir el hardware para que otros reproduzcan el problema ya que es una implementación propietaria. [82.958261] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000a4 [82.966891] Información de cancelación de memoria: [82.969663] ESR = 0x96000006 [82.972703] Clase de excepción = DABT (EL actual), IL = 32 bits [ 82.9 78603] CONFIGURAR = 0, FnV = 0 [82.981642] EA = 0, S1PTW = 0 [82.984765] Información de cancelación de datos: [82.987631] ISV = 0, ISS = 0x00000006 [82.991449] CM = 0, WnR = 0 [82.994409] tabla de usuario 4k: páginas, 39 VA de bits, pgdp = 00000000c6210ccc [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000 [ 83.00 9685] Error interno: Oops: 96000006 [#1] SMP PREEMPTO [83.026433] Proceso irq/62-dwc3 (pid : 303, límite de pila = 0x000000003985154c) [83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 No contaminado 4.19.124 #1 [83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 49628] ordenador personal: dwc3_ep0_handle_feature+0x414/0x43c [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94 ... [ 83.141788] Rastreo de llamadas: [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c [ 83.148 823] dwc3_ep0_interrupt+0x3b4/0xc94 [83.181546] ---[ final de seguimiento aac6b5267d84c32f ]---
Vulnerabilidad en kernel de Linux (CVE-2021-47270)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: repara varios gadgets null ptr deref en cableado de 10gbps. Esto evita una desreferencia de puntero null en f_{ecm,eem,hid,loopback,printer,rndis,serial,sourcesink,subset,tcm} simplemente reutilizando la configuración de 5 gbps para 10 gbps.
Vulnerabilidad en kernel de Linux (CVE-2021-47280)
Severidad: ALTA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm: corrige la lectura de use after free en drm_getunique(). Hay un error de tiempo de verificación a tiempo de uso en drm_getunique() debido a la recuperación de file_priv. ->master antes de bloquear el mutex maestro del dispositivo. Se puede ver un ejemplo en el informe de fallo del error de use after free encontrado por Syzbot: https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 En el informe, el puntero maestro se utilizó después de ser liberado. Esto se debe a que otro proceso adquirió el mutex maestro del dispositivo en drm_setmaster_ioctl() y luego sobrescribió fpriv->master en drm_new_set_master(). El antiguo valor de fpriv->master se liberó posteriormente antes de que se desbloqueara el mutex. Para solucionar este problema, bloqueamos el mutex maestro del dispositivo antes de recuperar el puntero desde fpriv->master. Este parche pasa la prueba del reproductor Syzbot.
CVE-2021-47281
Severidad: ALTA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ALSA: seq: Fix race of snd_seq_timer_open(). La instancia del temporizador por cola es exclusiva, y snd_seq_timer_open() debería haber gestionado los accesos concurrentes. Parece como si estuviera verificando la instancia del temporizador ya existente al principio, pero no es correcto, porque no hay protección, por lo tanto, cualquier llamada simultánea posterior a snd_seq_timer_open() puede anular la instancia del temporizador fácilmente. Esto puede resultar en UAF, ya que la instancia del temporizador sobrante puede seguir ejecutándose mientras la cola se cierra, como descubrió syzkaller recientemente. Para evitar la ejecución, agregue una verificación adecuada en la asignación de tmr->timeri nuevamente y devuelva -EBUSY si ya se registró.
Vulnerabilidad en kernel de Linux (CVE-2021-47314)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: memoria: fsl_ifc: corrige la pérdida de memoria privada en caso de fallo de la sonda. En caso de error de la sonda, el controlador debe liberar la memoria asignada para la estructura privada. Solucione este problema utilizando la asignación administrada de recursos.
Vulnerabilidad en kernel de Linux (CVE-2021-47316)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrige la desreferencia NULL en nfs3svc_encode_getaclres. En casos de error, la dentry puede ser NULL. Antes de 20798dfe249a, el codificador también verificaba dentry y d_really_is_positive(dentry), pero eso me parece excesivo: el estado cero debería ser suficiente para garantizar un dentry positivo. Esta no es la primera vez que vemos una desreferencia NULL de caso de error oculta en la inicialización de una variable local en un codificador xdr. Pero revisé las otras reescrituras recientes y no encontré ningún error similar.
Vulnerabilidad en kernel de Linux (CVE-2021-47319)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: virtio-blk: corrige la pérdida de memoria entre el procedimiento de suspensión/reanudación. El vblk->vqs debe liberarse antes de llamar a init_vqs() en virtblk_restore().
Vulnerabilidad en kernel de Linux (CVE-2021-47320)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfs: corrige la pérdida de memoria acl de posix_acl_create(). Al buscar en otro informe de nfs xfstests, encontré que acl y default_acl en nfs3_proc_create() y las rutas de error de nfs3_proc_mknod() posiblemente se hayan filtrado. Arréglelos con anticipación.
Vulnerabilidad en kernel de Linux (CVE-2021-47330)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: serial: 8250: serial_cs: corrige una pérdida de memoria en la ruta de manejo de errores. En la función de sonda, si el 'serial_config()' final falla, se está perdiendo 'info'. Agregue una ruta de manejo de recursos para liberar esta memoria.
Vulnerabilidad en kernel de Linux (CVE-2021-47331)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: común: usb-conn-gpio: corrige la desreferencia del puntero NULL del cargador. Cuando se enciende el sistema con un cable OTG, la interrupción de IDDIG surge antes del registro del cargador, lo que provocará un puntero NULL desreferencia, solucione el problema registrando la fuente de alimentación antes de solicitar IDDIG/VBUS irq.
Vulnerabilidad en kernel de Linux (CVE-2021-47332)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usx2y: No llamar a free_pages_exact() con dirección NULL A diferencia de otras funciones, no podemos pasar un puntero NULL a free_pages_exact(). Agregue una verificación NULL adecuada para evitar posibles Oops.
Vulnerabilidad en kernel de Linux (CVE-2021-47337)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: core: corrige la desreferencia del puntero incorrecto cuando ehandler kthread no es válido. La confirmación 66a834d09293 ("scsi: core: corrige el manejo de errores de scsi_host_alloc()") cambió la lógica de asignación para llamar a put_device( ) para realizar la limpieza del host asumiendo que la eliminación de IDA y la detención del kthread se realizarían correctamente en scsi_host_dev_release(). Sin embargo, en el improbable caso de que el subproceso del controlador de errores no se genere, shost->ehandler se establece en ERR_PTR(-ENOMEM). El código de limpieza del controlador de errores en scsi_host_dev_release() llamará a kthread_stop() si shost->ehandler != NULL, que siempre será el caso ya sea que kthread se genere exitosamente o no. En el caso de que no se genere, esto tiene el desagradable efecto secundario de intentar eliminar la referencia a un puntero no válido cuando se llama a kthread_stop(). El siguiente símbolo proporciona un ejemplo de este comportamiento en la naturaleza: scsi host11: el hilo del controlador de errores no pudo generarse, error = -4 El kernel intentó leer la página del usuario (10c): ¿intento de explotación? (uid: 0) ERROR: Desreferencia del puntero NULL del kernel al leer en 0x0000010c Dirección de instrucción errónea: 0xc00000000818e9a8 Ups: Acceso al kernel del área defectuosa, firma: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 Módulos NUMA pSeries vinculados en: ibmvscsi(+) scsi_transport_srp dm_multipath dm_mirror dm_region hash dm_log dm_mod fuse overlay squashfs loop CPU: 12 PID: 274 Comm: systemd-udevd Not tainted 5.13.0-rc7 #1 NIP: c00000000818e9a8 LR: 9846e8 CTR: 0000000000007ee8 REGS: c000000037d12ea0 TRAMPA : 0300 No contaminado (5.13.0-rc7) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28228228 XER: 20040001 CFAR: c0000000089846e4 DAR: 000000000000010c DSISR: 40000000 IRQMASK: 0 GPR00: c0000000089846e8 c000000037d13140 000009cc1100 ffffffffffffffffc GPR04: 0000000000000001 0000000000000000 0000000000000000 c000000037dc0000 GPR08: 0000000000000000 c000000037 dc0000 0000000000000001 00000000fffff7ff GPR12: 0000000000008000 c00000000a049000 c000000037d13d00 000000011134d5a0 GPR16: 001740 c0080000190d0000 c0080000190d1740 c000000009129288 GPR20: c000000037d13bc0 0000000000000001 c000000037d13bc0 c0080000190b7898 GPR24: c0080000190b7708 0000000000000000 c000000033bb2c48 000000 0000000000 GPR28: c000000046b28280 0000000000000000 000000000000010c ffffffffffffffffc NIP [c00000000818e9a8] kthread_stop+0x38/0x230 LR [c0000000089 846e8] scsi_host_dev_release+0x98/0x160 Seguimiento de llamadas: [c000000033bb2c48] 0xc000000033bb2c48 (no confiable) [c0000000089846e8] scsi_host_dev_release+0x98 /0x160 [c00000000891e960] device_release+0x60/0x100 [c0000000087e55c4] kobject_release+0x84/0x210 [c00000000891ec78] put_device+0x28/0x40 [c000000008984ea4] host_alloc+0x314/0x430 [c0080000190b38bc] ibmvscsi_probe+0x54/0xad0 [ibmvscsi] [c000000008110104] vio_bus_probe+ 0xa4/0x4b0 [c00000000892a860] very_probe+0x140/0x680 [c00000000892aefc] driver_probe_device+0x15c/0x200 [c00000000892b63c] device_driver_attach+0xcc/0xe0 [c0000000 0892b740] __driver_attach+0xf0/0x200 [c000000008926f28] bus_for_each_dev+0xa8/0x130 [c000000008929ce4] driver_attach+0x34/ 0x50 [c000000008928fc0] bus_add_driver+0x1b0/0x300 [c00000000892c798] driver_register+0x98/0x1a0 [c00000000810eb60] __vio_register_driver+0x80/0xe0 [c0080000190 b4a30] ibmvscsi_module_init+0x9c/0xdc [ibmvscsi] [c0000000080121d0] do_one_initcall+0x60/0x2d0 [c000000008261abc] do_init_module+0x7c /0x320 [c000000008265700] load_module+0x2350/0x25b0 [c000000008265cb4] __do_sys_finit_module+0xd4/0x160 [c000000008031110] system_call_exception+0x150/0x2d0 [c00 000000800d35c] system_call_common+0xec/0x278 Se soluciona esto al anular shost->ehandler cuando el kthread no se genera.
Vulnerabilidad en Recuperando datos. Espere unos segundos e intente cortar o copiar de nuevo. (CVE-2021-47338)
Severidad: ALTA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: fbmem: No elimina el modo que aún está en uso. La ejecución de fb_delete_videomode() no se basa en el resultado del fbcon_mode_deleted() anterior. Como resultado, el modo se elimina directamente, independientemente de si todavía está en uso, lo que puede causar UAF. ==================================================== ================ BUG: KASAN: use-after-free en fb_mode_is_equal+0x36e/0x5e0 \ drivers/video/fbdev/core/modedb.c:924 Lectura de tamaño 4 en addr ffff88807e0ddb1c por tarea syz-executor.0/18962 CPU: 2 PID: 18962 Comm: syz-executor.0 No contaminado 5.10.45-rc1+ #3 Nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS .. Seguimiento de llamadas: __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0x137/0x1be lib/dump_stack.c:118 print_address_description+0x6c/0x640 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c: 545 [en línea] kasan_report+0x13d/0x1e0 mm/kasan/report.c:562 fb_mode_is_equal+0x36e/0x5e0 drivers/video/fbdev/core/modedb.c:924 fbcon_mode_deleted+0x16a/0x220 drivers/video/fbdev/core/fbcon .c:2746 fb_set_var+0x1e1/0xdb0 drivers/video/fbdev/core/fbmem.c:975 do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [en línea ] __do_sys_ioctl fs/ioctl.c:753 [en línea] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 Liberado por tarea 18960: kasan_save_stack mm/kasan/common.c:48 [en línea] kasan_set_track+0x3d/0x70 mm/kasan/common.c:56 kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355 __kasan_slab_free+0x108/0x140 mm/kasan/ common.c:422 slab_free_hook mm/slub.c:1541 [en línea] slab_free_freelist_hook+0xd6/0x1a0 mm/slub.c:1574 slab_free mm/slub.c:3139 [en línea] kfree+0xca/0x3d0 mm/slub.c: 4121 fb_delete_videomode+0x56a/0x820 controladores/video/fbdev/core/modedb.c:1104 fb_set_var+0x1f3/0xdb0 controladores/video/fbdev/core/fbmem.c:978 do_fb_ioctl+0x4d9/0x6e0 controladores/video/fbdev/core/ fbmem.c:1108 vfs_ioctl fs/ioctl.c:48 [en línea] __do_sys_ioctl fs/ioctl.c:753 [en línea] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/ common.c:46 entrada_SYSCALL_64_after_hwframe+0x44/0xa9
Vulnerabilidad en kernel de Linux (CVE-2021-47344)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: zr364xx: corrige la pérdida de memoria en zr364xx_start_readpipe syzbot informó una pérdida de memoria en el controlador zr364xx. El problema estaba en la urb no liberada en caso de que fallara usb_submit_urb(). seguimiento: [] kmalloc include/linux/slab.h:561 [en línea] [] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74 [] zr364xx_start_readpipe+0x78/ 0x130 drivers/media/usb/zr364xx/zr364xx.c:1022 [] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [en línea] [] 0x851 drivers/media/ usb/zr364xx/zr364xx.c:1516 [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 []really_probe+0x159/0x500 controladores/base/dd.c:576
Vulnerabilidad en kernel de Linux (CVE-2021-47345)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/cma: Reparar pérdida de memoria rdma_resolve_route(). Reparar una pérdida de memoria cuando se llama a "mda_resolve_route() más de una vez en el mismo "rdma_cm_id". Esto es posible si cma_query_handler() desencadena el flujo RDMA_CM_EVENT_ROUTE_ERROR que devuelve la máquina de estado y permite volver a llamar a rdma_resolve_route().
Vulnerabilidad en kernel de Linux (CVE-2021-47353)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udf: Se corrigió la desreferencia del puntero NULL en la función udf_symlink. En la función udf_symlink, a epos.bh se le asigna el valor devuelto por udf_tgetblk. La función udf_tgetblk está definida en udf/misc.c y devuelve el valor de la función sb_getblk que podría ser NULL. Luego, epos.bh se usa sin ninguna verificación, lo que provoca una posible desreferencia del puntero NULL cuando falla sb_getblk. Esta solución agrega una verificación para validar el valor de epos.bh.
Vulnerabilidad en kernel de Linux (CVE-2021-47359)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: cifs: corrige el bloqueo suave durante fsstress. Los siguientes rastros se observan durante fsstress y el sistema se bloquea. [130.698396] perro guardián: BUG: bloqueo suave - ¡CPU#6 bloqueada durante 26 segundos!
Vulnerabilidad en kernel de Linux (CVE-2021-47397)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: se rompe si skb_header_pointer devuelve NULL en sctp_rcv_ootb. Siempre debemos verificar si el retorno de skb_header_pointer es NULL antes de usarlo; de lo contrario, puede causar null-ptr-deref, como informó syzbot: KASAN : null-ptr-deref en el rango [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_rcv_ootb net/sctp/input.c:705 [en línea] RIP: 0010:sctp_rcv+0x1d84/0x3220 net/sctp/input .c:196 Seguimiento de llamadas : sctp6_rcv+0x38/0x60 net/sctp/ipv6.c:1109 ip6_protocol_deliver_rcu+0x2e9/0x1ca0 net/ipv6/ip6_input.c:422 ip6_input_finish+0x62/0x170 net/ipv6/ip6_input.c:463 incluir/linux /netfilter.h:307 [en línea] NF_HOOK include/linux/netfilter.h:301 [en línea] ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:472 dst_input include/net/dst.h:460 [en línea] ip6_rcv_finish net/ipv6/ip6_input.c:76 [en línea] NF_HOOK include/linux/netfilter.h:307 [en línea] NF_HOOK include/linux/netfilter.h:301 [en línea] ipv6_rcv+0x28c/0x3c0 net/ipv6/ip6_input.c :297
Vulnerabilidad en kernel de Linux (CVE-2021-47399)
Severidad: MEDIA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ixgbe: corrige la desreferencia del puntero NULL en ixgbe_xdp_setup. El controlador ixgbe actualmente genera una desreferencia del puntero NULL con alguna máquina (cpus en línea <63). Esto se debe al hecho de que el valor máximo de num_xdp_queues es nr_cpu_ids. El código está en "ixgbe_set_rss_queues"". Así es como el problema se repite: alguna máquina (cpus en línea <63), y el usuario configuró num_queues en 63 a través de ethtool. El código está en "ixgbe_set_channels", adaptador->ring_feature[RING_F_FDIR].limit = count; se convierte en 63. Cuando el usuario usa xdp, "ixgbe_set_rss_queues" establecerá el número de colas adaptor->num_rx_queues = rss_i; = &adapter->ring_feature[RING_F_FDIR]; rss_i = f->indices = f->limit; Entonces "num_rx_queues" > "num_xdp_queues", cuando se ejecuta en "ixgbe_xdp_setup", para (i = 0; i < adaptor->num_rx_queues; i++) if (adapter->xdp_ring[i]->xsk_umem) Genera pánico: [excepción RIP: ixgbe_xdp+368] RIP: ffffffffc02a76a0 RSP: ffff9fe16202f8d0 RFLAGS: 00010297 RAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000000 RDX : 0000000000000000 RSI: 000000000000001c RDI: ffffffffa94ead90 RBP: ffff92f8f24c0c18 R8: 0000000000000000 R9: 0000000000000000 R10: ffff9fe1620 2f830 R11: 0000000000000000 R12: ffff92f8f24c0000 R13: ffff9fe16202fc01 R14: 000000000000000a R15: ffffffffc02a7530 ORIG_RAX: ffffffffffffffff CS: : 0018 7 [ffff9fe16202f8f0] dev_xdp_install en fffffffa89fbbcc 8 [ffff9fe16202f920] dev_change_xdp_fd en fffffffa8a08808 9 [ffff9fe16202f960] do_setlink en fffffffa8a20235 10 [ffff9fe16202fa88] rtnl_setlink en fffffffa8a20384 11 [ffff9fe16202fc78] rtnetlink_rcv_msg en ffffffffa8a1a8dd 12 [ffff9fe16202fcf0] netlink_rcv_skb en ffffffffa8a717eb 13 [ffff9fe16202fd40] netlink_unicast en fffffffa8a70f88 14 [ffff9fe162 02fd80] netlink_sendmsg en fffffffa8a71319 15 [ffff9fe16202fdf0] sock_sendmsg en ffffffffa89df290 16 [ffff9fe16202fe08] __sys_sendto en ffffffffa89e19c8 17 [ffff9fe16202ff30] __x64_sys_sendto en ffffffffa89e1a64 8 [ffff9fe16202ff38] do_syscall_64 en ffffffffa84042b9 19 [ffff9fe16202ff50] Entry_SYSCALL_64_after_hwframe en ffffffffa8c0008c Entonces arreglo ixgbe_max_channels para que no permita una configuración de colas ser mayor que num_online_cpus(). Y cuando ejecute ixgbe_xdp_setup, tome el valor más pequeño de num_rx_queues y num_xdp_queues.
Vulnerabilidad en kernel de Linux (CVE-2021-47404)
Severidad: ALTA
Fecha de publicación: 21/05/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: betop: corrige escritura slab-out-of-bounds en betop_probe. Syzbot informó un error de escritura slab-out-of-bounds en el controlador hid-betopff. El problema es que el controlador supone que el dispositivo debe tener un informe de entrada, pero algunos dispositivos maliciosos violan esta suposición. Entonces, este parche verifica que la entrada de hid_device no esté vacía antes de usarse.
Vulnerabilidad en kernel de Linux (CVE-2024-53089)
Severidad: MEDIA
Fecha de publicación: 21/11/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: KVM: Marcar hrtimer para que caduque en un contexto de interrupción dura Como en el commit 2c0d278f3293f ("KVM: LAPIC: Marcar hrtimer para que caduque en un contexto de interrupción dura") y el commit 9090825fa9974 ("KVM: arm/arm64: Dejar que el temporizador caduque en un contexto de hardirq en RT"), en los kernels con PREEMPT_RT habilitado, los hrtimers sin marcar se mueven al modo de caducidad de interrupción suave de forma predeterminada. Luego, los temporizadores se cancelan desde un notificador de preempción que se invoca con la preempción deshabilitada, lo que no está permitido en PREEMPT_RT. La devolución de llamada del temporizador es corta, por lo que podría invocarse en un contexto de hard-IRQ. Por lo tanto, deje que el temporizador caduque en un contexto de hard-IRQ incluso en -RT. Esto corrige un error de "programación mientras es atómico" para los kernels con PREEMPT_RT habilitado: ERROR: programación mientras es atómico: qemu-system-loo/1011/0x00000002 Módulos vinculados en: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Contaminado: GW 6.12.0-rc2+ #1774 Contaminado: [W]=WARN Nombre del hardware: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 21/10/2022 Pila: ffffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 900000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 900000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Seguimiento de llamadas: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finalizar_conmutación_de_tareas.isra.0+0x140/0x2e0 [<9000000004e44a70>] __programación+0x450/0x1660 [<9000000004e45cb0>] programación+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]
Vulnerabilidad en kernel de Linux (CVE-2024-53090)
Severidad: MEDIA
Fecha de publicación: 21/11/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: Fix lock recursion afs_wake_up_async_call() puede generar recursión de bloqueo. El problema es que se llama desde AF_RXRPC mientras se mantiene el ->notify_lock, pero intenta tomar una referencia en la estructura afs_call para pasarla a una cola de trabajo; pero si afs_call ya está en cola, entonces tenemos una referencia extraña que se debe poner... sin embargo, llamar a afs_put_call() puede volver a llamar a AF_RXRPC a través de rxrpc_kernel_shutdown_call(), que podría intentar tomar el ->notify_lock nuevamente. Sin embargo, este caso no es muy común, por lo que se debe diferir a una cola de trabajo. El error se parece a algo como esto: ERROR: recursión de spinlock en CPU#0, krxrpcio/7001/1646 bloqueo: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 No contaminado 6.12.0-rc2-build3+ #4351 Nombre del hardware: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Seguimiento de llamadas: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_de_la_bifurcación+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_de_la_bifurcación_asm+0x1a/0x30
Vulnerabilidad en kernel de Linux (CVE-2024-53091)
Severidad: MEDIA
Fecha de publicación: 21/11/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Agregar comprobación de sk_is_inet e IS_ICSK en tls_sw_has_ctx_tx/rx Como la introducción del soporte para vsock y sockets unix en sockmap, tls_sw_has_ctx_tx/rx no puede presumir que el socket pasado debe ser IS_ICSK. Los sockets vsock y af_unix tienen vsock_sock y unix_sock en lugar de inet_connection_sock. Para estos sockets, tls_get_ctx puede devolver un puntero no válido y causar un error de página en la función tls_sw_ctx_rx. ERROR: no se puede manejar el error de página para la dirección: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes
Vulnerabilidad en kernel de Linux (CVE-2024-53092)
Severidad: MEDIA
Fecha de publicación: 21/11/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_pci: Arreglar la limpieza de admin vq usando el puntero de información correcto vp_modern_avq_cleanup() y vp_del_vqs() limpian los recursos de admin vq mediante el puntero virtio_pci_vq_info. El puntero de información de admin vq se almacena en vp_dev->admin_vq.info en lugar de vp_dev->vqs[]. Usar el puntero de información de vp_dev->vqs[] para admin vq causa un error de desreferencia de puntero NULL en el kernel. En vp_modern_avq_cleanup() y vp_del_vqs(), obtener el puntero de información de vp_dev->admin_vq.info para admin vq para limpiar los recursos. También hacer que info ptr como argumento de vp_del_vq() sea simétrico con vp_setup_vq(). vp_reset llama a vp_modern_avq_cleanup y provoca el seguimiento de llamadas: ===================================================================== ERROR: desreferencia de puntero NULL del núcleo, dirección:000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe No contaminado 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Seguimiento de llamadas: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================
Vulnerabilidad en kernel de Linux (CVE-2024-53093)
Severidad: MEDIA
Fecha de publicación: 21/11/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-multipath: aplazar el escaneo de particiones Necesitamos evitar que el escaneo de particiones se realice dentro del contexto scan_work del controlador. Si se produce un error de ruta aquí, la IO esperará hasta que haya una ruta disponible o se eliminen todas las rutas, pero esa acción también ocurre dentro de scan_work, por lo que se bloquearía. Aplaza el escaneo de particiones a un contexto diferente que no bloquee scan_work.
Vulnerabilidad en kernel de Linux (CVE-2024-53094)
Severidad: MEDIA
Fecha de publicación: 21/11/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/siw: Agregar la comprobación sendpage_ok() para deshabilitar MSG_SPLICE_PAGES Mientras se ejecuta ISER sobre SIW, la máquina iniciadora encuentra una advertencia de skb_splice_from_iter() que indica que se está utilizando una página slab en send_page. Para solucionar esto, es mejor agregar una comprobación sendpage_ok() dentro del propio controlador y, si devuelve 0, entonces se debe deshabilitar el indicador MSG_SPLICE_PAGES antes de ingresar a la pila de red. Se ha discutido un problema similar para NVMe en este hilo: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ ADVERTENCIA: CPU: 0 PID: 5342 en net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Seguimiento de llamadas: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_de_la_bifurcación+0x34/0x40 ret_de_la_bifurcación_asm+0x1a/0x30
Vulnerabilidad en kernel de Linux (CVE-2024-53096)
Severidad: MEDIA
Fecha de publicación: 25/11/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: resolver el comportamiento defectuoso de la ruta de error mmap_region() La función mmap_region() es algo aterradora, con un flujo de control tipo espagueti y numerosos medios por los cuales pueden surgir problemas y pueden ocurrir estados incompletos, fugas de memoria y otras cosas desagradables. Una gran parte de la complejidad surge de intentar manejar errores tarde en el proceso de mapeo de un VMA, que forma la base de los problemas observados recientemente con fugas de recursos y estado inconsistente observable. Aprovechando los parches anteriores de esta serie, movemos una serie de verificaciones antes en el código, simplificando las cosas al mover el núcleo de la lógica a una función interna estática __mmap_region(). Hacer esto nos permite realizar una serie de verificaciones por adelantado antes de hacer cualquier trabajo real, y nos permite desenrollar la verificación de desasignación escribible incondicionalmente según sea necesario y realizar una validación CONFIG_DEBUG_VM_MAPLE_TREE incondicionalmente también. Aquí movemos una serie de cosas: 1. Preasignamos memoria para el iterador antes de llamar al gancho de memoria respaldado por archivo, lo que nos permite salir antes y evitar tener que realizar una lógica de cierre/liberación complicada y propensa a errores. Liberamos cuidadosamente el estado del iterador tanto en las rutas de éxito como de error. 2. La función mmap_region() que lo encierra maneja la lógica mapping_map_writable() de forma temprana. Anteriormente, la lógica tenía mapping_map_writable() en el punto de mapeo de un VMA respaldado por archivo recientemente asignado y un mapping_unmap_writable() coincidente en las rutas de éxito y error. Ahora hacemos esto incondicionalmente si se trata de un mapeo compartido escribible respaldado por archivo. Sin embargo, si un controlador cambia los indicadores para eliminar VM_MAYWRITE, al hacerlo no invalida la verificación de sello que acabamos de realizar y, en cualquier caso, siempre decrementamos el contador en el contenedor. Realizamos una aserción de depuración para asegurarnos de que un controlador no intente hacer lo contrario. 3. También trasladamos arch_validate_flags() a la función mmap_region(). Esto solo es relevante en arm64 y sparc64, y la comprobación solo es significativa para SPARC con ADI habilitado. Agregamos explícitamente una advertencia para esta arquitectura si un controlador invalida esta comprobación, aunque el código debería corregirse eventualmente para eliminar la necesidad de esto. Con todas estas medidas implementadas, ya no necesitamos cerrar explícitamente el VMA en las rutas de error, ya que colocamos todas las comprobaciones que podrían fallar antes de una llamada a cualquier gancho mmap del controlador. Esto elimina una clase completa de errores, hace que el código sea más fácil de razonar y más robusto.
Vulnerabilidad en kernel de Linux (CVE-2024-53097)
Severidad: MEDIA
Fecha de publicación: 25/11/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: krealloc: corrige la falsa alarma de MTE en __do_krealloc Este parche soluciona un problema introducido por el commit 1a83a716ec233 ("mm: krealloc: considere la memoria de repuesto para __GFP_ZERO") que hace que MTE (extensión de etiquetado de memoria) informe falsamente un error de losa fuera de los límites. El problema ocurre al poner a cero la memoria de repuesto en __do_krealloc. El código original solo consideraba KASAN basado en software y no tenía en cuenta MTE. No restablece la etiqueta KASAN antes de llamar a memset, lo que lleva a una falta de coincidencia entre la etiqueta del puntero y la etiqueta de memoria, lo que resulta en un falso positivo. Ejemplo del error: ================================================================== swapper/0: ERROR: KASAN: slab fuera de los límites en __memset+0x84/0x188 swapper/0: Escritura en la dirección f4ffff8005f0fdf0 por la tarea swapper/0/1 swapper/0: Etiqueta de puntero: [f4], etiqueta de memoria: [fe] swapper/0: swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 No contaminado 6.12. swapper/0: Nombre del hardware: MT6991(ENG) (DT) swapper/0: Rastreo de llamadas: swapper/0: dump_backtrace+0xfc/0x17c swapper/0: show_stack+0x18/0x28 swapper/0: dump_stack_lvl+0x40/0xa0 swapper/0: print_report+0x1b8/0x71c swapper/0: kasan_report+0xec/0x14c swapper/0: __do_kernel_fault+0x60/0x29c swapper/0: do_bad_area+0x30/0xdc swapper/0: do_tag_check_fault+0x20/0x34 swapper/0: do_mem_abort+0x58/0x104 swapper/0: el1_abort+0x3c/0x5c intercambiador/0: el1h_64_sync_handler+0x80/0xcc intercambiador/0: el1h_64_sync+0x68/0x6c intercambiador/0: __memset+0x84/0x188 intercambiador/0: btf_populate_kfunc_set+0x280/0x3d8 intercambiador/0: __register_btf_kfunc_id_set+0x43c/0x468 intercambiador/0: register_btf_kfunc_id_set+0x48/0x60 intercambiador/0: register_nf_nat_bpf+0x1c/0x40 intercambiador/0: nf_nat_init+0xc0/0x128 intercambiador/0: do_one_initcall+0x184/0x464 intercambiador/0: do_initcall_level+0xdc/0x1b0 intercambiador/0: do_initcalls+0x70/0xc0 intercambiador/0: do_basic_setup+0x1c/0x28 intercambiador/0: kernel_init_freeable+0x144/0x1b8 intercambiador/0: kernel_init+0x20/0x1a8 intercambiador/0: ret_from_fork+0x10/0x20 ====================================================================
Vulnerabilidad en kernel de Linux (CVE-2024-53098)
Severidad: ALTA
Fecha de publicación: 25/11/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/ufence: Prefetch ufence addr para capturar direcciones falsas. access_ok() solo verifica el desbordamiento de direcciones, por lo que también intenta leer la dirección para capturar direcciones no válidas enviadas desde el espacio de usuario. (seleccionado de el commit 9408c4508483ffc60811e910a93d6425b8e63928)
Vulnerabilidad en kernel de Linux (CVE-2024-53099)
Severidad: ALTA
Fecha de publicación: 25/11/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: comprobar la validez de link->type en bpf_link_show_fdinfo() Si un tipo de enlace recién añadido no invoca BPF_LINK_TYPE(), acceder a bpf_link_type_strs[link->type] puede dar como resultado un acceso fuera de los límites. Para detectar dichas invocaciones fallidas de forma temprana en el futuro, se debe comprobar la validez de link->type en bpf_link_show_fdinfo() y emitir una advertencia cuando se omiten dichas invocaciones.
Vulnerabilidad en kernel de Linux (CVE-2024-53100)
Severidad: MEDIA
Fecha de publicación: 25/11/2024
Fecha de última actualización: 24/12/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme: tcp: evitar la ejecución entre el bloqueo de queue_lock y la destrucción. El commit 76d54bf20cdc ("nvme-tcp: no acceder al socket liberado durante la recuperación de errores") agregó una llamada mutex_lock() para queue->queue_lock en nvme_tcp_get_address(). Sin embargo, mutex_lock() compite con mutex_destroy() en nvme_tcp_free_queue() y provoca la siguiente ADVERTENCIA. DEBUG_LOCKS_WARN_ON(bloqueo->mágico != bloqueo) ADVERTENCIA: CPU: 3 PID: 34077 en kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Módulos vinculados en: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus bucle fusible nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx disquete nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [última descarga: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd No contaminado 6.11.0-rc7 #319 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 01/04/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Código: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 00000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? hacer_syscall_64+0x9f/0x180 ? bloquear_hardirqs_en_preparar+0x16d/0x400 ? hacer_syscall_64+0x9f/0x180 ? bloquear_hardirqs_en+0x78/0x100 ? hacer_syscall_64+0x9f/0x180 ? bloquear_hardirqs_en_preparar+0x16d/0x400 ? hacer_syscall_64+0x9f/0x180 ? bloquear_hardirqs_en+0x78/0x100 ? hacer_syscall_64+0x9f/0x180 ? bloquear_hardirqs_en_preparar+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Código: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncado---