Vulnerabilidades

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().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFC: digital: corrige una posible pérdida de memoria en digital_tg_listen_mdaa() Los 'params' se asignan en digital_tg_listen_mdaa(), pero no están libres cuando falla digital_send_cmd(), lo que provocará una pérdida de memoria. Solucionelo liberando 'params' si falla la devolución de digital_send_cmd().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/edid: En conector_bad_edid() cap num_of_ext por num_blocks leído En commit e11f5bd8228f ("drm: Agregar soporte para prueba de corrupción edid de cumplimiento de DP 1.4") la función conector_bad_edid() comenzó a asumir que la memoria para el EDID que se le pasó era lo suficientemente grande como para contener bloques de datos `edid[0x7e] + 1` (1 adicional para el bloque base). Ignoró por completo el hecho de que a la función se le pasó `num_blocks`, que indicaba cuánta memoria se había asignado para el EDID. Arreglemos esto agregando una verificación de los límites. Esto es importante para manejar el caso en el que hay un error en el primer bloque del EDID. En ese caso llamaremos a Connector_bad_edid() sin haber reasignado memoria en base a `edid[0x7e]`.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/msm: corrige la desreferencia del puntero nulo en el puntero edp. La inicialización del puntero dev desreferencias del puntero edp antes de edp se marca como nula, por lo que existe un posible problema de deferencia del puntero nulo. Solucione este problema eliminando la referencia a edp únicamente después de que se haya marcado como nulo. Direcciones-Cobertura: ("Desreferencia antes de verificación nula")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/msm/a4xx: corrige el manejo de errores en a4xx_gpu_init() Este código devuelve 1 en caso de error en lugar de un error negativo. Conduce a un Ups en la persona que llama. Un segundo problema es que la verificación de "if (ret! = -ENODATA)" no puede ser verdadera porque "ret" está establecido en 1.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/msm/a3xx: corrige el manejo de errores en a3xx_gpu_init() Estas rutas de error devolvieron 1 en caso de falla, en lugar de un código de error negativo. Esto provocaría un Ups en la persona que llama. Un segundo problema es que la verificación de "if (ret! = -ENODATA)" no funcionó porque "ret" estaba establecido en 1.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrige posible bloqueo en recvmsg() recvmsg() puede entrar en un bucle infinito si la persona que llama proporciona MSG_WAITALL, los datos presentes en la cola de recepción no son suficientes para cumplir con la solicitud y el par no recibe más datos. Cuando sucede lo anterior, mptcp_wait_data() siempre regresará sin espera, ya que el indicador MPTCP_DATA_READY verificado por dicha función se establece y nunca se borra en dicha ruta de código. Aprovechar el syzbot anterior fue capaz de desencadenar una parada de RCU: rcu: INFO: rcu_preempt parada autodetectada en la CPU rcu: 0-...!: (10499 marca este GP) idle=0af/1/0x4000000000000000 softirq=10678/10678 fqs=1 (t=10500 jiffies g=13089 q=109) rcu: rcu_preempt ¡kthread se quedó sin 10497 jiffies! g13089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1 rcu: A menos que rcu_preempt kthread obtenga suficiente tiempo de CPU, ahora se espera que OOM sea el comportamiento. rcu: Volcado de pila de kthread del período de gracia de RCU: tarea: rcu_preempt estado: R pila de tareas en ejecución: 28696 pid: 14 ppid: 2 banderas: 0x00004000 Seguimiento de llamadas: context_switch kernel/sched/core.c:4955 [en línea] __schedule+0x940/ 0x26f0 kernel/sched/core.c:6236 Schedule+0xd3/0x270 kernel/sched/core.c:6315 Schedule_timeout+0x14a/0x2a0 kernel/time/timer.c:1881 rcu_gp_fqs_loop+0x186/0x810 kernel/rcu/tree.c :1955 rcu_gp_kthread+0x1de/0x320 kernel/rcu/tree.c:2128 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 rcu: Volcado de pila donde RCU Última ejecución de GP kthread: Envío de NMI desde la CPU 0 a las CPU 1: seguimiento de NMI para la CPU 1 CPU: 1 PID: 8510 Comm: syz-executor827 No contaminado 5.15.0-rc2-next-20210920-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:84 [en línea] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:102 [en línea] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:128 [en línea] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:159 [en línea] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [en línea] RIP : 0010:kasan_check_range+0xc8/0x180 mm/kasan/generic.c:189 Código: 38 00 74 ed 48 8d 50 08 eb 09 48 83 c0 01 48 39 d0 74 7a 80 38 00 74 f2 48 89 c2 b8 01 00 00 00 48 85 d2 75 56 5b 5d 41 5c c3 <48> 85 d2 74 5e 48 01 ea eb 09 48 83 c0 01 48 39 d0 74 50 80 38 00 RSP: 0018:ffffc9000cd676c8 EFLAGS: 000283 RAX: ffffed100e9a110e RBX: ffffed100e9a110f RCX : ffffffff88ea062a RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888074d08870 RBP: ffffed100e9a110e R08: 0000000000000001 R09: d08877 R10: ffffed100e9a110e R11: 0000000000000000 R12: ffff888074d08000 R13: ffff888074d08000 R14: ffff888074d08088 R15: ffff888074d08000 0000555556d8e300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 S: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000068909000 CR4: 00000000001506e0 0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: instrument_atomic_ lectura_escritura incluye/linux/ instrumented.h:101 [en línea] test_and_clear_bit include/asm-generic/bitops/instrumented-atomic.h:83 [en línea] mptcp_release_cb+0x14a/0x210 net/mptcp/protocol.c:3016 release_sock+0xb4/0x1b0 net/core/ sock.c:3204 mptcp_wait_data net/mptcp/protocol.c:1770 [en línea] mptcp_recvmsg+0xfd1/0x27b0 net/mptcp/protocol.c:2080 inet6_recvmsg+0x11b/0x5e0 net/ipv6/af_inet6.c:659 vmsg_nosec red/socket .c:944 [en línea] ____sys_recvmsg+0x527/0x600 net/socket.c:2626 ___sys_recvmsg+0x127/0x200 net/socket.c:2670 do_recvmmsg+0x24d/0x6d0 net/socket.c:2764 net/socket.c: 2843 [en línea] __do_sys_recvmmsg net/socket.c:2866 [en línea] __se_sys_recvmmsg net/socket.c:2859 [en línea] ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: corrige la lógica de aborto en btrfs_replace_file_extents Las pruebas de inyección de errores descubrieron un caso en el que terminaríamos con un sistema de archivos corrupto al que le faltaba una extensión en medio de un archivo. Esto ocurre porque la declaración if para decidir si debemos abortar es incorrecta. La única manera de abortar en este caso es si obtenemos un ret! = -EOPNOTSUPP y llamamos desde el código de clonación del archivo. Sin embargo, el código de preasignación también utiliza esta ruta. En lugar de eso, debemos abortar si hay un error, y el único error por el que _no_ abortamos es -EOPNOTSUPP y solo si venimos del código del archivo clonado.