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 una petición HTTP al servidor web en diversos dispositivos Modicon (CVE-2021-22788)
Severidad: MEDIA
Fecha de publicación: 11/02/2022
Fecha de última actualización: 10/04/2024
Una CWE-787: Se presenta una vulnerabilidad de Escritura Fuera de Límites que podría causar una denegación de servicio cuando un atacante envía una petición HTTP especialmente diseñada al servidor web del dispositivo. Producto afectado: CPUs Modicon M340: BMXP34 (Versiones anteriores a V3.40), Módulos de Comunicación Ethernet Modicon M340 X80: BMXNOE0100 (H), BMXNOE0110 (H), BMXNOC0401, BMXNOR0200H RTU (Todas las versiones), Procesadores Modicon Premium con Ethernet integrada (Copro): TSXP574634, TSXP575634, TSXP576634 (Todas las versiones), Procesadores Modicon Quantum con Ethernet integrado (Copro): 140CPU65xxxxx (Todas las versiones), Módulos de comunicación Modicon Quantum: 140NOE771x1, 140NOC78x00, 140NOC77101 (Todas las versiones), Módulos de comunicación Modicon Premium: TSXETY4103, TSXETY5103 (todas las versiones)
Vulnerabilidad en kernel de Linux (CVE-2021-46926)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: hda: intel-sdw-acpi: reforzar la detección del controlador El código existente actualmente establece un puntero a un identificador ACPI antes de verificar que en realidad es un controlador SoundWire. Esto puede provocar problemas en los que el recorrido del gráfico continúa y finalmente falla, pero el puntero ya estaba configurado. Este parche cambia la lógica para que la información proporcionada a la persona que llama se establezca cuando se encuentra un controlador.
Vulnerabilidad en kernel de Linux (CVE-2021-46927)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nitro_enclaves: use la llamada get_user_pages_unlocked() para manejar mmap afirmar. Después del commit 5b78ed24e8ec ("mm/pagemap: agregue anotaciones mmap_assert_locked() a find_vma*()"), la llamada a get_user_pages( ) activará la afirmación mmap. estático en línea void mmap_assert_locked(struct mm_struct *mm) { lockdep_assert_held(&mm->mmap_lock); VM_BUG_ON_MM(!rwsem_is_locked(&mm->mmap_lock), mm); } [62.521410] ¡ERROR del kernel en include/linux/mmap_lock.h:156! ................................................. ......... [ 62.538938] RIP: 0010:find_vma+0x32/0x80 ................................. ................................. [ 62.605889] Seguimiento de llamadas: [ 62.608502] [ 62.610956] ? LOCK_TIMER_BASE+0x61/0x80 [62.614106] find_extend_vma+0x19/0x80 [62.617195] __get_user_pages+0x9b/0x6a0 [62.6203356] __guup_longter_locked+0x42d/0x450 [62.620356] terminar_esperar+0x41/0x80 [62.626748]? __kmalloc+0x178/0x2f0 [ 62.629768] ne_set_user_memory_region_ioctl.isra.0+0x225/0x6a0 [nitro_enclaves] [ 62.635776] ne_enclave_ioctl+0x1cf/0x6d7 [nitro_enclaves] [ 62.639541] __x64 _sys_ioctl+0x82/0xb0 [ 62.642620] do_syscall_64+0x3b/0x90 [ 62.645642] Entry_SYSCALL_64_after_hwframe+0x44/0xae Utilice get_user_pages_unlocked() al configurar las regiones de memoria del enclave. Es un patrón similar al mmap_read_lock() usado junto con get_user_pages().
Vulnerabilidad en kernel de Linux (CVE-2021-46928)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: parisc: borra el valor IIR obsoleto en la trampa de derechos de acceso a instrucciones Cuando ocurre una trampa 7 (derechos de acceso a instrucciones), esto significa que la CPU no pudo ejecutar una instrucción debido a que faltan permisos de ejecución en la región de la memoria. En este caso, parece que la CPU ni siquiera obtuvo la instrucción de la memoria y, por lo tanto, no la almacenó en el registro cr19 (IIR) antes de llamar al controlador de trampas. Entonces, el manejador de trampas encontrará algún valor obsoleto aleatorio en cr19. Este parche simplemente sobrescribe el valor IIR obsoleto con un valor mágico constante de "mala comida" (0xbaadf00d), con la esperanza de que la gente no empiece a intentar comprender los diversos valores IIR aleatorios en los volcados de la trampa 7.
Vulnerabilidad en kernel de Linux (CVE-2021-46929)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sctp: use call_rcu para liberar el endpoint. Este parche tiene como objetivo retrasar la liberación del endpoint llamando a call_rcu() para solucionar otro problema de use-after-free en sctp_sock_dump(): ERROR: KASAN: use-after-free en __lock_acquire+0x36d9/0x4c20 Rastreo de llamadas: __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h :135 [en línea] _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334 [en línea] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/ 0x120 net/core/sock.c:2774 lock_sock include/net/sock.h:1492 [en línea] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324 sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c: 5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527 __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065 netlink_dump+0x6 06/0x1080 neto/ netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [en línea] inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cm re neto /core/sock_diag.c:232 [en línea] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag. c:274 Este problema ocurre cuando se quita asoc y se libera el sk antiguo después de obtenerlo mediante asoc->base.sk y antes de llamar a lock_sock(sk). Para evitar que sk se libere, como titular de sk, ep debe estar activo al llamar a lock_sock(). Este parche usa call_rcu() y mueve sock_put y ep free a sctp_endpoint_destroy_rcu(), por lo que es seguro intentar mantener el ep bajo rcu_read_lock en sctp_transport_traverse_process(). Si sctp_endpoint_hold() devuelve verdadero, significa que este ep todavía está vivo, lo hemos retenido y podemos continuar descartándolo; Si devuelve falso, significa que este ep está muerto y puede liberarse después de rcu_read_unlock, y debemos omitirlo. En sctp_sock_dump(), después de bloquear el sk, si este ep es diferente de tsp->asoc->ep, significa que durante este volcado, este asoc se eliminó antes de llamar a lock_sock(), y el sk debe omitirse; Si este ep es el mismo con tsp->asoc->ep, significa que no se produce ningún despegue en este asoc y, debido a lock_sock, tampoco se producirá ningún despegue hasta que se libere_sock. Tenga en cuenta que retrasar la liberación del endpoint no retrasará la liberación del puerto, ya que la liberación del puerto ocurre en sctp_endpoint_destroy() antes de llamar a call_rcu(). Además, liberar el endpoint mediante call_rcu() hace que sea seguro acceder a sk mediante asoc->base.sk en sctp_assocs_seq_show() y sctp_rcv(). Gracias Jones por plantear este problema. v1->v2: - mejorar el registro de cambios. - agregue kfree(ep) a sctp_endpoint_destroy_rcu(), como notó Jakub.
Vulnerabilidad en kernel de Linux (CVE-2021-46930)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: mtu3: corrección de advertencia de verificación de list_head Esto se debe a la desinicialización de list_head. ERROR: KASAN: uso después de la liberación en __list_del_entry_valid+0x34/0xe4 Rastreo de llamadas: dump_backtrace+0x0/0x298 show_stack+0x24/0x34 dump_stack+0x130/0x1a8 print_address_description+0x88/0x56c __kasan_report+0x1b8/0x2a0 kasan_report +0x14/0x20 __asan_load8+ 0x9c/0xa0 __list_del_entry_valid+0x34/0xe4 mtu3_req_complete+0x4c/0x300 [mtu3] mtu3_gadget_stop+0x168/0x448 [mtu3] usb_gadget_unregister_driver+0x204/0x3a0 unregister_gadget_item+0x44/0xa4
Vulnerabilidad en kernel de Linux (CVE-2021-46931)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: envuelve la devolución de llamada del volcado de tx reporter para extraer el sq. La función mlx5e_tx_reporter_dump_sq() lanza su argumento void * a la estructura mlx5e_txqsq *, pero en el flujo TX-timeout-recovery el argumento en realidad es de tipo struct mlx5e_tx_timeout_ctx *. mlx5_core 0000: 08: 00.1 enp8s0f1: tx timeout detectado mlx5_core 0000: 08: 00.1 enp8s0f1: tx timeout en cola: 1, sq: 0x11ec, cq: 0x146d, sq consecuencia: 0x0 sq prod: 0x1, usecs desde el último trans: 21565000 : la página de protección de pila fue visitada en 0000000093f1a2de (la pila es 00000000b66ea0dc..000000004d932dae) Desbordamiento de pila del kernel (fallo de página): 0000 [#1] SMP NOPTI CPU: 5 PID: 95 Comm: kworker/u20:1 Contaminado: GW OE 5.13. 0_mlnx #1 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 Cola de trabajo: mlx5e mlx5e_tx_timeout_work [mlx5_core] RIP: 0010:mlx5e_tx_reporter_ volcado_sq +0xd3/0x180 [mlx5_core] Seguimiento de llamadas: mlx5e_tx_reporter_dump+0x43/0x1c0 [mlx5_core] devlink_health_do_dump.part.91+0x71/0xd0 devlink_health_report+0x157/0x1b0 mlx5e_reporter_tx_timeout+0xb9/0xf0 [ml x5_core] ? mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0 [mlx5_core] ? mlx5e_health_queue_dump+0xd0/0xd0 [mlx5_core] ? update_load_avg+0x19b/0x550? set_next_entity+0x72/0x80? pick_next_task_fair+0x227/0x340? Finish_task_switch+0xa2/0x280 mlx5e_tx_timeout_work+0x83/0xb0 [mlx5_core] Process_one_work+0x1de/0x3a0 trabajador_thread+0x2d/0x3c0? proceso_one_work+0x3a0/0x3a0 kthread+0x115/0x130 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30 --[ end trace 51ccabea504edaff ]--- RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 PKRU: 55555554 Pánico del kernel - no sincronizado: excepción fatal Compensación del kernel: final deshabilitado Pánico del kernel - no sincronizar : Excepción fatal Para corregir este error, agregue un contenedor para mlx5e_tx_reporter_dump_sq() que extrae el sq de la estructura mlx5e_tx_timeout_ctx y lo configura como devolución de llamada de volcado de flujo de recuperación de tiempo de espera de TX.
Vulnerabilidad en kernel de Linux (CVE-2021-46932)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Entrada: appletouch: inicializa el trabajo antes del registro del dispositivo Syzbot ha informado una advertencia en __flush_work(). Esta advertencia es causada por work->func == NULL, lo que significa que falta la inicialización del trabajo. Esto puede suceder, ya que input_dev->close() llama a cancel_work_sync(&dev->work), pero la inicialización dev->work ocurre _después_ de la llamada input_register_device(). Entonces este parche mueve la inicialización dev->work antes de registrar el dispositivo de entrada
Vulnerabilidad en kernel de Linux (CVE-2021-46933)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: gadget: f_fs: Borrar ffs_eventfd en ffs_data_clear. ffs_data_clear se llama indirectamente desde ffs_fs_kill_sb y ffs_ep0_release, por lo que termina siendo llamado dos veces cuando el área de usuario cierra ep0 y luego desmonta f_fs. Si Userland proporcionó un eventfd junto con los descriptores USB de la función, termina llamando a eventfd_ctx_put tantas veces, provocando un desbordamiento insuficiente de recuento. NULL-ify ffs_eventfd para evitar estas llamadas extrañas eventfd_ctx_put. Además, establezca epfiles en NULL justo después de desasignarlo, para facilitar la lectura. Para completar, ffs_data_clear en realidad termina siendo llamado tres veces, la última llamada es antes de que se libere toda la estructura de ffs, por lo que cuando ocurre esta secuencia específica, se produce un segundo desbordamiento insuficiente (pero no se informa): /sys/kernel/debug/tracing # modprobe usb_f_fs /sys/kernel/debug/tracing# echo ffs_data_clear > set_ftrace_filter /sys/kernel/debug/tracing# echo function > current_tracer /sys/kernel/debug/tracing# echo 1 > tracing_on (dispositivo de configuración, función ejecutar y finalizar proceso de usuario, dispositivo de desmontaje) /sys/kernel/debug/tracing# echo 0 > tracing_on /sys/kernel/debug/tracing# cat trace smartcard-openp-436 [000] ..... 1946.208786: ffs_data_clear <-ffs_data_closed tarjeta inteligente -openp-431 [000] ..... 1946.279147: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] .n... 1946.905512: ffs_data_clear <-ffs_data_put Salida de advertencia correspondiente al seguimiento anterior: [ 1946.284139] ADVERTENCIA: CPU : 0 PID: 431 en lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c [ 1946.293094] refcount_t: desbordamiento insuficiente; use-after-free. [1946.298164] Módulos vinculados en: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E ) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_b cm2835 (CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E ) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c (E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E ) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E) [ 1946.399633] CPU: 0 PID: 431 Comm: tarjeta inteligente- openp Contaminado: GC OE 5.15.0-1-rpi #1 Debian 5.15.3-1 [ 1946.417950] Nombre de hardware: BCM2835 [ 1946.425442] Seguimiento inverso: [ 1946.432048] [] (dump_backtrace) de [] ( show_stack+0x20/0x24) [ 1946.448226] r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c [ 1946.458412] [] (show_stack) de [] (dump_ pila+0x28/0x30) [ 1946.470380] [< c08d9ab8>] (dump_stack) de [] (__warn+0xe8/0x154) [ 1946.482067] r5:c04a948c r4:c0a71dc8 [ 1946.490184] [] (__warn) de [] (warn_slowpath_fmt+0xa0/ 0xe4) [ 1946.506758] r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04 [ 1946.517070] [] (warn_slowpath_fmt) de [] (refcount_war n_saturado+0x110/0x15c) [ 1946.535309] r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0 [ 1946.546708] [] (refcount_warn_saturate) de [] (eventfd_ctx_put+0x48/0x74) [ 1946.564476] [] (eventfd_ctx_put) de [] (ffs_data_clear+0xd0/0x118 [usb_f_fs]) [ 1946.582664] r5:c3b84c00 r4:c2695b00 [ 1946.590668] [] (ffs_data_clear [usb_f_fs]) de [] ( ffs_data_closed+0x9c/0x150 [usb_f_fs]) [ 1946.609608] r5:bf54d014 r4:c2695b00 [ 1946.617522] [] (ffs_data_closed [usb_f_fs
Vulnerabilidad en kernel de Linux (CVE-2021-46934)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: validar datos de usuario en compat ioctl Los datos de usuario incorrectos pueden causar advertencia en i2c_transfer(), ej: cero mensajes. El espacio de usuario no debería poder activar advertencias, por lo que este parche agrega comprobaciones de validación para los datos del usuario en ioctl compacto para evitar advertencias reportadas.
Vulnerabilidad en kernel de Linux (CVE-2021-46935)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: binder: corrige la contabilidad async_free_space para paquetes vacíos En 4.13, el commit 74310e06be4d ("android: binder: mover el búfer fuera del área compartida con el espacio del usuario") solucionó un problema de visibilidad de la estructura del kernel. Como parte de ese parche, se usó sizeof(void *) como tamaño de búfer para cargas de datos de longitud 0, de modo que el controlador pudiera detectar clientes abusivos que enviaran transacciones asincrónicas de longitud 0 a un servidor imponiendo límites en async_free_size. Desafortunadamente, en el lado "libre", la contabilidad de async_free_space no volvió a agregar el tamaño de (void *). El resultado fue que se filtraron hasta 8 bytes de async_free_space en cada transacción asíncrona de 8 bytes o menos. Estas pequeñas transacciones son poco comunes, por lo que este problema contable ha pasado desapercibido durante varios años. La solución es utilizar "buffer_size" (el tamaño del búfer asignado) en lugar de "size" (el tamaño del búfer lógico) al actualizar async_free_space durante la operación libre. Son iguales excepto por este caso de esquina de transacciones asincrónicas con payloads <8 bytes.
Vulnerabilidad en kernel de Linux (CVE-2021-46936)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: corrige use-after-free en tw_timer_handler Se encontró un problema de pánico en el mundo real como se muestra a continuación en Linux 5.4. ERROR: no se puede manejar el error de página para la dirección: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP: 0010:tw_timer_handler+0x20/0x40 Seguimiento de llamadas: call_timer_fn+0x2b/ 0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/ 0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20 Este problema también se informó desde 2017 en el hilo [1], desafortunadamente, el problema aún se puede reproducir después de corregir DCCP. ipv4_mib_exit_net se llama antes de tcp_sk_exit_batch cuando se destruye un espacio de nombres de red, ya que tcp_sk_ops está registrado antes de ipv4_mib_ops, lo que significa que tcp_sk_ops está al frente de ipv4_mib_ops en la lista de pernet_list. Habrá un use-after-free en net->mib.net_statistics en tw_timer_handler después de ipv4_mib_exit_net si hay algunos temporizadores de espera a bordo. Este error no se introduce mediante la confirmación f2bf415cfed7 ("mib: add net to NET_ADD_STATS_BH") ya que net_statistics es una variable global en lugar de una asignación y liberación dinámicas. En realidad, la confirmación 61a7e26028b9 ("mib: poner estadísticas de red en struct net") introduce el error ya que coloca estadísticas de red en struct net y las libera cuando se destruye el espacio de nombres de red. Mover init_ipv4_mibs() al frente de tcp_init() para corregir este error y reemplazar pr_crit() con pánico() ya que continuar no tiene sentido cuando init_ipv4_mibs() falla. [1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1
Vulnerabilidad en kernel de Linux (CVE-2021-46937)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/damon/dbgfs: corrige las fugas de 'struct pid' en 'dbgfs_target_ids_write()' La interfaz DAMON debugfs aumenta los recuentos de referencias de 'struct pid' para los objetivos de la escritura del archivo 'target_ids' devolución de llamada ('dbgfs_target_ids_write()'), pero disminuye los recuentos solo en la devolución de llamada de terminación de monitoreo de DAMON ('dbgfs_before_terminate()'). Por lo tanto, cuando el archivo 'target_ids' se escribe repetidamente sin que DAMON supervise el inicio/terminación, el recuento de referencias no disminuye y, por lo tanto, no se puede liberar memoria para 'struct pid'. Este commit soluciona este problema al disminuir el recuento de referencias cuando se escribe 'target_ids'.
Vulnerabilidad en kernel de Linux (CVE-2020-36776)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Thermal/drivers/cpufreq_cooling: solucionar el problema de Slab OOB El problema de Slab OOB es escaneado por KASAN en cpu_power_to_freq(). Si la potencia se limita por debajo de la potencia de OPP0 en la tabla EM, provocará un problema de losa fuera de los límites con un índice de matriz negativo. Devuelve la frecuencia más baja si la potencia limitada no puede encontrar un OPP adecuado en la tabla EM para solucionar este problema. Seguimiento inverso: [] die+0x104/0x5ac [] bug_handler+0x64/0xd0 [] brk_handler+0x160/0x258 [] do_debug_exception+0x 248/0x3f0 [] el1_dbg+0x14 /0xbc [] __kasan_report+0x1dc/0x1e0 [] kasan_report+0x10/0x20 [] __asan_report_load8_noabort+0x18/0x28 [] cpufreq_power2state+0x180/0x43c [] power_actor_set_power+0x114 /0x1d4 [] allocate_power+0xaec/0xde0 [] power_allocator_throttle+0x3ec/0x5a4 [] handle_thermal_trip+0x160/0x294 [] térmico _zone_device_check+0xe4/0x154 [] proceso_one_work+0x5e4 /0xe28 [] work_thread+0xa4c/0xfac [] kthread+0x33c/0x358 [] ret_from_fork+0xc/0x18
Vulnerabilidad en kernel de Linux (CVE-2020-36777)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: dvbdev: corrige la pérdida de memoria en dvb_media_device_free() dvb_media_device_free() está perdiendo memoria. Libere `dvbdev->adapter->conn` antes de configurarlo en NULL, como se documenta en include/media/media-device.h: "La instancia media_entity debe ser liberada explícitamente por el controlador si es necesario".
Vulnerabilidad en kernel de Linux (CVE-2021-46938)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm rq: corrige la liberación doble de blk_mq_tag_set en dev y se elimina después de que falla la carga de la tabla Al cargar una tabla de mapeador de dispositivos para un dispositivo mapeado basado en solicitudes y la asignación/inicialización de blk_mq_tag_set Si el dispositivo falla, la siguiente eliminación del dispositivo provocará una doble liberación. Por ejemplo, (dmesg): mapeador de dispositivos: núcleo: no se puede inicializar la cola para el dispositivo asignado dm-mq basado en solicitudes mapeador de dispositivos: ioctl: no se puede configurar la cola de dispositivos para una nueva tabla. No se puede manejar la desreferencia del puntero del kernel en el espacio de direcciones virtual del kernel Dirección fallida: 0305e098835de000 TEID: 0305e098835de803 Fallo en el modo de espacio de inicio mientras se usa el kernel ASCE. AS:000000025efe0007 R3:0000000000000024 Ups: 0038 ilc:3 [#1] Módulos SMP vinculados en: ... muchos módulos ... Compatible: Sí, CPU externa: 0 PID: 7348 Comm: multipathd Kdump: cargado Contaminado: GWX 5.3.18-53-default #1 SLE15-SP3 Nombre de hardware: IBM 8561 T01 7I2 (LPAR) Krnl PSW: 0704e00180000000 000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Clave:0 M :1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 00000000000000000 000000025e520270 000000025 e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 0 00003ff80138650 000000025e5202a2 000003e00396faa8 Código Krnl: 000000025e368eb8: c4180041e100 lgrl % r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310 b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Seguimiento de llamadas: [<0 00000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/ 0xb8 [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x1 50/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe /0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [ <000000025e8c15ac>] system_call+0xd8/0x2c8 Última dirección del evento de última hora: [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 Pánico del kernel: no se sincroniza: excepción grave: pánico_on_oops Cuando la asignación/inicialización de blk_mq_tag_set falla en d m_mq_init_request_queue(), no está inicializado/liberado, pero el puntero no se restablece a NULL; entonces, cuando dev_remove() ingresa más tarde a dm_mq_cleanup_mapped_device(), ve el puntero e intenta desinicializarlo y liberarlo nuevamente. Solucione este problema estableciendo el puntero en NULL en el manejo de errores dm_mq_init_request_queue(). También configúrelo en NULL en dm_mq_cleanup_mapped_device().
Vulnerabilidad en kernel de Linux (CVE-2021-46939)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rastreo: reestructurar trace_clock_global() para no bloquear nunca. Se informó que una solución a la detección de recursividad del búfer circular provocaría que la máquina se bloqueara al realizar pruebas de suspensión/reanudación. El siguiente seguimiento se extrajo de la depuración de ese caso: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7 /0xf0? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0? trace_clock_global+0x91/0xa0? __rb_reserve_next+0x237/0x460? ring_buffer_lock_reserve+0x12a/0x3f0? trace_event_buffer_lock_reserve+0x3c/0x120? trace_event_buffer_reserve+0x6b/0xc0? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0? dpm_run_callback+0x3b/0xc0? pm_ops_is_empty+0x50/0x50? platform_get_irq_byname_opcional+0x90/0x90? trace_device_pm_callback_start+0x82/0xd0? dpm_run_callback+0x49/0xc0 Con el siguiente RIP: RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200 Dado que la solución a la detección de recursión permitiría que ocurriera una sola recursión durante el seguimiento, esto llevó a trace_clock_global() a tomar un bloqueo de giro y luego intentarlo para tomarlo de nuevo: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* bloqueo tomado */ (algo más es rastreado por la función de seguimiento del gráfico) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath () { /* ¡BLOQUEO MUERTO! */ El rastreo *nunca* debe bloquearse, ya que puede provocar bloqueos extraños como el anterior. Reestructura el código trace_clock_global() para que, en lugar de simplemente tomar un bloqueo para actualizar el "prev_time" registrado, simplemente lo uses, ya que dos eventos suceden en dos CPU diferentes que llaman a esto al mismo tiempo, realmente no importa cuál va primero. Utilice un trylock para obtener el bloqueo para actualizar prev_time y, si falla, simplemente inténtelo de nuevo la próxima vez. Si no se pudo tomar, eso significa que algo más ya lo está actualizando. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761
Vulnerabilidad en kernel de Linux (CVE-2021-46940)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: herramientas/turbostat de potencia: soluciona el problema de desbordamiento de compensación en la conversión de índice. La función idx_to_offset() devuelve el tipo int (32 bits firmado), pero MSR_PKG_ENERGY_STAT es u32 y se interpretaría como negativo. número. El resultado final es que alcanza la verificación if (offset < 0) en update_msr_sum(), lo que evita que la devolución de llamada del temporizador actualice la estadística en segundo plano cuando se utilizan duraciones prolongadas. Existe un problema similar en offset_to_idx() y update_msr_sum(). Solucione este problema convirtiendo 'int' a 'off_t' en consecuencia.
Vulnerabilidad en kernel de Linux (CVE-2021-46941)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: core: Realiza un reinicio suave del núcleo al cambiar de modo Según la guía de programación, para cambiar el modo del controlador DRD, el controlador debe hacer lo siguiente. Para cambiar de dispositivo a host: 1. Reinicie el controlador con GCTL.CoreSoftReset 2. Configure GCTL.PrtCapDir (modo de host) 3. Reinicie el host con USBCMD.HCRESET 4. Luego siga con la secuencia de inicialización de registros del host Para cambiar de host a dispositivo: 1. Reinicie el controlador con GCTL.CoreSoftReset 2. Configure GCTL.PrtCapDir (modo de dispositivo) 3. Reinicie el dispositivo con DCTL.CSftRst 4. Luego siga con la secuencia de inicialización de registros Actualmente nos falta el paso 1) para hacer GCTL .CoreSoftReset y paso 3) de cambio de host a dispositivo. John Stult informó un problema de bloqueo observado con la plataforma HiKey960 sin estos pasos[1]. Se observa un problema similar con la plataforma de pruebas de Ferry[2]. Entonces, aplique los pasos requeridos junto con algunas correcciones a la versión de Yu Chen y John Stultz. Las principales correcciones a sus versiones son la falta de espera para la sincronización de los relojes antes de borrar GCTL.CoreSoftReset y solo aplicar DCTL.CSftRst al cambiar de host a dispositivo. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7- 9cd4-0695-64fc927e01f1@gmail.com/
Vulnerabilidad en kernel de Linux (CVE-2021-46942)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corrige bloqueos de cancelación de sqpoll compartido [736.982891] INFORMACIÓN: tarea iou-sqp-4294:4295 bloqueada durante más de 122 segundos. [ 736.982897] Seguimiento de llamadas: [ 736.982901] agenda+0x68/0xe0 [ 736.982903] io_uring_cancel_sqpoll+0xdb/0x110 [ 736.982908] io_sqpoll_cancel_cb+0x24/0x30 [ 736.982911] io_run_task_work_head+0x28/0x50 [ 736.982913] io_sq_thread+0x4e3/0x720 Llamamos a io_uring_cancel_sqpoll( ) uno por uno para cada ctx, ya sea en sq_thread() o mediante tareas, y está destinado a cancelar todas las solicitudes de un contexto específico. Sin embargo, la función utiliza contadores por tarea para rastrear la cantidad de solicitudes en curso, por lo que cuenta más solicitudes de las disponibles a través de currect io_uring ctx y se pone en suspensión para que aparezcan (por ejemplo, desde IRQ), eso nunca sucederá. Cancele un poco más que antes, es decir, todos los ctx que comparten sqpoll y continúan usando contadores compartidos. No olvide que no debemos eliminar ctx de la lista antes de ejecutar task_work sqpoll-cancel; de lo contrario, la función no podrá encontrar el contexto y se bloqueará.
Vulnerabilidad en kernel de Linux (CVE-2021-46943)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: staging/intel-ipu3: Corrija el manejo de errores set_fmt Si ocurre un error durante un set_fmt, no sobrescriba los tamaños anteriores con la configuración no válida. Sin este parche, el cumplimiento de v4l2 termina asignando 4 GiB de RAM y provocando los siguientes OOP [38.662975] ipu3-imgu 0000:00:05.0: el búfer swiotlb está lleno (sz: 4096 bytes) [38.662980] DMA: Fuera de SW-IOMMU espacio para 4096 bytes en el dispositivo 0000:00:05.0 [38.663010] falla de protección general: 0000 [#1] PREEMPT SMP
Vulnerabilidad en kernel de Linux (CVE-2021-46944)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: staging/intel-ipu3: Reparar pérdida de memoria en imu_fmt Estamos perdiendo la referencia a una memoria asignada si lo intentamos. Cambie el orden del cheque para evitarlo.
Vulnerabilidad en kernel de Linux (CVE-2021-46945)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: siempre entra en pánico cuando se especifica errores=panic Antes del commit 014c9caa29d3 ("ext4: make ext4_abort() use __ext4_error()"), la siguiente serie de comandos desencadenaría un pánico: 1. mount /dev/sda -o ro,errors=panic test 2. mount /dev/sda -o remount,abort test Después de el commit 014c9caa29d3, volver a montar un sistema de archivos utilizando la opción de montaje de prueba "abort" ya no provocará pánico . Esta confirmación restaurará el comportamiento inmediatamente anterior a el commit 014c9caa29d3. (Sin embargo, tenga en cuenta que el comportamiento del kernel de Linux no ha sido consistente; algunas versiones anteriores del kernel, incluidas 5.4 y 4.19, tampoco entraron en pánico después de usar la opción de montaje "abortar".) Esto también supone un cambio en el comportamiento de larga data; es decir, los siguientes comandos de la serie ahora causarán pánico, cuando antes no lo hacían: 1. mount /dev/sda -o ro,errors=panic test 2. echo test > /sys/fs/ext4/sda/trigger_fs_error Sin embargo, Esto hace que el comportamiento de ext4 sea mucho más consistente, por lo que es algo bueno.
Vulnerabilidad en kernel de Linux (CVE-2021-46947)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: ajuste efx->xdp_tx_queue_count con el número real de colas inicializadas. efx->xdp_tx_queue_count se inicializa inicialmente en num_possible_cpus() y luego se usa para asignar y recorrer la búsqueda de efx->xdp_tx_queues formación. Sin embargo, es posible que terminemos sin inicializar todas las ranuras de la matriz con colas reales durante el sondeo. Esto da como resultado, por ejemplo, una desreferencia del puntero NULL, cuando se ejecuta "# ethtool -S ", similar a lo siguiente [2570283.664955][T4126959] ERROR: desreferencia del puntero NULL del kernel, dirección: 000000000000000f8 [2570283.681283][T4126959] # PF: acceso de lectura de supervisor en modo kernel [2570283.695678][T4126959] #PF: error_code(0x0000) - página no presente [2570283.710013][T4126959] PGD 0 P4D 0 [2570283.721649][T4126959] Ups: 0000 [# 1]MPD PTI [2570283.734108][T4126959] CPU: 23 PID: 4126959 Comunicaciones: ethtool Contaminado: GO 5.10.20-cloudflare-2021.3.1 #1 [2570283.752641][T4126959] Nombre de hardware: [2570283.78140 8][T4126959] QEPD: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc] [2570283.796073][T4126959] Código: 00 85 c0 74 39 48 8b 95 a8 0f 00 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95 a8 0f 00 00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca <48> 8b 92 f8 00 00 00 49 89 54 24 f8 39 85 a0 0f 00 00 77 d7 48 8b [2570283.831259][T4126959] RSP: 0018:ff ffb79a77657ce8 EFLAGS: 00010202 [2570283.845121 ][T4126959] RAX: 0000000000000019 RBX: ffffb799cd0c9280 RCX: 0000000000000018 [2570283.860872][T4126959] RDX: 0000000000000000 RSI: ffff96dd 970ce000 RDI: 0000000000000005 [2570283.876525][T4126959] RBP: ffff96dd86f0a000 R08: ffff96dd970ce480 R09: 000000000000005f [2570283.892014][T4 126959]R10 : ffffb799cd0c9fff R11: ffffb799cd0c9000 R12: ffffb799cd0c94f8 [2570283.907406][T4126959] R13: ffffffffc11b1090 R14: ffff96dd970ce000 R15: ffffffffc11cd66 c [2570283.922705][T4126959] FS: 00007fa7723f8740(0000) GS:ffff96f51fac0000(0000) knlGS:00000000000000000 [2570283.938848][T4126959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2570283.952524][T4126959] CR2: 000000000000000f8 CR3: 0000001a73e6e006 CR4: 00000000007706 e0 [2570283.967529][T4126959] DR0: 00000000000000000 DR1: 0000000000000000 DR2: 00000000000000000 [2570283.982400][T4126959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [2570283.997308][T4126959] PKRU: 55555554 [2570284.007649][T4126959] Seguimiento de llamadas: [257 0284.017598][T4126959] dev_ethtool+0x1832/0x2830 Solucione este problema ajustando efx->xdp_tx_queue_count después de sondear para reflejar el verdadero valor de las ranuras inicializadas en efx->xdp_tx_queues.
Vulnerabilidad en kernel de Linux (CVE-2021-46948)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: farch: corrige la búsqueda de cola TX en el manejo de eventos TX Estamos comenzando desde una etiqueta TXQ, no un tipo TXQ, por lo que efx_channel_get_tx_queue() es inapropiado (y podría devolver NULL, provocando pánico).
Vulnerabilidad en kernel de Linux (CVE-2021-46949)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: farch: corrige la búsqueda de la cola TX en el manejo finalizado del vaciado TX. Estamos comenzando desde un número de instancia TXQ ('qid'), no un tipo TXQ, por lo que efx_get_tx_queue() es inapropiado (y podría devolver NULL, lo que provocaría pánico).
Vulnerabilidad en kernel de Linux (CVE-2021-46950)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid1: indica correctamente el error al finalizar una solicitud de escritura fallida. Este parche soluciona un error de corrupción de datos en matrices raid1 que utilizan mapas de bits. Sin esta solución, los bits del mapa de bits de la E/S fallida terminan borrándose. Dado que estamos en el tramo fallido de raid1_end_write_request, es necesario volver a intentar la solicitud (R1BIO_WriteError) o fallar (R1BIO_Degraded).
Vulnerabilidad en kernel de Linux (CVE-2021-46951)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tpm: efi: use la variable local para calcular el tamaño del registro final Cuando se llama a tpm_read_log_efi varias veces, lo que sucede cuando uno carga y descarga un controlador TPM2 varias veces, entonces la variable global efi_tpm_final_log_size en algún momento se convierte en un número negativo debido a la resta de final_events_preboot_size que ocurre cada vez. Utilice una variable local para evitar este desbordamiento de enteros. El siguiente problema ahora está resuelto: 8 de marzo 15:35:12 kernel hibinst: Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 0.0.0 06/02/2015 8 de marzo 15:35:12 kernel hibinst: Cola de trabajo: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy] 8 de marzo 15:35:12 kernel de hibinst: RIP: 0010:__memcpy+0x12/0x20 8 de marzo 15:35:12 kernel de hibinst: Código: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 8 de marzo 15:35:12 kernel de hibinst: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206 8 de marzo 15:35:12 kernel de hibinst: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ff ffffffffffe0f 8 de marzo 15:35:12 kernel de hibinst: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d 8 de marzo 15:35:12 kernel de hibinst: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000 000007e9d6073 8 de marzo 15:35:12 kernel hibinst: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5 8 de marzo 15:35:12 kernel de hibinst: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018 8 de marzo 15:35:12 kernel de hibinst: FS: 0000000000000000(0000) GS:ffff8 8f87bd00000(0000) knlGS:0000000000000000 8 de marzo a las 15:35: 12 kernel de hibinst: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 8 de marzo 15:35:12 kernel de hibinst: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0 8 de marzo 15:35:12 kernel de hibinst: Seguimiento de llamadas: 8 de marzo 15:35:12 Hibinst Kernel: tpm_read_log_efi+0x152/0x1a7 mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0 mar 8 15:35:12 hibinst kernel: tpm_chip_register kernel de hibinst: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy] 8 de marzo 15:35:12 kernel de hibinst: Process_one_work+0x1b4/0x370 8 de marzo 15:35:12 kernel de hibinst: work_thread+0x53/0x3e0 8 de marzo 15:35:12 kernel de hibinst : ? proceso_un_trabajo+0x370/0x370
Vulnerabilidad en kernel de Linux (CVE-2021-46952)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFS: fs_context: valida las retransmisiones UDP para evitar cambios fuera de los límites. Corrige cambios fuera de los límites en xprt_calc_majortimeo(). Esto se debe a que se pasa una opción de montaje de tiempo de espera de basura (retransmisión) al montaje nfs, en este caso desde syzkaller. Si el protocolo es XPRT_TRANSPORT_UDP, entonces 'retrans' es un valor de desplazamiento para un entero largo de 64 bits, por lo que 'retrans' no puede ser >= 64. Si es >= 64, falla el montaje y devuelve un error.
Vulnerabilidad en kernel de Linux (CVE-2021-46953)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ACPI: GTDT: no corrompe las asignaciones de interrupciones en caso de falla de la sonda de vigilancia. Cuando falla la sonda del controlador debido a propiedades de firmware no válidas, el controlador GTDT desasigna la interrupción que asignó anteriormente. Sin embargo, nunca comprueba si el mapeo de la interrupción realmente tuvo éxito. Aún más, si el firmware informa un número de interrupción ilegal que se superpone con el rango GIC SGI, esto puede resultar en que un IPI no se asigne y en posteriores fuegos artificiales (según lo informado por Dann Frazier). Vuelva a trabajar el controlador para que tenga un comportamiento un poco más sensato y verifique si la interrupción se ha asignado antes de desasignar las cosas.
Vulnerabilidad en kernel de Linux (CVE-2021-46954)
Severidad: Pendiente de análisis
Fecha de publicación: 27/02/2024
Fecha de última actualización: 10/04/2024
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: sch_frag: corrige la lectura OOB de la pila al fragmentar paquetes IPv4 cuando 'act_mirred' intenta fragmentar paquetes IPv4 que se habían reensamblado previamente usando 'act_ct', símbolos como el Se puede observar lo siguiente en los núcleos creados con KASAN: ERROR: KASAN: pila fuera de los límites en ip_do_fragment+0x1b03/0x1f60 Lectura de tamaño 1 en la dirección ffff888147009574 mediante tarea ping/947 CPU: 0 PID: 947 Comm: ping no contaminado 5.12.0-rc6+ #418 Nombre de hardware: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 01/04/2014 Seguimiento de llamadas: dump_stack+0x92/0xc1 print_address_description.constprop. 7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 sch_fragment+0x4bf/0xe40 tcf_mirred_act+0xc3d/0x11a0 [act_mirred] tcf_action_exec+0x104/0x3e0 fl_classify+0 x49a/0x5e0 [cls_flower] tcf_classify_ingress+0x18a/0x820 __netif_receive_skb_core+0xae7/0x3340 __netif_receive_skb_one_core+0xb6/0x1b0 Process_backlog+0x1ef/0x6c0 __napi_poll+0xaa/0x500 net_rx_action+0x702/0xac0 __do_softirq+0x1e4/0x97f do_softirq +0x71/0x90 __local_bh_enable_ip+0xdb/0xf0 ip_finish_output2+0x760/0x2120 ip_do_fragment +0x15a5/0x1f60 __ip_finish_output+0x4c2/0xea0 ip_output+0x1ca/0x4d0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x1c4b/0x2d00 sock_sendmsg+0xdb/0x110 __sys_sendto+0x1d7/0x 2b0 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0x33/0x40 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP : 0033:0x7f82e13853eb Código: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48 > 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89 RSP: 002b:00007ffe01fad888 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffff ffffffffffda RBX: 00005571aac13700 RCX: 00007f82e13853eb RDX: 0000000000002330 RSI: 00005571aac13700 RDI: 0000000000000003 RBP: 0000000000002330 R08: 00005571aac10500 R09: 0000000000000010 R10: 00000000000000000 R11: 0000000000000246 R12: 00007ffe01faefb0 R13: 00007ffe01fad890 R14: 00007ffe01fad980 R15: 00005571aac0f0a0 La dirección del error pertenece a la página: página:000000001dff2e03 refcount:1 mapcount:0 mapeo:0000000000000000 índice: 0x0 pfn:0x147009 banderas: 0x17ffffc0001000(reservado) raw: 0017ffffc0001000 ffffea00051c0248 ffffea00051c0248 0000000000000000 raw: 0000000000000000 0000 000000000000 00000001ffffffff 00000000000000000 página volcada porque: kasan: se detectó mal acceso Estado de la memoria alrededor de la dirección con errores: ffff888147009400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888147009480: f1 f1 f1 f1 04 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 >ffff888147009500: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f 2 f2 f2^ffff888147009580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888147009600: 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 para paquetes IPv4, sch_fragment() utiliza una estructura temporal dst_entry. Luego, en el siguiente gráfico de llamadas: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() el puntero a struct dst_entry se usa como puntero a struct rtable: esto convierte el acceso a miembros de estructura como rt_mtu_locked en una lectura OOB en la pila. Solucione este problema cambiando la variable temporal utilizada para los paquetes IPv4 en sch_fragment(), de manera similar a lo que se hace para IPv6 unas líneas más abajo.