Vulnerabilidades

El complemento CSV Me para WordPress es vulnerable a la carga de archivos arbitrarios debido a una validación insuficiente del tipo de archivo en la función 'csv_me_options_page' en todas las versiones hasta la 2.0 incluida. Esto permite que atacantes autenticados, con acceso de administrador o superior, carguen archivos arbitrarios en el servidor del sitio afectado, lo que podría posibilitar la ejecución remota de código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: alloc_tag: asignar contadores por CPU para etiquetas de módulo dinámicamente Cuando se descarga un módulo, este verifica si alguna de sus etiquetas aún está en uso y, de ser así, mantenemos activa la memoria que contiene las etiquetas de asignación del módulo hasta que todas las etiquetas estén sin usar. Sin embargo, los contadores por CPU referenciados por las etiquetas son liberados por free_module(). Esto conducirá a UAF si se accede a la memoria asignada por un módulo después de que el módulo se haya descargado. Para corregir esto, asignamos contadores por CPU para etiquetas de asignación de módulo dinámicamente y los mantenemos activos para las etiquetas que aún están en uso después de la descarga del módulo. Esto también elimina el requisito de un PERCPU_MODULE_RESERVE más grande cuando el perfil de asignación de memoria está habilitado porque la memoria por CPU para los contadores ya no necesita reservarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Aumentar el tamaño de la matriz block_sequence [Por qué] Es posible generar más de 50 pasos en hwss_build_fast_sequence, por ejemplo, con un ASIC de 6 tuberías donde todas las tuberías están en una cadena MPC. Esto desborda el búfer block_sequence y corrompe block_sequence_steps, lo que provoca un fallo. [Cómo] Ampliar block_sequence a 100 elementos. Un límite superior simple para el número posible de pasos para un ASIC de 6 tuberías, ignorando la posibilidad de que los pasos sean mutuamente excluyentes, es 91 con el código actual; por lo tanto, 100 es suficiente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi-rockchip: Se corrige el acceso fuera de los límites al registro. No se debe escribir información de selección de chip nativa para las selecciones de chip GPIO. Las GPIO pueden tener una numeración mucho mayor que la de las CS nativas. Además, no tiene sentido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: virtuser: corrección de una posible escritura fuera de límite. Si el llamador escribió más caracteres, el recuento se trunca al espacio máximo disponible en "simple_write_to_buffer". Compruebe que el tamaño de entrada no supere el tamaño del búfer. Escriba una terminación de cero después.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: algif_hash - corrección de doble liberación en hash_accept. Si se ejecuta accept(2) en el socket tipo algif_hash con el indicador MSG_MORE activado y crypto_ahash_import falla, se libera sk2. Sin embargo, también se libera en af_alg_release, lo que genera un error de uso de slab después de la liberación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: pcm: Corrección de la ejecución de acceso al búfer en la capa PCM OSS. La capa PCM OSS intenta borrar el búfer con los datos de silencio durante la inicialización (o reconfiguración) de un flujo mediante la llamada explícita a snd_pcm_format_set_silence() con runtime->dma_area. Sin embargo, esto puede generar una UAF, ya que el acceso a runtime->dma_area podría liberarse simultáneamente, ya que se realiza fuera de las operaciones PCM. Para evitarlo, mueva el código al núcleo PCM y ejecútelo dentro del bloqueo de acceso al búfer, de modo que no se modifique durante la operación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86: dell-wmi-sysman: Evitar el desbordamiento de búfer en current_password_store(). Si la matriz 'buf' recibida del usuario contiene una cadena vacía, la variable 'length' será cero. Acceder al elemento de la matriz 'buf' con el índice 'length - 1' provocará un desbordamiento de búfer. Se ha añadido una comprobación para cadenas vacías. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: sma1307: Se ha añadido una comprobación de valores nulos en sma1307_setting_loaded(). Todas las variables asignadas por kzalloc y devm_kzalloc podrían ser nulas. Se han añadido varias comprobaciones de punteros y su limpieza. Nuestra herramienta de análisis estático ha detectado este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: endpoint: pci-epf-test: Se corrige la doble liberación que provoca un error en el kernel. Se corrige un error en el kernel detectado al probar el controlador de endpoint stm32_pcie con el manejo de la deaserción PERST#: Durante la inicialización de EP, pci_epf_test_alloc_space() asigna todos los BAR, que se liberan aún más si epc_set_bar() falla (por ejemplo, debido a que no hay una ventana de entrada libre). Sin embargo, cuando pci_epc_set_bar() falla, la ruta de error: pci_epc_set_bar() -> pci_epf_free_space() no borra la asignación previa a epf_test->reg[bar]. Luego, si el host se reinicia, la desasignación PERST# reinicia la secuencia de asignación de BAR con el mismo fallo de asignación (sin ventana de entrada libre), lo que crea una situación de doble liberación, ya que epf_test->reg[bar] se desasignó y sigue siendo distinto de NULL. Por lo tanto, asegúrese de que las invocaciones de pci_epf_alloc_space() y pci_epf_free_space() sean simétricas y, por lo tanto, establezca epf_test->reg[bar] en NULL cuando se libere memoria. [kwilczynski: registro de confirmaciones]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: corregir ejecución entre set_blocksize y las rutas de lectura Con el nuevo soporte para tamaños de sector grandes, ahora es posible que set_blocksize cambie i_blksize y el orden de los folios de forma que entre en conflicto con un lector concurrente y provoque un fallo del kernel. Específicamente, supongamos que udev-worker llama a libblkid para detectar las etiquetas en un dispositivo de bloque. La llamada de lectura puede crear un folio de orden 0 para leer los primeros 4096 bytes del disco. Pero entonces udev es interrumpido. A continuación, alguien intenta montar un sistema de archivos de tamaño de sector de 8k desde el mismo dispositivo de bloque. El sistema de archivos llama a set_blksize, que establece i_blksize en 8192 y el orden mínimo de folio en 1. Ahora udev se reanuda, aún manteniendo el folio de orden 0 que asignó. Entonces intenta programar una biografía de lectura y do_mpage_readahead intenta crear bufferheads para el folio. Desafortunadamente, bloques_por_folio == 0 porque el tamaño de página es 4096, pero el tamaño de bloque es 8192, por lo que no se conectan bufferheads y el bh walk nunca establece bdev. Luego, enviamos la biografía con un dispositivo de bloque nulo y se produce un fallo. Por lo tanto, truncamos la caché de páginas después del vaciado, pero antes de actualizar i_blksize. Sin embargo, esto no es suficiente; también necesitamos bloquear la E/S de archivos y los fallos de página durante la actualización. Use tanto i_rwsem como invalidate_lock en modo exclusivo para invalidaciones y en modo compartido para operaciones de lectura/escritura. No sé si esta sea la solución correcta, pero xfs/259 la encontró.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: iscsi: Se corrige el tiempo de espera en la conexión eliminada. El temporizador de respuesta NOPIN puede expirar en una conexión eliminada y bloquearse con dichos registros: No se recibió respuesta a NOPIN en CID: 0, falla de conexión para I_T Nexus (nulo),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d ERROR: Desreferencia de puntero NULL del kernel en lectura en 0x00000000 NIP strlcpy+0x8/0xb0 LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod] Rastreo de llamadas: iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod] call_timer_fn+0x58/0x1f0 run_timer_softirq+0x740/0x860 __do_softirq+0x16c/0x420 irq_exit+0x188/0x1c0 timer_interrupt+0x184/0x410 Esto se debe a que el temporizador de respuesta de nopin puede reiniciarse al expirar. Deténgalo antes de detener el temporizador de respuesta de nopin para asegurarse de que ninguno de ellos se reinicie.