Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: pdr: protege locator_addr con el mutex principal Si el servidor del localizador de servicios se reinicia lo suficientemente rápido, el PDR puede reescribir los campos locator_addr simultáneamente. Protéjalos colocando la modificación de esos campos bajo el pdr->lock principal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: xilinx: cambiar el nombre de cpu_number1 a dummy_cpu_number La variable por CPU cpu_number1 se pasa a xlnx_event_handler como argumento "dev_id", pero no se utiliza en esta función. Así que elimine la inicialización de esta variable y cámbiele el nombre a dummy_cpu_number. Este parche es para corregir el siguiente seguimiento de llamadas cuando la opción del kernel CONFIG_DEBUG_ATOMIC_SLEEP está habilitada: ERROR: función de suspensión llamada desde un contexto no válido en include/linux/sched/mm.h:274 in_atomic(): 1, irqs_disabled(): 0, non_block : 0, pid: 1, nombre: swapper/0 preempt_count: 1, esperado: 0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0 #53 Nombre de hardware: Xilinx Versal vmk180 Placa de evaluación rev1.1 (QSPI ) (DT) Seguimiento de llamadas: dump_backtrace+0xd0/0xe0 show_stack+0x18/0x40 dump_stack_lvl+0x7c/0xa0 dump_stack+0x18/0x34 __might_resched+0x10c/0x140 __might_sleep+0x4c/0xa0 __kmem_cache_alloc_node+0xf4/ 0x168 kmalloc_trace+0x28/0x38 __request_percpu_irq+0x74 /0x138 xlnx_event_manager_probe+0xf8/0x298 plataforma_probe+0x68/0xd8

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cgroup/cpuset: Prevenir UAF en proc_cpuset_show() Puede ocurrir un UAF cuando se lee /proc/cpuset como se informa en [1]. Esto se puede reproducir mediante los siguientes métodos: 1.Agregue un mdelay(1000) antes de adquirir cgroup_lock en la función cgroup_path_ns. 2.$cat /proc//cpuset repetidamente. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repetidamente. La ejecución que causa este error se puede mostrar a continuación: (umount) | (cat /proc//cpuset) css_release | proc_cpuset_show css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id); css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...); cgroup_destroy_root | mutex_lock(&cgroup_mutex); rebind_subsistemas | cgroup_free_root | | // cgrp fue liberado, UAF | cgroup_path_ns_locked(cgrp,..); Cuando se inicializa cpuset, el nodo raíz top_cpuset.css.cgrp apuntará a &cgrp_dfl_root.cgrp. En cgroup v1, la operación de montaje asignará cgroup_root y top_cpuset.css.cgrp apuntará al &cgroup_root.cgrp asignado. Cuando se ejecuta la operación desmontaje, top_cpuset.css.cgrp se rebotará en &cgrp_dfl_root.cgrp. El problema es que al volver a vincular a cgrp_dfl_root, hay casos en los que el cgroup_root asignado al configurar la raíz para cgroup v1 se almacena en caché. Esto podría dar lugar a un use-after-free (UAF) si se libera posteriormente. Los cgroups descendientes de cgroup v1 solo se pueden liberar después de que se publique el CSS. Sin embargo, el CSS de la raíz nunca se liberará, pero cgroup_root debe liberarse cuando se desmonta. Esto significa que obtener una referencia al CSS de la raíz no garantiza que css.cgrp->root no se libere. Solucione este problema usando rcu_read_lock en proc_cpuset_show(). Como cgroup_root es kfree_rcu después del commit d23b5c577715 ("cgroup: hacer que las operaciones en la RCU cgroup root_list sean seguras"), css->cgroup no se liberará durante la sección crítica. Para llamar a cgroup_path_ns_locked, se necesita css_set_lock, por lo que es seguro reemplazar task_get_css con task_css. [1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: inicializa el búfer de integridad a cero antes de escribirlo en el medio. Los metadatos agregados por bio_integrity_prep utilizan kmalloc simple, lo que lleva a que la memoria del kernel se escriba en el medio de forma aleatoria. Para los metadatos de PI, esto se limita a la etiqueta de la aplicación que no es utilizada por los metadatos generados por el kernel, pero para los metadatos que no son de PI, todo el búfer pierde memoria del kernel. Solucione este problema agregando el indicador __GFP_ZERO a las asignaciones para escrituras.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md: corrige el punto muerto entre mddev_suspend y purgar bio. El punto muerto ocurre cuando mddev se suspende mientras se realiza algún purga de biografía. Es una cuestión compleja. T1. la primera descarga está en la etapa final, borra 'mddev->flush_bio' e intenta enviar datos, pero se bloquea porque T4 suspende mddev. T2. la segunda descarga establece 'mddev->flush_bio' e intenta poner en cola md_submit_flush_data(), que ya se está ejecutando (T1) y no se ejecutará nuevamente si está en la misma CPU que T1. T3. el tercer enjuague incluye active_io e intenta descargar, pero se bloquea porque 'mddev->flush_bio' no es NULL (establecido por T2). T4. Se llama a mddev_suspend() y espera que active_io dec a 0, que es incrementado por T3. T1 T2 T3 T4 (flush 1) (flush 2) (tercero 3) (suspender) md_submit_flush_data mddev->flush_bio = NULL; . . md_flush_request. mddev->flush_bio = biografía. cola submit_flushes . . . . md_handle_request. . activo_io + 1. . md_flush_request. . ¡espera! mddev->flush_bio. . . . mddev_suspend. . ¡espera! active_io. . . enviar_flushes. queue_work md_submit_flush_data. //md_submit_flush_data ya se está ejecutando (T1). md_handle_request espera reanudar la raíz del problema es el aumento/disminución no atómico de active_io durante el proceso de descarga. active_io disminuye antes de que md_submit_flush_data se ponga en cola y se inc poco después de ejecutar md_submit_flush_data(). md_flush_request active_io + 1 submit_flushes active_io - 1 md_submit_flush_data md_handle_request active_io + 1 make_request active_io - 1 Si active_io se dec después de md_handle_request() en lugar de dentro de submit_flushes(), se puede llamar a make_request() directamente en lugar de md_handle_request() en md_submit_flush_data(), y active_io solo aumentará y disminuirá una vez durante todo el proceso de descarga. Se solucionará el punto muerto. Además, la única diferencia entre solucionar el problema y antes es que no hay manejo de errores de devolución de make_request(). Pero después de que el parche anterior limpió md_write_start(), make_requst() solo devuelve un error en raid5_make_request() por dm-raid, consulte el commit 41425f96d7aa ("dm-raid456, md/raid456: solucione un punto muerto para dm-raid456 mientras io concurre con reshape) ". Dado que dm siempre divide los datos y la operación de descarga en dos io separados, el tamaño de io de descarga enviado por dm siempre es 0, no se llamará a make_request() en md_submit_flush_data(). Para evitar que modificaciones futuras introduzcan problemas, agregue WARN_ON para garantizar que make_request() no se devuelva ningún error en este contexto.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dma: corrige el orden de llamadas en dmam_free_coherent dmam_free_coherent() libera una asignación de DMA, lo que hace que el vaddr liberado esté disponible para su reutilización, luego llama a devres_destroy() para eliminar y liberar la estructura de datos utilizada para realizar un seguimiento de la asignación de DMA. Entre las dos llamadas, es posible que una tarea simultánea realice una asignación con el mismo vaddr y lo agregue a la lista de devres. Si esto sucede, habrá dos entradas en la lista devres con el mismo vaddr y devres_destroy() puede liberar la entrada incorrecta, activando WARN_ON() en dmam_match. Para solucionarlo, destruya la entrada devres antes de liberar la asignación de DMA. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: jfs: Reparar array-index-out-of-bounds en diFree

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: F2FS: Correcto para truncar los bloques preallocados en F2FS_FILE_OPEN () Chenyuwen informa un error F2FS a continuación: Ineable para manejar el kernel nulo dreference en la dirección virtual 000000000011 FSCRYPT_SET_BIO_CRYPT_ POTER_ GACT/0X1 ab_read_bio+0x78 /0x208 f2fs_submit_page_read+0x44/0x154 f2fs_get_read_data_page+0x288/0x5f4 f2fs_get_lock_data_page+0x60/0x190 truncate_partial_data_page+0x108/0x4fc f2fs_do_truncate_blocks+0x344/0x5f0 f2fs_truncate_blocks+0x6c/0x134 f2fs_truncate+0xd8/0x200 f2fs_iget+0x20c/0x5ac do_garbage_collect+0x5d0/0xf6c f2fs_gc+0x22c /0x6a4 f2fs_disable_checkpoint+0xc8/0x310 f2fs_fill_super+0x14bc/0x1764 mount_bdev+0x1b4/0x21c f2fs_mount+0x20/0x30 Legacy_get_tree+0x50/0xbc vfs_get_tree+0x5c/0x1b0 8/0x4cc path_mount+0x33c/0x5fc __arm64_sys_mount+0xcc/0x15c invoke_syscall+0x60 /0x150 el0_svc_common+0xb8/0xf8 do_el0_svc+0x28/0xa0 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec Es porque inode.i_crypt_info no se inicializa durante la siguiente ruta: - mount - f2fs_fill_super - f2fs_disable_checkpoint - fs_gc - f2fs_iget - f2fs_truncate Entonces, reubique el truncamiento de bloques preasignados a f2fs_file_open(), después de fscrypt_file_open().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: remoteproc: imx_rproc: omitir la región de memoria cuando el valor del nodo es NULL En imx_rproc_addr_init() "nph = of_count_phandle_with_args()" solo cuenta el número de phandles. Pero los phandles pueden estar vacíos. Por lo tanto, of_parse_phandle() en el bucle de análisis (0 < a < nph) puede devolver NULL, que luego se desreferencia. Ajuste este problema agregando una verificación de retorno NULL. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE. [Título fijo para que se ajuste a los 70-75 caracteres prescritos]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethtool: pse-pd: Arreglar posible null-deref Arreglar una posible desreferencia nula cuando un PSE soporta tanto c33 como PoDL, pero solo se especifica uno de los atributos netlink. Las capacidades de c33 o PoDL PSE ya están validadas en la llamada ethnl_set_pse_validate().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrigió la verificación de desbordamiento en ajustar_jmp_off() ajuste_jmp_off() usó incorrectamente el campo insn->imm para toda la verificación de desbordamiento, lo cual es incorrecto ya que eso solo debe hacerse o el BPF_JMP32 | Caso BPF_JA, no el caso de instrucción de salto general. Solucionelo usando insn->off para verificar el desbordamiento en el caso general.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: riscv, bpf: soluciona el problema de fuera de los límites al preparar la imagen del trampolín. Obtenemos el tamaño de la imagen del trampolín durante la fase de ejecución en seco y asignamos memoria en función de ese tamaño. La imagen asignada se completará con instrucciones durante la fase de parche real. Pero después del commit 26ef208c209a ("bpf: Use arch_bpf_trampoline_size"), el argumento `im` es inconsistente en la fase de prueba y de parche real. Esto puede hacer que emit_imm en RV64 genere una cantidad diferente de instrucciones al generar la dirección 'im', lo que podría causar problemas fuera de los límites. Emitamos la cantidad máxima de instrucciones para la dirección "im" durante el ensayo para solucionar este problema.