Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: se corrige una posible pérdida de memoria en gpu_metrics_table La memoria está asignada para gpu_metrics_table en renoir_init_smc_tables(), pero no se libera en int smu_v12_0_fini_smc_tables(). ¡Libérenla!

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/plane: mover la comprobación de rango para format_count antes Si bien la comprobación para format_count > 64 en __drm_universal_plane_init() no debería verse afectada (es un WARN_ON), en su posición actual perderá la matriz plane->format_types y no podrá llamar a drm_mode_object_unregister(), lo que filtra el identificador modeset. Muévalo al inicio de la función para evitar asignar esos recursos en primer lugar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Se han solucionado algunas fugas de memoria en una ruta de manejo de errores de 'log_replay()'. Todas las rutas de manejo de errores conducen a 'out', donde se liberan muchos recursos. Hágalo también aquí en lugar de un retorno directo, de lo contrario, se producirán fugas de 'log', 'ra' y 'log->one_page_buf' (al menos).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: ir_toy: free before error exiting Se corrige la fuga en la ruta de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: staging: media: zoran: move videodev alloc Mueva parte del código de zr36057_init() y cree nuevas funciones para manejar zr->video_dev. Esto permite facilitar la lectura del código y reparar una pérdida de memoria en zr->video_dev.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: staging: media: zoran: calcula el número de búfer correcto para zoran_reap_stat_com En el caso tmp_dcim=1, el índice del búfer se calcula mal. Esto genera una desreferencia de puntero NULL más adelante. Por lo tanto, arreglemos el cálculo y agreguemos una verificación para evitar que esto vuelva a aparecer.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Revert "Revert "block, bfq: respetar las fusiones de colas ya configuradas"" Se produjo un fallo [1] junto con la confirmación 2d52c58b9c9b ("block, bfq: respetar las fusiones de colas ya configuradas"). Esta última se revirtió mediante la confirmación ebc69e897e17 ("Revert "block, bfq: respetar las fusiones de colas ya configuradas""). Sin embargo, la confirmación revertida no fue la que introdujo el error. De hecho, activó una UAF introducida por una confirmación diferente, y ahora corregida por la confirmación d29bd41428cf ("block, bfq: restablecer last_bfqq_created al cambiar de grupo"). Por lo tanto, no tiene sentido mantener la confirmación 2d52c58b9c9b ("block, bfq: respetar las fusiones de colas ya configuradas"). Esta confirmación la restaura. [1] https://bugzilla.kernel.org/show_bug.cgi?id=214503

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: qcom: ipq8074: fix PCI-E clock oops Corrige los errores del kernel relacionados con el reloj PCI-E que son causados por un reloj padre faltante. pcie0_rchng_clk_src tiene num_parents establecido en 2, pero solo un padre está realmente establecido a través de parent_hws, también debería tener "XO" definido. Esto hará que el kernel entre en pánico en un puntero NULL en clk_core_get_parent_by_index(). Entonces, para solucionar esto, utilice clk_parent_data para proporcionar los datos del padre gcc_xo_gpll0. Dado que ya existe un static const char * const gcc_xo_gpll0[] utilizado para proporcionar los mismos padres a través de parent_names, convierta esos usuarios a clk_parent_data también. Sin este earlycon es necesario incluso para detectar el OOPS ya que reiniciará la placa antes de que se inicialice el serial con lo siguiente: [0.232279] No se puede manejar la solicitud de paginación del kernel en la dirección virtual 0000a00000000000 [0.232322] Información de aborto de memoria: [0.239094] ESR = 0x96000004 [0.241778] EC = 0x25: DABT (EL actual), IL = 32 bits [0.244908] SET = 0, FnV = 0 [0.250377] EA = 0, S1PTW = 0 [0.253236] FSC = 0x04: falla de traducción de nivel 0 [0.256277] Información de aborto de datos: [0.261141] ISV = 0, ISS = 0x00000004 [ 0.264262] CM = 0, WnR = 0 [ 0.267820] [0000a00000000000] dirección entre los rangos de direcciones del usuario y del núcleo [ 0.270954] Error interno: Oops: 96000004 [#1] SMP [ 0.278067] Módulos vinculados en: [ 0.282751] CPU: 1 PID: 1 Comm: swapper/0 No contaminado 5.15.10 #0 [ 0.285882] Nombre del hardware: Xiaomi AX3600 (DT) [ 0.292043] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0,296299] pc: clk_core_get_parent_by_index+0x68/0xec [0,303067] lr: __clk_register+0x1d8/0x820 [0,308273] sp: ffffffc01111b7d0 [0,312438] x29: ffffffc01111b7d0 x28: 0000000000000000 x27: 0000000000000040 [0,315919] x26: 000000000000002 x25: 0000000000000000 x24: ffffff8000308800 [ 0,323037] x23: ffffff8000308850 x22: ffffff8000308880 x21: ffffff8000308828 [ 0,330155] x20: 0000000000000028 x19: ffffff8000309700 x18: 0000000000000020 [ 0,337272] x17: 000000005cc86990 x16: 0000000000000004 x15: ffffff80001d9d0a [ 0,344391] x14: 0000000000000000 x13: 00000000000000000 x12: 0000000000000006 [ 0.351508] x11: 0000000000000003 x10: 0101010101010101 x9 : 0000000000000000 [ 0.358626] x8 : 7f7f7f7f7f7f7f7f x7 : 6468626f5e626266 x6 : 17000a3a403c1b06 [ 0.365744] x5 : 061b3c403a0a0017 x4 : 000000000000000 x3 : 0000000000000001 [ 0.372863] x2 : 0000a00000000000 x1 : 0000000000000001 x0 : ffffff8000309700 [ 0.379982] Rastreo de llamadas: [ 0.387091] clk_core_get_parent_by_index+0x68/0xec [ 0.389351] __clk_register+0x1d8/0x820 [ 0.394210] devm_clk_hw_register+0x5c/0xe0 [ 0.398030] devm_clk_register_regmap+0x44/0x8c [ 0.402198] qcom_cc_really_probe+0x17c/0x1d0 [ 0.406711] qcom_cc_probe+0x34/0x44 [ 0.411224] gcc_ipq8074_probe+0x18/0x30 [ 0.414869] platform_probe+0x68/0xe0 [ 0.418776] really_probe.part.0+0x9c/0x30c [ 0.422336] __driver_probe_device+0x98/0x144 [ 0.426329] driver_probe_device+0x44/0x11c [ 0.430842] __device_attach_driver+0xb4/0x120 [ 0.434836] bus_for_each_drv+0x68/0xb0 [ 0.439349] __device_attach+0xb0/0x170 [ 0.443081] device_initial_probe+0x14/0x20 [ 0.446901] bus_probe_device+0x9c/0xa4 [ 0.451067] device_add+0x35c/0x834 [ 0.454886] of_device_add+0x54/0x64 [ 0.458360] of_platform_device_create_pdata+0xc0/0x100 [ 0.462181] of_platform_bus_create+0x114/0x370 [ 0.467128] of_platform_bus_create+0x15c/0x370 [ 0.471641] of_platform_populate+0x50/0xcc [ 0.476155] of_platform_default_populate_init+0xa8/0xc8 [ 0.480324] do_one_initcall+0x50/0x1b0 [ 0.485877] kernel_init_freeable+0x234/0x29c [ 0.489436] kernel_init+0x24/0x120 [ 0.493948] ret_from_fork+0x10/0x20 [ 0.497253] Código: d50323bf d65f03c0 f94002a2 b4000302 (f9400042) [ 0.501079] ---[ fin del seguimiento 4ca7e1129da2abce ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpu: host1x: Se corrige una pérdida de memoria en 'host1x_remove()'. Se agrega una llamada 'host1x_channel_list_free()' faltante en la función de eliminación, como ya se hizo en la ruta de manejo de errores de la función de sonda.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udmabuf: validar ubuf->pagecount Syzbot ha informado de un GPF en sg_alloc_append_table_from_pages(). El problema estaba en ubuf->pages == ZERO_PTR. ubuf->pagecount se calcula a partir de los argumentos pasados desde el espacio de usuario. Si el usuario crea udmabuf con list.size == 0, entonces ubuf->pagecount también será igual a cero; esto hace que kmalloc_array() devuelva ZERO_PTR. Arréglelo validando ubuf->pagecount antes de pasarlo a kmalloc_array().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: soc-compress: evita el posible uso de un puntero nulo Hay un seguimiento de llamada que snd_soc_register_card() ->snd_soc_bind_card()->soc_init_pcm_runtime() ->snd_soc_dai_compress_new()->snd_soc_new_compress(). En el seguimiento, 'codec_dai' se transfiere desde card->dai_link, y podemos ver desde snd_soc_add_pcm_runtime() en snd_soc_bind_card() que, si el valor de card->dai_link->num_codecs es 0, entonces 'codec_dai' podría ser un puntero nulo causado por un índice fuera de los límites en 'asoc_rtd_to_codec(rtd, 0)'. Además, varias plataformas llaman a snd_soc_register_card(), por lo que es mejor agregar la verificación en caso de uso incorrecto. Y como 'cpu_dai' ya se ha verificado en soc_init_pcm_runtime(), no es necesario volver a verificar. Si se agrega la verificación de la siguiente manera, si 'codec_dai' es nulo, snd_soc_new_compress() no pasará la verificación 'if (playback + capture != 1)', lo que evita el uso sobrante de 'codec_dai'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: rpmpd: Verificar el retorno nulo de devm_kcalloc Debido al posible fallo de la asignación, data->domains podría ser un puntero NULL y provocará la desreferencia del puntero NULL más adelante. Por lo tanto, podría ser mejor verificarlo y devolver directamente -ENOMEM sin liberar los datos manualmente si falla, porque el comentario de devm_kmalloc() dice "La memoria asignada con esta función se libera automáticamente al desconectar el controlador".