Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ocfs2: gestiona correctamente un error de lectura de enlace simbólico Serie de parches "Convertir ocfs2 para usar folios". Mark hizo una conversión de ocfs2 para usar folios y me lo envió como un parche gigante para revisión ;-) Así que lo rehice como parches individuales y le di crédito a Mark por los parches donde su código es sustancialmente el mismo. No es una mala forma de hacerlo; su parche tenía algunos errores y mis parches tenían algunos errores. Con suerte, todos nuestros errores fueron diferentes entre sí. ¡Y con suerte a Mark le gustan todos los cambios que hice en su código! Este parche (de 23): Si no podemos leer el búfer, asegúrese de desbloquear la página antes de regresar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: uvcvideo: Eliminar punteros colgantes Cuando se escribe un control asíncrono, copiamos un puntero al identificador de archivo que inició la operación. Ese puntero se utilizará cuando el dispositivo termine. Lo que podría ser en cualquier momento en el futuro. Si el usuario cierra ese descriptor de archivo, se liberará su estructura y habrá un puntero colgante por cada control asíncrono pendiente, que el controlador intentará utilizar. Limpie todos los punteros colgantes durante release(). Para evitar agregar una penalización de rendimiento en el caso más común (sin operación asíncrona), se ha introducido un contador con cierta lógica para asegurarse de que se gestiona correctamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tpm: Cambio a kvalloc() en eventlog/acpi.c Se informó el siguiente error en HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 La transcripción anterior muestra que ACPI apuntó a un búfer de 16 MiB para los eventos de registro porque RSI se asigna al parámetro 'order' de __alloc_pages_noprof(). Solucione el error pasando de devm_kmalloc() a devm_add_action() y kvmalloc() y devm_add_action().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: qcom: socinfo: Evitar la lectura fuera de los límites del número de serie En los dispositivos MSM8916, el número de serie expuesto en sysfs es constante y no cambia en los dispositivos individuales. Siempre es: db410c:/sys/devices/soc0$ cat serial_number 2644893864 El firmware utilizado en MSM8916 expone SOCINFO_VERSION(0, 8), que no tiene soporte para el campo serial_num en la estructura socinfo. Existe una comprobación para evitar exponer el número de serie en ese caso, pero no es correcta: Al comprobar el item_size devuelto por SMEM, debemos asegurarnos de que el *final* del serial_num esté dentro de los límites, en lugar de compararlo con el desplazamiento *inicio*. El serial_number que se expone actualmente en los dispositivos MSM8916 es simplemente una lectura fuera de límites de lo que viene después de la estructura sociinfo en SMEM. Solucione esto cambiando offsetof() a offsetofend(), de modo que también se tenga en cuenta el tamaño del campo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: L2CAP: gestionar puntero sock NULL en l2cap_sock_alloc Se pasa un puntero sock NULL a l2cap_sock_alloc() cuando se llama desde l2cap_sock_new_connection_cb() y las rutas de gestión de errores también deberían tenerlo en cuenta. Aparentemente, una solución más elegante sería intercambiar las llamadas bt_sock_alloc() y l2cap_chan_create() ya que no son interdependientes en ese momento, pero luego l2cap_chan_create() agrega el canal que pronto se desasignará y aún tiene inicialización ficticia a la lista global accesible por muchas rutas L2CAP. El canal se eliminaría de la lista en un corto período de tiempo, pero aquí sería un poco más directo y solo verificaría si es NULL en lugar de cambiar el orden de las llamadas de función. Encontrado por Linux Verification Center (linuxtesting.org) con la herramienta de análisis estático SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binfmt_flat: soluciona un error de desbordamiento de enteros en sistemas de 32 bits La mayoría de estos tamaños y recuentos están limitados a 256 MB, por lo que el cálculo no da como resultado un desbordamiento de enteros. También es necesario comprobar el recuento de "relocs". De lo contrario, en sistemas de 32 bits, el cálculo de "full_data" podría ser incorrecto. full_data = data_len + relocs * sizeof(unsigned long);

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: i2c: ds90ub9x3: Fix extra fwnode_handle_put() Los controladores ub913 y ub953 llaman a fwnode_handle_put(priv->sd.fwnode) como parte de su proceso de eliminación y, si el controlador se elimina varias veces, eventualmente conduce a un "desbordamiento" de put, posiblemente causando corrupción de memoria o falla. fwnode_handle_put() es un remanente del commit 905f88ccebb1 ("media: i2c: ds90ub9x3: Fix sub-device matching"), que cambió el código relacionado con sd.fwnode, pero no eliminó estas llamadas fwnode_handle_put().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: intel/ipu6: eliminar solicitud de QoS de latencia de CPU en caso de error Corrija la corrupción de la lista de QoS de latencia de CPU como se muestra a continuación. Ocurre cuando no eliminamos la solicitud de latencia de CPU en la ruta de error y liberamos la memoria correspondiente. [ 30.634378] l7 kernel: list_add corruption. prev->next should be next (ffffffff9645e960), but was 0000000100100001. (prev=ffff8e9e877e20a8). [ 30.634388] l7 kernel: WARNING: CPU: 2 PID: 2008 at lib/list_debug.c:32 __list_add_valid_or_report+0x83/0xa0 [ 30.634640] l7 kernel: Call Trace: [ 30.634650] l7 kernel: [ 30.634659] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0 [ 30.634669] l7 kernel: ? __warn.cold+0x93/0xf6 [ 30.634678] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0 [ 30.634690] l7 kernel: ? report_bug+0xff/0x140 [ 30.634702] l7 kernel: ? handle_bug+0x58/0x90 [ 30.634712] l7 kernel: ? exc_invalid_op+0x17/0x70 [ 30.634723] l7 kernel: ? asm_exc_invalid_op+0x1a/0x20 [ 30.634733] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0 [ 30.634742] l7 kernel: plist_add+0xdd/0x140 [ 30.634754] l7 kernel: pm_qos_update_target+0xa0/0x1f0 [ 30.634764] l7 kernel: cpu_latency_qos_update_request+0x61/0xc0 [ 30.634773] l7 kernel: intel_dp_aux_xfer+0x4c7/0x6e0 [i915 1f824655ed04687c2b0d23dbce759fa785f6d033]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: dwc: ep: Impedir cambiar el tamaño/indicadores de BAR en pci_epc_set_bar() En el commit 4284c88fff0e ("PCI: designware-ep: Permitir que pci_epc_set_bar() actualice la dirección del mapa de entrada"), se modificó set_bar() para admitir el cambio dinámico de la dirección física de respaldo de un BAR que ya estaba configurado. Esto significa que se puede llamar a set_bar() dos veces, sin llamar nunca a clear_bar() (ya que llamar a clear_bar() borraría la dirección PCI del BAR asignada por el host). Esto solo se puede hacer si el nuevo tamaño/indicadores de BAR no difieren de la configuración de BAR existente. Agregue estas comprobaciones faltantes. Si permitimos que set_bar() establezca, por ejemplo, un nuevo tamaño de BAR que difiere del tamaño de BAR existente, el nuevo rango de traducción de direcciones será más pequeño que el tamaño de BAR ya determinado por el host, lo que significaría que una lectura más allá del nuevo tamaño de BAR pasaría la iATU sin traducir, lo que podría permitir que el host lea memoria que no pertenece a la nueva estructura pci_epf_bar. Mientras tanto, agregue comentarios que aclaren el soporte para cambiar dinámicamente la dirección física de un BAR. (Lo cual también faltaba).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KEYS: trusted: dcp: corrige el uso incorrecto de sg con CONFIG_VMAP_STACK=y Con las direcciones de pila vmalloc habilitadas (CONFIG_VMAP_STACK=y), las claves confiables de DCP pueden fallar durante el cifrado y descifrado de la clave de cifrado de blobs a través del controlador de cifrado DCP. Esto se debe al uso incorrecto de sg_init_one() con búferes de pila vmalloc (plain_key_blob). Solucione esto utilizando siempre kmalloc() para los búferes que le damos al controlador de cifrado DCP.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/tracing: Arreglar un UAF potencial de TP_printk el commit afd2627f727b ("tracing: Comprobar la desreferencia de "%s" mediante el campo y no el formato TP_printk") expone posibles UAF en el evento de seguimiento xe_bo_move. Arregle estos problemas evitando desreferenciar la matriz xe_mem_type_to_name[] en el momento de TP_printk. Dado que se ha realizado cierta refactorización del código, es posible que se necesite una retroportación explícita para kernels anteriores a la versión 6.10.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: vidtv: Se corrige una desreferencia de puntero nulo en vidtv_mux_stop_thread syzbot informa una desreferencia de puntero nulo en vidtv_mux_stop_thread. [1] Si dvb->mux no se inicializa correctamente mediante vidtv_mux_init() en vidtv_start_streaming(), se activará la desreferencia de puntero nulo sobre mux en vidtv_mux_stop_thread(). Ajuste el tiempo de inicialización de la transmisión y verifíquelo antes de detenerlo. [1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f