Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: OMAP2+: pdata-quirks: Corregir error de pérdida de recuento de referencias En pdata_quirks_init_clocks(), el bucle contiene of_find_node_by_name() pero sin el of_node_put() correspondiente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: OMAP2+: display: Se corrige el error de fuga de refcount. En omapdss_init_fbdev(), of_find_node_by_name() devolverá un puntero de nodo con refcount incrementado. Deberíamos usar of_node_put() cuando ya no se use.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md-raid10: corrección de la advertencia de KASAN. Hay una advertencia de KASAN en raid10_remove_disk al ejecutar la prueba lvm lvconvert-raid-reshape.sh. Para corregir esta advertencia, verificamos que el valor "number" sea válido. ERROR: KASAN: slab fuera de los límites en raid10_remove_disk+0x61/0x2a0 [raid10] Lectura de tamaño 8 en la dirección ffff889108f3d300 por la tarea mdX_raid10/124682 CPU: 3 PID: 124682 Comm: mdX_raid10 No contaminado 5.19.0-rc6 #1 Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x34/0x44 print_report.cold+0x45/0x57a ? __lock_text_start+0x18/0x18 ? raid10_remove_disk+0x61/0x2a0 [raid10] kasan_report+0xa8/0xe0 ? raid10_remove_disk+0x61/0x2a0 [raid10] raid10_remove_disk+0x61/0x2a0 [raid10] Buffer I/O error on dev dm-76, logical block 15344, async page read ? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0 remove_and_add_spares+0x367/0x8a0 [md_mod] ? super_written+0x1c0/0x1c0 [md_mod] ? mutex_trylock+0xac/0x120 ? _raw_spin_lock+0x72/0xc0 ? _raw_spin_lock_bh+0xc0/0xc0 md_check_recovery+0x848/0x960 [md_mod] raid10d+0xcf/0x3360 [raid10] ? sched_clock_cpu+0x185/0x1a0 ? rb_erase+0x4d4/0x620 ? var_wake_function+0xe0/0xe0 ? psi_group_change+0x411/0x500 ? preempt_count_sub+0xf/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? raid10_sync_request+0x36c0/0x36c0 [raid10] ? preempt_count_sub+0xf/0xc0 ? _raw_spin_unlock_irqrestore+0x19/0x40 ? del_timer_sync+0xa9/0x100 ? try_to_del_timer_sync+0xc0/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? _raw_spin_unlock_irq+0x11/0x24 ? __list_del_entry_valid+0x68/0xa0 ? finish_wait+0xa3/0x100 md_thread+0x161/0x260 [md_mod] ? unregister_md_personality+0xa0/0xa0 [md_mod] ? _raw_spin_lock_irqsave+0x78/0xc0 ? prepare_to_wait_event+0x2c0/0x2c0 ? unregister_md_personality+0xa0/0xa0 [md_mod] kthread+0x148/0x180 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Allocated by task 124495: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x80/0xa0 setup_conf+0x140/0x5c0 [raid10] raid10_run+0x4cd/0x740 [raid10] md_run+0x6f9/0x1300 [md_mod] raid_ctr+0x2531/0x4ac0 [dm_raid] dm_table_add_target+0x2b0/0x620 [dm_mod] table_load+0x1c8/0x400 [dm_mod] ctl_ioctl+0x29e/0x560 [dm_mod] dm_compat_ctl_ioctl+0x7/0x20 [dm_mod] __do_compat_sys_ioctl+0xfa/0x160 do_syscall_64+0x90/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0xc0 kvfree_call_rcu+0x84/0x480 timerfd_release+0x82/0x140 L __fput+0xfa/0x400 task_work_run+0x80/0xc0 exit_to_user_mode_prepare+0x155/0x160 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x42/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Second to last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0xc0 kvfree_call_rcu+0x84/0x480 timerfd_release+0x82/0x140 __fput+0xfa/0x400 task_work_run+0x80/0xc0 exit_to_user_mode_prepare+0x155/0x160 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x42/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The buggy address belongs to the object at ffff889108f3d200 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte region [ffff889108f3d200, ffff889108f3d300) The buggy address belongs to the physical page: page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c head:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0 flags: 0x4000000000010200(slab|head|zone=2) raw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40 raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff889108f3d280: 00 00 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: MIPS: cpuinfo: Se corrige una advertencia para CONFIG_CPUMASK_OFFSTACK. Al seleccionar CONFIG_CPUMASK_OFFSTACK y CONFIG_DEBUG_PER_CPU_MAPS, cpu_max_bits_warn() genera una advertencia de tiempo de ejecución similar a la que se muestra a continuación mientras se muestra /proc/cpuinfo. Se corrige usando nr_cpu_ids (el límite de tiempo de ejecución) en lugar de NR_CPUS para iterar las CPU. [ 3.052463] ------------[ cortar aquí ]------------ [ 3.059679] ADVERTENCIA: CPU: 3 PID: 1 en include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Módulos vinculados: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd No contaminado 5.19-rc5+ #1052 [ 3.084034] Nombre del hardware: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [3.099465] Pila: 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [3.118774] 90000001001578e8 000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 000000000000000 0000000000000000 000000000000000 00000000000000 00000000000aaaaaa [ 3.147711] ffff8000339dc220 000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Rastreo de llamadas: [ 3.203941] [<98000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9800000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<980000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9800000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9800000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<98000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<98000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<98000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<98000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9800000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9800000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ fin de seguimiento 8b484262b4b8c24c ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: meson-mx-socinfo: Se corrige la fuga de recuento de referencias en meson_mx_socinfo_init. of_find_matching_node() devuelve un puntero de nodo con el recuento de referencias incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: amlogic: Se corrige una pérdida de recuento de referencias en meson-secure-pwrc.c En meson_secure_pwrc_probe(), hay una pérdida de recuento de referencias en una ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM: hibernar: aplazar el sondeo del dispositivo al reanudar desde la hibernación syzbot informa una tarea colgada en misc_open() [1], ya que hay una ventana de ejecución de punto muerto AB-BA que involucra a la variable probe_count. Actualmente, wait_for_device_probe() de snapshot_open() de misc_open() puede dormir para siempre con misc_mtx retenido si probe_count no puede llegar a 0. Cuando un dispositivo es sondeado por la función de trabajo hub_event(), probe_count se incrementa antes de que comience la función de sondeo y probe_count se decrementa después de que la función de sondeo se complete. Hay tres casos que pueden evitar que probe_count caiga a 0. (a) Un dispositivo que se está sondeando dejó de responder (es decir, hardware roto/malicioso). (b) Un proceso que emula un dispositivo USB usando la interfaz /dev/raw-gadget dejó de responder por alguna razón. (c) Siguen llegando nuevas solicitudes de sondeo de dispositivo antes de que se completen las solicitudes de sondeo de dispositivo existentes. El fenómeno que syzbot reporta es (b). Un proceso que contiene system_transition_mutex y misc_mtx espera a que probe_count sea 0 dentro de wait_for_device_probe(), pero la función de sonda, llamada desde la función de trabajo hub_event(), espera a que los procesos bloqueados en mutex_lock(&misc_mtx) respondan mediante la interfaz /dev/raw-gadget. Este parche mitiga (b) al posponer wait_for_device_probe() de snapshot_open() a snapshot_write() y snapshot_ioctl(). Tenga en cuenta que la posibilidad de (b) persiste mientras cualquier hilo que emule un dispositivo USB mediante la interfaz /dev/raw-gadget pueda ser bloqueado por operaciones de bloqueo ininterrumpido (p. ej., mutex_lock()). Tenga en cuenta también que (a) y (c) no se abordan. Respecto a (c), debemos modificar el código para que espere solo a un dispositivo que contenga la imagen para reanudar la hibernación. No sé cómo abordar (a), ya que el uso del tiempo de espera para wait_for_device_probe() podría provocar la pérdida de datos de usuario en la imagen. Quizás deberíamos exigir que el espacio de usuario espere al dispositivo de imagen antes de abrir la interfaz /dev/snapshot.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: selinux: corrige memleak en security_read_state_kernel() En esta función, devuelve directamente el resultado de __security_read_policy sin liberar la memoria asignada en *data, lo que causa un problema de pérdida de memoria, por lo que libera la memoria si __security_read_policy falla. [PM: ajuste de la línea de asunto]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: selinux: Agregar verificación de los límites en put_entry() Al igual que next_entry(), la verificación de los límites es necesaria para evitar el acceso fuera de los límites de la memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: OMAP2+: Se corrige la fuga de recuento de referencias en omapdss_init_of. Omapdss_find_dss_of_node() llama a of_find_compatible_node() para obtener el nodo del dispositivo. of_find_compatible_node() devuelve un puntero de nodo con el recuento de referencias incrementado; al finalizar, se debe usar of_node_put(). Se añade la falta de of_node_put() en la ruta de error posterior y en la ruta normal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: OMAP2+: Se corrige la fuga de recuento de referencias en omap3xxx_prm_late_init. of_find_matching_node() devuelve un puntero de nodo con el recuento de referencias incrementado. Debemos usar of_node_put() cuando ya no sea necesario. Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpufreq: zynq: Se corrige la fuga de recuento de referencias en zynq_get_revision. of_find_compatible_node() devuelve un puntero de nodo con el recuento de referencias incrementado; al finalizar, se debe usar of_node_put(). Se ha añadido la función of_node_put() que falta para evitar la fuga de recuento de referencias.