Vulnerabilidades

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

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: dsa: microchip: se agregó la condición para programar ksz_mib_read_work Cuando el módulo ksz se instala y elimina usando rmmod, el kernel falla con un error de desreferencia de puntero nulo. Durante rmmod, la función ksz_switch_remove intenta cancelar mib_read_workqueue usando la rutina cancel_delayed_work_sync y cancelar el registro del conmutador de dsa. Durante dsa_unregister_switch llama a ksz_mac_link_down, que a su vez reprograma la cola de trabajo ya que mib_interval no es cero. Debido a qué cola se ejecutó después de mib_interval e intenta acceder a dp->slave. Pero el esclavo no está registrado en la función ksz_switch_remove. Por lo tanto, el kernel falla. Para evitar este bloqueo, antes de cancelar la cola de trabajo, restableció mib_interval a 0. v1 -> v2: -Se eliminó la condición if en ksz_mib_read_work

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: encx24j600: error de verificación en devm_regmap_init_encx24j600 devm_regmap_init puede devolver un error causado por falta de memoria, esto resultará en una desreferencia del puntero nulo más adelante al leer o escribir el registro: falla de protección general en encx24j600_spi_probe KASAN: null-ptr-deref en el rango [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 286 Comm: spi-encx24j600- No contaminado 5.15.0-rc2-00142-g9978db7 50e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652 Nombre del hardware: PC estándar QEMU ( i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 01/04/2014 RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540 Código: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00 RSP: 0018:ffffc900010476b8 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 00000000000000000 RDX: 0000000000000012 RSI: 888002de0000 RDI: 0000000000000094 RBP: ffff888013c9a000 R08: 0000000000000000 R09: ffffbfff3f9cc6a R10: ffffc900010476e8 R11: ffffbfff3f9cc69 : 0000000000000001 R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08 FS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000 CS: 010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 00000 00000000000DR2 : 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459 spi_probe drivers/spi/spi.c:397 Actually_probe drivers/base/dd.c:517 __driver_probe_device drivers/base/dd.c:751 driver_probe_device drivers/ base/dd.c:782 __device_attach_driver drivers/base/dd.c:899 bus_for_each_drv drivers/base/bus.c:427 __device_attach drivers/base/dd.c:971 bus_probe_device drivers/base/bus.c:487 device_add drivers/ base/core.c:3364 __spi_add_device drivers/spi/spi.c:599 spi_add_device drivers/spi/spi.c:641 spi_new_device drivers/spi/spi.c:717 new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d0 0630982840568e85e] controladores/base dev_attr_store /core.c:2074 sysfs_kf_write fs/sysfs/file.c:139 kernfs_fop_write_iter fs/kernfs/file.c:300 new_sync_write fs/read_write.c:508 (discriminador 4) vfs_write fs/read_write.c:594 ksys_write fs/read_write .c:648 do_syscall_64 arch/x86/entry/common.c:50 Entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113 Agregue verificación de errores en devm_regmap_init_encx24j600 para evitar esta situación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: Thermal: corrige accesos a memoria fuera de los límites Actualmente, mlxsw permite establecer estados de enfriamiento por encima del estado de enfriamiento máximo admitido por el controlador: # cat /sys/class/ Thermal/thermal_zone2/cdev0/type mlxsw_fan # cat /sys/class/thermal/thermal_zone2/cdev0/max_state 10 # echo 18 > /sys/class/thermal/thermal_zone2/cdev0/cur_state # echo $? 0 Esto da como resultado accesos a la memoria fuera de los límites cuando las estadísticas de transición de estado térmico están habilitadas (CONFIG_THERMAL_STATISTICS=y), ya que se accede a la tabla de transición con un índice (estado) demasiado grande [1]. Según el mantenedor térmico, es responsabilidad del conductor rechazar este tipo de operaciones [2]. Por lo tanto, devolverá un error cuando el estado que se establecerá exceda el estado de enfriamiento máximo admitido por el controlador. Para evitar el código inactivo, como lo sugiere el mantenedor térmico [3], revierta parcialmente el commit a421ce088ac8 ("mlxsw: core: Extend Cooling Device with Cooling Levels") que intentó interpretar estos estados de enfriamiento no válidos (por encima del máximo) de una manera especial. . La matriz de niveles de enfriamiento no se elimina para evitar que los ventiladores bajen del 20 % de PWM, lo que provocaría que se atasquen en el 0 % de PWM. [1] ERROR: KASAN: losa fuera de los límites en Thermal_cooling_device_stats_update+0x271/0x290 Lectura de tamaño 4 en la dirección ffff8881052f7bf8 por tarea kworker/0:0/5 CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122 Nombre del hardware: Mellanox Technologies Ltd. "MSN2410-CB2FO"/"SA000874", BIOS 4.6.5 08/03/2016 Cola de trabajo: events_freezable_power_ Thermal_zone_device_check Seguimiento de llamadas: dump_stack_lvl+0x8b /0xb3 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b Thermal_cooling_device_stats_update+0x271/0x290 __thermal_cdev_update+0x15e/0x4e0 Thermal_cdev_update+0x9f/0xe0 70/0xee0 actualización_dispositivo_zona_termal+0x3f6/0xdf0 proceso_one_work+0xa42/0x1770 hilo_trabajador+ 0x62f/0x13e0 kthread+0x3ee/0x4e0 ret_from_fork+0x1f/0x30 Asignado por tarea 1: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 Thermal_cooling_device_setup_sysfs+0x153/0x2c0 _device_register.part.0+0x25b/0x9c0 Thermal_cooling_device_register+0xb3/0x100 mlxsw_thermal_init+0x5c5 /0x7e0 __mlxsw_core_bus_device_register+0xcb3/0x19c0 mlxsw_core_bus_device_register+0x56/0xb0 mlxsw_pci_probe+0x54f/0x710 local_pci_probe+0xc6/0x170 pci_device_probe+0x2b2/0x4d0 very_probe+ 0x293/0xd10 __driver_probe_device+0x2af/0x440 driver_probe_device+0x51/0x1e0 __driver_attach+0x21b/0x530 bus_for_each_dev+0x14c /0x1d0 bus_add_driver+0x3ac/0x650 driver_register+0x241/0x3d0 mlxsw_sp_module_init+0xa2/0x174 do_one_initcall+0xee/0x5f0 kernel_init_freeable+0x45a/0x4de kernel_init+0x1f/0x210 f/0x30 La dirección con errores pertenece al objeto en ffff8881052f7800 que pertenece al caché kmalloc-1k de tamaño 1024 La dirección con errores se encuentra 1016 bytes dentro de la región de 1024 bytes [ffff8881052f7800, ffff8881052f7c00) La dirección con errores pertenece a la página: página:0000000052355272 refcount:1 mapcount:0 mapeo:0000000000000000 índice :0x0 pfn: 0x1052f0 cabeza:0000000052355272 orden:3 compuesto_mapcount:0 compuesto_pincount:0 banderas: 0x200000000010200(slab|head|node=0|zone=2) raw: 0200000000010200 ffffea0005034800 00000003000 00003 ffff888100041dc0 raw: 0000000000000000 0000000000100010 00000001ffffffff 00000000000000000 página volcada porque: kasan: se detectó mal acceso Estado de la memoria alrededor de la dirección del error: ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc >ffff8881052f7 b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFC: digital: corrige una posible pérdida de memoria en digital_in_send_sdd_req() 'skb' está asignado en digital_in_send_sdd_req(), pero no está libre cuando falla digital_in_send_cmd(), lo que provocará una pérdida de memoria. Solucionarlo liberando 'skb' si falla la devolución de digital_in_send_cmd().