Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: arm64: corrige el recuento de PGD de etapa 2 del host La librería de tablas de páginas de KVM vuelve a contar las páginas de los PGD de etapa 2 concatenados individualmente. Sin embargo, cuando se ejecuta KVM en modo protegido, EL2 administra actualmente el PGD de etapa 2 del host como una única página compuesta de alto orden, lo que puede causar que el recuento de las páginas finales llegue a 0 cuando no debería, corrompiendo así el tabla de páginas. Solucione este problema introduciendo un nuevo asistente hyp_split_page() en el asignador de páginas EL2 (que coincida con la función split_page() del kernel) y utilícelo desde host_s2_zalloc_pages_exact().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: xt_IDLETIMER: corrige el pánico que ocurre cuando timer_type tiene valor basura Actualmente, cuando se agrega la regla relacionada con IDLETIMER, kmalloc inicializa la estructura del temporizador idletimer_tg al ejecutar la función idletimer_tg_create. Sin embargo, en este proceso timer->timer_type no está definido en un valor específico. Por lo tanto, timer->timer_type tiene un valor basura y se produce un pánico en el kernel. Entonces, esta confirmación soluciona el pánico al inicializar timer->timer_type usando kzalloc en lugar de kmalloc. Comandos de prueba: # iptables -A OUTPUT -j IDLETIMER --timeout 1 --label test $ cat /sys/class/xt_idletimer/timers/test Killed Splat se ve así: ERROR: KASAN: acceso a memoria de usuario en alarm_expires_remaining+0x49/ 0x70 Lectura del tamaño 8 en la dirección 0000002e8c7bc4c8 por tarea cat/917 CPU: 12 PID: 917 Comm: cat Not tainted 5.14.0+ #3 79940a339f71eb14fc81aee1757a20d5bf13eb0e Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 009), BIOS 1.13.0- 1ubuntu1.1 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x6e/0x9c kasan_report.cold+0x112/0x117 ? alarm_expires_remaining+0x49/0x70 __asan_load8+0x86/0xb0 alarm_expires_remaining+0x49/0x70 idletimer_tg_show+0xe5/0x19b [xt_IDLETIMER 11219304af9316a21bee5ba9d58f76a6b9bccc6d] tr_show+0x3c/0x60 sysfs_kf_seq_show+0x11d/0x1f0 ? device_remove_bin_file+0x20/0x20 kernfs_seq_show+0xa4/0xb0 seq_read_iter+0x29c/0x750 kernfs_fop_read_iter+0x25a/0x2c0 ? __fsnotify_parent+0x3d1/0x570? iov_iter_init+0x70/0x90 new_sync_read+0x2a7/0x3d0? __x64_sys_llseek+0x230/0x230 ? rw_verify_area+0x81/0x150 vfs_read+0x17b/0x240 ksys_read+0xd9/0x180 ? vfs_write+0x460/0x460? do_syscall_64+0x16/0xc0? lockdep_hardirqs_on+0x79/0x120 __x64_sys_read+0x43/0x50 do_syscall_64+0x3b/0xc0 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f0cdc819142 Código: c0 e9 c2 fe ff ff 50 48 8d 3d 3a ca 0a 00 e8 f5 19 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 RSP: :00007fff28eee5b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 000000000020000 RCX: 00007f0cdc819142 RDX: 0000000000020000 RSI: 00007f0cdc03200 0 RDI: 0000000000000003 RBP: 00007f0cdc032000 R08: 00007f0cdc031010 R09: 0000000000000000 R10: 0000000000000022 R11: 00000000000000246 R 12: 00005607e9ee31f0 R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: omitir eventos de netdev generados al eliminar netns syzbot informó lo siguiente (inofensivo) ADVERTENCIA: ADVERTENCIA: CPU: 1 PID: 2648 en net/netfilter/core.c:468 nft_netdev_unregister_hooks net/netfilter/nf_tables_api.c:230 [en línea] nf_tables_unregister_hook include/net/netfilter/nf_tables.h:1090 [en línea] __nft_release_basechain+0x138/0x640 net/netfilter/nf_tables_api.c:9524 nft_netdev_event net/netfilter/nft_ filtro_cadena.c: 351 [en línea] nf_tables_netdev_event+0x521/0x8a0 net/netfilter/nft_chain_filter.c:382 reproductor: dejar de compartir -n bash -c 'ip link agregar puente tipo br0; nft agregar tabla netdev t; \ nft add chain netdev t ingress \{ tipo filtro gancho ingreso dispositivo "br0" \ prioridad 0\; caída de la política\; \}' El problema es que cuando los ganchos de salida del dispositivo netns crean el evento UNREGISTER, el gancho .pre_exit para nf_tables core ya ha eliminado el gancho base. Notifier intenta hacer esto nuevamente. La necesidad de cancelar el registro del enlace base incondicionalmente era necesaria en el pasado, porque el notificador era la última etapa donde la desreferencia reg->dev era segura. Ahora que nf_tables elimina el gancho en .pre_exit, esto ya no es necesario.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ice: Evite fallas por IDA innecesario libre en la ruta de eliminación, hay un intento de liberar el IDA aux_idx, ya sea que esté asignado o no. Potencialmente, esto puede provocar un bloqueo al descargar el controlador en sistemas que no inicializan la compatibilidad con RDMA. Sin embargo, esta liberación no puede ser controlada por el bit de estado para RDMA, ya que se asigna si el controlador detecta soporte para RDMA en el momento de la prueba, pero el controlador puede entrar en un estado en el que RDMA no es compatible después de que se haya asignado el IDA en el momento de la prueba. tiempo y esto provocaría una pérdida de memoria. Inicialice aux_idx con un valor no válido y verifique si hay un valor válido al descargar para determinar si es necesaria una IDA libre.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/smp: no disminuye el recuento de prioridad de tareas inactivas en la CPU fuera de línea Con PREEMPT_COUNT=y, cuando una CPU está fuera de línea y luego vuelve a estar en línea, obtenemos: ERROR: programación mientras es atómica: swapper/1/0/0x00000000 no hay bloqueos retenidos por swapper/1/0. CPU: 1 PID: 0 Comunicaciones: swapper/1 No contaminado 5.15.0-rc2+ #100 Seguimiento de llamadas: dump_stack_lvl+0xac/0x108 __schedule_bug+0xac/0xe0 __schedule+0xcf8/0x10d0 Schedule_idle+0x3c/0x70 do_idle+0x2d8/0x4a0 entrada_arriba+ 0x38/0x40 start_secondary+0x2ec/0x3a0 start_secondary_prolog+0x10/0x14 Esto se debe a que arch_cpu_idle_dead() de powerpc disminuye el recuento de apropiación de tareas inactivas, por razones explicadas en el commit a7c2bb8279d2 ("powerpc: volver a habilitar la apropiación antes de cpu_die()"), específicamente " start_secondary() espera un preempt_count() de 0." Sin embargo, desde el commit 2c669ef6979c ("powerpc/preempt: no toque el preempt_count de la tarea inactiva durante la conexión en caliente") y el commit f1a0a376ca0c ("sched/core: inicialice la tarea inactiva con la preferencia deshabilitada"), esa justificación ya no se cumple. No se supone que la tarea inactiva vuelva a habilitar la preferencia, por lo tanto, elimine el preempt_enable() residual de la ruta fuera de línea de la CPU. Probado con pseries y powernv en qemu y pseries en PowerVM.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: pico_pci: pico_pci_remove(): arreglar UAF Cuando se elimina el módulo peek_pci, hacer referencia a 'chan' nuevamente después de liberar 'dev' causará UAF. Solucione este problema lanzando 'dev' más tarde. El siguiente registro lo revela: [35.961814] ERROR: KASAN: uso después de liberar en pico_pci_remove+0x16f/0x270 [peak_pci] [35.963414] Lectura de tamaño 8 en addr ffff888136998ee8 por tarea modprobe/5537 [35.965513] Seguimiento de llamadas: [3 5.965718 ] dump_stack_lvl+0xa8/0xd1 [35.966028] print_address_description+0x87/0x3b0 [35.966420] kasan_report+0x172/0x1c0 [35.966725]? pico_pci_remove+0x16f/0x270 [pico_pci] [35.967137]? trace_irq_enable_rcuidle+0x10/0x170 [35.967529]? pico_pci_remove+0x16f/0x270 [pico_pci] [ 35.967945 ] __asan_report_load8_noabort+0x14/0x20 [ 35.968346 ] pico_pci_remove+0x16f/0x270 [pico_pci] [ 35.968752 ] ve+0xa9/0x250

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: isotp: isotp_sendmsg(): agregar verificación de resultado para wait_event_interruptible() Usar wait_event_interruptible() para esperar la transmisión completa, pero no verificar el resultado de wait_event_interruptible() que puede ser interrumpido. Dará como resultado que el búfer TX tenga múltiples accesos y el proceso posterior interfiera con el proceso anterior. El siguiente es uno de los problemas informados por syzbot. ==================================================== =========== ADVERTENCIA: CPU: 0 PID: 0 en net/can/isotp.c:840 isotp_tx_timer_handler+0x2e0/0x4c0 CPU: 0 PID: 0 Comm: swapper/0 No contaminado 5.13.0 -rc7+ #68 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 01/04/2014 RIP: 0010:isotp_tx_timer_handler+0x2e0/0x4c0 Seguimiento de llamadas: ? isotp_setsockopt+0x390/0x390 __hrtimer_run_queues+0xb8/0x610 hrtimer_run_softirq+0x91/0xd0 ? rcu_read_lock_sched_held+0x4d/0x80 __do_softirq+0xe8/0x553 irq_exit_rcu+0xf8/0x100 sysvec_apic_timer_interrupt+0x9e/0xc0 asm_sysvec_apic_timer_interrupt+0x12/0x20 Agregar verificación de resultado para wait_event_ interrumpible() en isotp_sendmsg() para evitar múltiples accesos al búfer tx.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: el montaje falla con desbordamiento del búfer en strlen. A partir del kernel 5.11 compilado con CONFIG_FORTIFY_SOURCE, la conexión de un sistema de archivos ocfs2 con una pila de clúster o2cb o pcmk falla con el siguiente seguimiento. El problema parece ser que no se garantiza que las cadenas para la pila del clúster y el nombre del clúster tengan terminación nula en la representación del disco, mientras que strlcpy supone que la cadena de origen siempre termina en nulo. Esto provoca una lectura fuera de la cadena de origen que activa la detección de desbordamiento del búfer. se detectó desbordamiento del búfer en strlen ------------[ cortar aquí ]------------ ¡ERROR del kernel en lib/string.c:1149! código de operación no válido: 0000 [#1] SMP PTI CPU: 1 PID: 910 Comm: mount.ocfs2 No contaminado 5.14.0-1-amd64 #1 Debian 5.14.6-2 RIP: 0010:fortify_panic+0xf/0x11... Seguimiento de llamadas: ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2] ocfs2_fill_super+0x359/0x19b0 [ocfs2] mount_bdev+0x185/0x1b0 Legacy_get_tree+0x27/0x40 vfs_get_tree+0x25/0xb0 xa20 __x64_sys_mount+0x103/0x140 do_syscall_64+0x3b/0xc0 entrada_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: j1939: j1939_netdev_start(): arreglar UAF para rx_kref de j1939_priv Activará UAF para rx_kref de j1939_priv de la siguiente manera. cpu0 cpu1 j1939_sk_bind(socket0, ndev0, ...) j1939_netdev_start j1939_sk_bind(socket1, ndev0, ...) j1939_netdev_start j1939_priv_set j1939_priv_get_by_ndev_locked j1939_jsk_add ..... kref_put_lock(&priv->rx_kref, ...) kref_get(&priv->rx_kref , ...) REFCOUNT_WARN("adición en 0;...") ================================== ==================== refcount_t: suma en 0; use-after-free. ADVERTENCIA: CPU: 1 PID: 20874 en lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0 RIP: 0010:refcount_warn_saturate+0x169/0x1e0 Seguimiento de llamadas: j1939_netdev_start+0x68b/0x920 j1939_sk_bind+0x426 /0xeb0 ? security_socket_bind+0x83/0xb0 Los kref_get() y kref_put() de rx_kref deben usar j1939_netdev_lock para proteger.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige la corrupción de datos después de la conversión desde el formato en línea. el commit 6dbf7bb55598 ("fs: No invalide los buffers de página en block_write_full_page()") descubrió un error latente en la conversión de ocfs2 desde el inodo en línea. formato a un formato de inodo normal. El código en ocfs2_convert_inline_data_to_extents() intenta poner a cero todo el clúster asignado para datos de archivos capturando, poniendo a cero y ensuciando todas las páginas que cubren este clúster. Sin embargo, estas páginas están más allá de i_size, por lo que el código de reescritura generalmente ignora estas páginas sucias y nunca se puso a cero ningún bloque en el disco. Este descuido se solucionó mediante el commit 693c241a5f6a ("ocfs2: No es necesario poner a cero las páginas después de i_size.") para la ruta de escritura estándar de ocfs2, la ruta de conversión en línea aparentemente se olvidó; el registro de confirmación también tiene un razonamiento por el cual la puesta a cero en realidad no es necesaria. Después de el commit 6dbf7bb55598, las cosas empeoraron ya que el código de reescritura dejó de invalidar los buffers en páginas más allá de i_size y, por lo tanto, estas páginas terminan con un bit PageDirty limpio pero con los búferes adjuntos a estas páginas todavía sucios. Entonces, cuando un archivo se convierte desde un formato en línea, se activa la reescritura y luego el archivo crece para que estas páginas se vuelvan válidas, se conserva el estado de suciedad no válido, mark_buffer_dirty() no hace nada en estas páginas (los búferes ya están sucios), excepto la página nunca se vuelve a escribir porque está limpio. Por lo tanto, los datos escritos en estas páginas se pierden una vez que se recuperan las páginas. El reproductor simple para el problema es: xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \ -c "pwrite 4000 2000" ocfs2_file Después de desmontar y montar el fs nuevamente, puede observar que El final de 'ocfs2_file' ha perdido su contenido. Solucione el problema al no realizar la puesta a cero inútil durante la conversión desde el formato en línea de manera similar a como lo hace en la ruta de escritura estándar. [akpm@linux-foundation.org: arreglar espacios en blanco, según Joseph]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ptp: solucione una posible pérdida de memoria en ptp_clock_register() Obtuve una pérdida de memoria de la siguiente manera al realizar la prueba de inyección de fallas: objeto sin referencia 0xffff88800906c618 (tamaño 8): comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (edad 13,188 s) volcado hexadecimal (primeros 8 bytes): 70 74 70 30 00 00 00 00 ptp0.... backtrace: [<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0 [<0000 000079f6e2ff>] kvasprintf+0xb5 /0x150 [<0000000026aae54f>] kvasprintf_const+0x60/0x190 [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150 [<000000004e35abdd>] dev_set_name+0xc0/0x100 0000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp] [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33] Cuando posix_clock_register() devuelve un error, el nombre asignado en dev_set_name() se filtrará, se debe usar put_device() para renunciar a la referencia del dispositivo, luego el nombre se liberará kobject_cleanup() y otra memoria se liberarán en ptp_clock_release().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: corrige la pérdida de memoria en la ruta de error mlx5_core_destroy_cq(). Antes de este parche, en caso de que mlx5_core_destroy_cq() fallara, regresa sin completar todas las operaciones de destrucción y eso conduce a una pérdida de memoria. En su lugar, complete el flujo de destrucción antes de que se produzca el error de devolución. También mueva mlx5_debug_cq_remove() al principio de mlx5_core_destroy_cq() para que sea simétrico con mlx5_core_create_cq(). kmemleak se queja de: objeto sin referencia 0xc000000038625100 (tamaño 64): comm "ethtool", pid 28301, jiffies 4298062946 (edad 785.380 s) volcado hexadecimal (primeros 32 bytes): 60 01 48 94 00 00 00 c0 b8 05 34 3 00 00 00 c0 `.H.......4..... 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}..... rastreo hacia atrás : [<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core] [<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core] [<000000002a12918f>] 0x1d0/0x2d0 [mlx5_core] [<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core] [<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core] [<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core] [<0000000081839561>] 5e_open_channels+0x9cc/0x13e0 [mlx5_core] [<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4 /0x230 [mlx5_core] [<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300 [mlx5_core] [<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core [<00000000a] 0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core] [<00000000a8f3d84b>] etnl_set_privflags +0x234/0x2d0 [<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0 [<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0 [<00000000646c5c2c>] v_msg+0x78/0x120 [<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0