Vulnerabilidades

ServiceNow ha solucionado una vulnerabilidad de omisión de autorización que se identificó en la versión de Washington de Now Platform. Esta vulnerabilidad, si se explota, podría permitir que un usuario autenticado acceda a datos no autorizados almacenados en Now Platform a los que, de otro modo, el usuario no tendría derecho a acceder. Este problema se soluciona en los parches y la versión de la familia que se indican, que se han puesto a disposición de los clientes alojados y autoalojados, así como de los socios.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: RDMA/rxe: Se corrige la advertencia "__rxe_cleanup+0x12c/0x170 [rdma_rxe]" El seguimiento de llamadas es el siguiente: " ? show_regs.cold+0x1a/0x1f ? __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? __warn+0x84/0xd0 ? __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? report_bug+0x105/0x180 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? __rxe_cleanup+0x124/0x170 [rdma_rxe] rxe_destroy_qp.cold+0x24/0x29 [rdma_rxe] ib_destroy_qp_user+0x118/0x190 [ib_core] rdma_destroy_qp.cold+0x43/0x5e [rdma_cm] rtrs_cq_qp_destroy.cold+0x1d/0x2b [rtrs_core] rtrs_srv_close_work.cold+0x1b/0x31 [rtrs_server] process_one_work+0x21d/0x3f0 worker_thread+0x4a/0x3c0 ? process_one_work+0x3f0/0x3f0 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 "Cuando se asignan demasiados recursos rdma, rxe necesita más tiempo para gestionar estos recursos rdma. A veces, con el tiempo de espera actual, rxe no puede liberar los recursos rdma correctamente. En comparación con otros controladores rdma, se utiliza un tiempo de espera mayor.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool() el commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq ending variable initialization") introdujo una barrera de escritura en la función de sondeo para almacenar la variable global '__scm'. Todos sabemos que las barreras están emparejadas (consulte memory-barriers.txt: "Note que las barreras de escritura normalmente deben emparejarse con barreras de lectura o de dependencia de dirección"), por lo tanto, acceder a ellas desde contextos concurrentes requiere una barrera de lectura. Una confirmación anterior agregó dicha barrera en qcom_scm_is_available(), así que usémosla directamente. La falta de esta barrera de lectura puede resultar en la obtención del valor de la variable '__scm' obsoleto, NULL, y su desreferenciación. Tenga en cuenta que la barrera en qcom_scm_is_available() satisface aquí la dependencia de control.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: dispcc-sm6350: Add missing parent_map for a clock If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c Agregue la propiedad parent_map para el reloj donde falta y también desvincule parent_data para mantener juntos los parent_map y parent_data coincidentes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: mmp2: llamar a pm_genpd_init() solo después de que se establece genpd.name La configuración del nombre del dispositivo de la estructura genpd con dev_set_name() ocurre dentro de pm_genpd_init(). Si permanece NULL, las cosas pueden explotar más tarde, como al crear la jerarquía devfs para el dominio de energía: No se puede gestionar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000 cuando se lee ... Rastreo de llamadas: start_creating+0x90/0x138 start_creating from debugfs_create_dir+0x20/0x178 debugfs_create_dir from genpd_debug_add.part.0+0x4c/0x144 genpd_debug_add.part.0 from genpd_debug_init+0x74/0x90 genpd_debug_init from do_one_initcall+0x5c/0x244 do_one_initcall from kernel_init_freeable+0x19c/0x1f4 kernel_init_freeable from kernel_init+0x1c/0x12c kernel_init from ret_from_fork+0x14/0x28 Bisecting rastrea este fallo hasta el commit 899f44531fe6 ("pmdomain: core: Agregar bandera GENPD_FLAG_DEV_NAME_FW"), que intercambia el uso de genpd->name con dev_name(&genpd->dev) en genpd_debug_add.part().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: uvcvideo: Se corrige el fallo durante la desvinculación si la unidad gpio está en uso. Usamos el dispositivo incorrecto para las funciones administradas por el dispositivo. Usamos el dispositivo usb, cuando deberíamos estar usando el dispositivo de interfaz. Si desvinculamos el controlador de la interfaz usb, las funciones de limpieza nunca se llaman. En nuestro caso, la IRQ nunca se deshabilita. Si se activa una IRQ, intentará acceder a secciones de memoria que ya están libres, lo que provocará un OOPS. No podemos usar la función devm_request_threaded_irq aquí. Las funciones de limpieza devm_* pueden llamarse después de que uvc_delete libere la estructura principal. Afortunadamente, este error tiene un impacto pequeño, ya que solo se ve afectado por dispositivos con unidades gpio y el usuario tiene que desvincular el dispositivo, una desconexión no activará este error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tomoyo: no emitir advertencia en tomoyo_write_control() syzbot informa una advertencia de asignación demasiado grande en tomoyo_write_control(), ya que se puede escribir una línea muy larga sin un carácter de nueva línea. Para corregir esta advertencia, uso __GFP_NOWARN en lugar de verificar KMALLOC_MAX_SIZE, ya que prácticamente una línea válida siempre debe ser más corta que 32 KB donde se aplica la regla de asignación de memoria "demasiado pequeña para fallar". Uno podría intentar escribir una línea válida que sea más larga que 32 KB, pero tal solicitud probablemente fallará con -ENOMEM. Por lo tanto, creo que devolver por separado -EINVAL cuando una línea es más larga que KMALLOC_MAX_SIZE es redundante. No hay necesidad de distinguir entre más de 32 KB y más de KMALLOC_MAX_SIZE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: misc_minor_alloc para usar ida para todos los menores dinámicos/misc dinámicos misc_minor_alloc asignaba id usando ida para menores solo en el caso de MISC_DYNAMIC_MINOR pero misc_minor_free siempre liberaba id usando ida_free, lo que causaba una falta de coincidencia y la siguiente advertencia: > > WARNING: CPU: 0 PID: 159 at lib/idr.c:525 ida_free+0x3e0/0x41f > > ida_free called for id=127 which is not allocated. > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ... > > [<60941eb4>] ida_free+0x3e0/0x41f > > [<605ac993>] misc_minor_free+0x3e/0xbc > > [<605acb82>] misc_deregister+0x171/0x1b3 misc_minor_alloc Se cambió misc_minor_alloc para asignar id de ida para todos los menores que caen en el rango de menores dinámicos/misc dinámicos

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: nuvoton: Se corrige una comprobación de errores en npcm_video_ece_init(). Cuando la función of_find_device_by_node() falla, devuelve NULL en lugar de un código de error. Por lo tanto, se debe modificar la lógica de comprobación de errores correspondiente para verificar si el valor de retorno es NULL y establecer el código de error que se devolverá como -ENODEV.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: verificar explícitamente que la vCPU de destino esté en línea en kvm_get_vcpu() Verifique explícitamente que la vCPU de destino esté completamente en línea _antes_ de fijar el índice en kvm_get_vcpu(). Si el índice es "malo", la fijación nospec generará '0', es decir, KVM devolverá vCPU0 en lugar de NULL. En la práctica, es poco probable que el error cause problemas, ya que solo entrará en juego si el espacio de usuario o el invitado tienen errores o se comportan mal, por ejemplo, KVM puede enviar interrupciones a vCPU0 en lugar de dejarlas en el suelo. Sin embargo, devolver vCPU0 cuando no debería existir según online_vcpus es problemático ahora que KVM usa una matriz x para la matriz vCPUs, ya que KVM necesita insertar en la matriz x antes de publicar la vCPU en el espacio de usuario (consulte el commit c5b077549136 ("KVM: Convertir la matriz kvm->vcpus en una matriz x")), es decir, antes de que se garantice que la creación de la vCPU sea exitosa. Como resultado, proporcionar acceso incorrectamente a vCPU0 activará un uso después de liberación si se desreferencia a vCPU0 y kvm_vm_ioctl_create_vcpu() abandona la creación de la vCPU debido a un error y libera vCPU0. El commit afb2acb2e3a3 ("KVM: Reparar las ejecuciones vcpu_array[0]") disimuló ese problema, pero al hacerlo introdujo un enigma de desmontaje irresoluble. Evitar accesos a vCPU0 antes de que esté completamente en línea permitirá revertir el commit afb2acb2e3a3, sin volver a introducir la ejecución UAF vcpu_array[0].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: soc-pcm: no usar soc_pcm_ret() en la devolución de llamada .prepare commit 1f5664351410 ("ASoC: menor severidad del registro "no backend DAIs enabled for ... Port") ignora el mensaje de error -EINVAL en soc_pcm_ret() común. Se usa desde muchas funciones, ignorar -EINVAL es exagerado. La razón por la que se ignoró -EINVAL fue que realmente solo debería usarse en parámetros no válidos que provengan del espacio de usuario y, en ese caso, no queremos registrar un error ya que no queremos darle al espacio de usuario una forma de realizar un ataque de denegación de servicio en el syslog / espacio de disco. Por lo tanto, no usar soc_pcm_ret() en la devolución de llamada .prepare es una mejor idea.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: gcc-sm6350: Add missing parent_map for two clocks If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c Agregue la propiedad parent_map para dos relojes donde falta y también desvincule parent_data para mantener juntos los parent_map y parent_data coincidentes.