Vulnerabilidades

Hay un ClusterRole en piraeus-operator v2.5.0 y versiones anteriores al que se le ha otorgado permiso de lista de secretos, lo que permite a un atacante hacerse pasar por la cuenta de servicio vinculada a este ClusterRole y usar sus privilegios de alto riesgo para enumerar información confidencial en todo el clúster.

Se descubrió un problema en las API de criptografía Java de Bouncy Castle antes de BC 1.78. Cuando la identificación de endpoint está habilitada en BCJSSE y se crea un socket SSL sin un nombre de host explícito (como sucede con HttpsURLConnection), la verificación del nombre de host podría realizarse contra una dirección IP resuelta por DNS en algunas situaciones, lo que abre una posibilidad de envenenamiento de DNS.

IBM Aspera Orchestrator 4.0.1 podría permitir que un atacante remoto autenticado ejecute comandos arbitrarios en el sistema enviando una solicitud especialmente manipulada. ID de IBM X-Force: 260116.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regmap: spi: reserva de espacio para dirección/relleno de registro Actualmente, los límites max_raw_read y max_raw_write en la estructura regmap_spi no tienen en cuenta el tamaño adicional de la dirección de registro transmitida y el relleno. Esto puede dar como resultado que se exceda el tamaño de mensaje SPI máximo permitido, lo que podría causar un comportamiento indefinido, por ejemplo, corrupción de datos. Corrija regmap_get_spi_bus() para ajustar adecuadamente los límites mencionados anteriormente reservando espacio para la dirección/relleno del registro como se establece en la configuración de regmap.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: corrige un use-after-free. Solucione la siguiente queja de use-after-free activada por blktests nvme/004: ERROR: KASAN: acceso a la memoria del usuario en blk_mq_complete_request_remote+0xac /0x350 Lectura de tamaño 4 en la dirección 0000607bd1835943 por tarea kworker/13:1/460 Cola de trabajo: nvmet-wq nvme_loop_execute_work [nvme_loop] Seguimiento de llamadas: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e /0x1e2 informe_kasan+0xb9 /0xf0 __asan_load4+0x6b/0x80 blk_mq_complete_request_remote+0xac/0x350 nvme_loop_queue_response+0x1df/0x275 [nvme_loop] __nvmet_req_complete+0x132/0x4f0 [nvmet_req_complete+0x15/0x 40 [nvmet] nvmet_execute_io_connect+0x18a/0x1f0 [nvmet] nvme_loop_execute_work+0x20/0x30 [ nvme_loop] proceso_one_work+0x56e/0xa70 trabajador_thread+0x2d1/0x640 kthread+0x183/0x1c0 ret_from_fork+0x1f/0x30

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: soluciona la pérdida de memoria al usar debugfs_lookup() Al llamar a debugfs_lookup(), el resultado debe tener llamado dput(); de lo contrario, la memoria se perderá con el tiempo. Solucione este problema llamando correctamente a dput().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/debug: corrige la fuga de dentry en update_sched_domain_debugfs Kuyo informa que el patrón de uso de debugfs_remove(debugfs_lookup()) pierde un dentry y con una prueba de estrés de conexión en caliente, la máquina eventualmente se queda sin memoria. Solucione este problema utilizando la llamada debugfs_lookup_and_remove() recién creada, que maneja adecuadamente la lógica de conteo de referencias de dentry.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vfio/type1: Desanclar páginas cero Actualmente hay una pérdida de recuento de referencias en la página cero. Incrementamos la referencia a través de pin_user_pages_remote(), pero la página luego se maneja como una página no válida/reservada, por lo tanto, no se contabiliza contra el usuario y nuestro put_pfn() no la desancla. Introducir un manejo especial de la página cero en put_pfn() resolvería la fuga, pero sin tener en cuenta la página cero, un solo usuario aún podría crear suficientes asignaciones para generar un desbordamiento del recuento de referencias. La página cero siempre es residente, por lo que para nuestros propósitos no hay motivo para mantenerla fijada. Por lo tanto, agregue un bucle para recorrer las páginas devueltas desde pin_user_pages_remote() y desanclar las páginas cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: corrige un error fuera de los límites en __snd_usb_parse_audio_interface() Puede haber un dispositivo de audio USB defectuoso con una ID de USB de (0x04fa, 0x4201) y el Si el número de interfaces es inferior a 4, se produce un error de lectura fuera de límites al analizar el descriptor de interfaz para este dispositivo. Solucione este problema verificando la cantidad de interfaces.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ALSA: emu10k1: corrige el acceso fuera de los límites en snd_emu10k1_pcm_channel_alloc() El asignador de voz a veces comienza a asignar desde cerca del final de la matriz y luego regresa, sin embargo, snd_emu10k1_pcm_channel_alloc() accede al nuevo asignó voces como si nunca hubiera terminado. Esto da como resultado un acceso fuera de los límites si la primera voz tiene un índice lo suficientemente alto como para que primera_voz + recuento_de_voces_solicitadas > NUM_G (64). Cuantas más voces se soliciten, más probabilidades habrá de que esto ocurra. Esto se descubrió inicialmente usando PipeWire, sin embargo, se puede reproducir llamando a aplay varias veces con 16 canales: aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero UBSAN: array-index-out -of-bounds en sound/pci/emu10k1/emupcm.c:127:40 el índice 65 está fuera de rango para el tipo 'snd_emu10k1_voice [64]' CPU: 1 PID: 31977 Comm: aplay Contaminado: GW IOE 6.0.0-rc2 -emu10k1+ #7 Nombre del hardware: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 22/07/2010 Seguimiento de llamadas: dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x3f __ubsan_handle_out_of_bounds.cold + 0x44/0x49 snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1] snd_pcm_hw_params+0x29f/0x600 [snd_pcm] snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm] ? exit_to_user_mode_prepare+0x35/0x170? do_syscall_64+0x69/0x90? syscall_exit_to_user_mode+0x26/0x50? do_syscall_64+0x69/0x90? exit_to_user_mode_prepare+0x35/0x170 snd_pcm_ioctl+0x27/0x40 [snd_pcm] __x64_sys_ioctl+0x95/0xd0 do_syscall_64+0x5c/0x90 ? do_syscall_64+0x69/0x90? do_syscall_64+0x69/0x90 entrada_SYSCALL_64_after_hwframe+0x63/0xcd

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thermal/int340x_thermal: maneja data_vault cuando el valor es ZERO_SIZE_PTR. En algunos casos, el GDDV devuelve un paquete con un buffer que tiene longitud cero. Provoca que kmemdup() devuelva ZERO_SIZE_PTR (0x10). Luego, data_vault_read() tuvo un problema de desreferencia de punto NULL al acceder al valor 0x10 en data_vault. [71.024560] ERROR: desreferencia del puntero NULL del kernel, dirección: 00000000000000010 Este parche usa ZERO_OR_NULL_PTR() para verificar ZERO_SIZE_PTR o el valor NULL en data_vault.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/irdma: corrige el drenaje de SQ que se bloquea sin completarse. Las finalizaciones generadas por SW para los WR pendientes publicados en SQ después de que QP tiene un error apuntan al CQ incorrecto. Esto hace que ib_drain_sq se cuelgue sin completarse. Solucione este problema para generar terminaciones en el CQ derecho. [863.969340] INFORMACIÓN: tarea kworker/u52:2:671 bloqueada durante más de 122 segundos. [863.979224] No contaminado 5.14.0-130.el9.x86_64 #1 [863.986588] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. [863.996997] tarea:kworker/u52:2 estado:D pila: 0 pid: 671 ppid: 2 banderas:0x00004000 [864.007272] Cola de trabajo: xprtiod xprt_autoclose [sunrpc] [864.014056] Seguimiento de llamadas: [864.017575] regla+0x206/0x580 [ 864.022296] programación+0x43/0xa0 [ 864.026736] programación_timeout+0x115/0x150 [ 864.032185] __wait_for_common+0x93/0x1d0 [ 864.037717] ? usleep_range_state+0x90/0x90 [864.043368] __ib_drain_sq+0xf6/0x170 [ib_core] [864.049371] ? __rdma_block_iter_next+0x80/0x80 [ib_core] [ 864.056240] ib_drain_sq+0x66/0x70 [ib_core] [ 864.062003] rpcrdma_xprt_disconnect+0x82/0x3b0 [rpcrdma] [ 864.069365] ? xprt_prepare_transmit+0x5d/0xc0 [sunrpc] [ 864.076386] xprt_rdma_close+0xe/0x30 [rpcrdma] [ 864.082593] xprt_autoclose+0x52/0x100 [sunrpc] [ 864.088718] x3c0 [864.094170] hilo_trabajador+0x50/0x3b0 [864.099109]? hilo_rescate+0x370/0x370 [ 864.104473] kthread+0x149/0x170 [ 864.109022] ? set_kthread_struct+0x40/0x40 [864.114713] ret_from_fork+0x22/0x30