Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zlib: arregla los bytes avail_in para la ruta de compresión de hardware zlib s390 Dado que la longitud de los datos de entrada que se pasan a zlib_compress_folios() puede ser arbitraria, configurar siempre strm.avail_in como un múltiplo de PAGE_SIZE puede provocar que los bytes de lectura superen el rango de entrada. Actualmente, esto activa una afirmación en btrfs_compress_folios() en el kernel de depuración (ver a continuación). Arregla el cálculo de strm.avail_in para la ruta de aceleración de hardware S390. La afirmación falló: *total_in <= orig_len, en fs/btrfs/compression.c:1041 ------------[ corte aquí ]------------ ¡ERROR del kernel en fs/btrfs/compression.c:1041! Evento de monitor: 0040 ilc:2 [#1] PREEMPT SMP CPU: 16 UID: 0 PID: 325 Comm: kworker/u273:3 No contaminado 6.13.0-20241204.rc1.git6.fae3b21430ca.300.fc41.s390x+debug #1 Nombre de hardware: IBM 3931 A01 703 (z/VM 7.4.0) Cola de trabajo: btrfs-delalloc btrfs_work_helper Krnl PSW: 0704d00180000000 0000021761df6538 (btrfs_compress_folios+0x198/0x1a0) R:0 T:1 IO:1 EX:1 Clave:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 0000000080000000 0000000000000001 0000000000000047 0000000000000000 000000000000006 ffffff01757bb000 000001976232fcc0 000000000000130c 000001976232fcd0 000001976232fcc8 00000118ff4a0e30 0000000000000001 00000111821ab400 0000011100000000 0000021761df6534 000001976232fb58 Código Krnl: 0000021761df6528: c020006f5ef4 larl %r2,0000021762be2310 0000021761df652e: c0e5ffbd09d5 brasl %r14,00000217615978d8 #0000021761df6534: af000000 mc 0,0 >0000021761df6538: 0707 bcr 0,%r7 0000021761df653a: 0707 bcr 0,%r7 0000021761df653c: 0707 bcr 0,%r7 0000021761df653e: 0707 bcr 0,%r7 0000021761df6540: c004004bb7ec brcl 0,000002176276d518 Seguimiento de llamadas: [<0000021761df6538>] btrfs_compress_folios+0x198/0x1a0 ([<0000021761df6534>] btrfs_compress_folios+0x194/0x1a0) [<0000021761d97788>] rango_archivo_comprimir+0x3b8/0x6d0 [<0000021761dcee7c>] ayuda_trabajo_btrfs+0x10c/0x160 [<0000021761645760>] trabajo_proceso_uno+0x2b0/0x5d0 [<000002176164637e>] subproceso_trabajador+0x20e/0x3e0 [<000002176165221a>] subproceso_k+0x15a/0x170 [<00000217615b859c>] __ret_de_bifurcación+0x3c/0x60 [<00000217626e72d2>] ret_de_bifurcación+0xa/0x38 INFORMACIÓN: bloqueo_dep es Desactivado. Dirección del último evento de ruptura: [<0000021761597924>] _printk+0x4c/0x58 Pánico del kernel: no se sincroniza: Excepción fatal: panic_on_oops

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/mediatek: Establecer private->all_drm_private[i]->drm en NULL si mtk_drm_bind devuelve err El puntero debe establecerse en NULL, de lo contrario KASAN se queja de use-after-free. Porque en mtk_drm_bind, todos los drm de private se establecen de la siguiente manera. private->all_drm_private[i]->drm = drm; Y drm será liberado por drm_dev_put en caso de que mtk_drm_kms_init devuelva un error. Sin embargo, la ruta de apagado aún accede a la memoria asignada previamente en drm_atomic_helper_shutdown. [ 84.874820] watchdog: watchdog0: ¡watchdog no se detuvo! [ 86.512054] ======================================================================= [ 86.513162] ERROR: KASAN: use-after-free en drm_atomic_helper_shutdown+0x33c/0x378 [ 86.514258] Lectura de tamaño 8 en la dirección ffff0000d46fc068 por la tarea shutdown/1 [ 86.515213] [ 86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown No contaminado 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55 [ 86.516752] Nombre del hardware: Producto desconocido/Producto desconocido, BIOS 2022.10 10/01/2022 [ 86.517960] Rastreo de llamadas: [ 86.518333] show_stack+0x20/0x38 (C) [ 86.518891] dump_stack_lvl+0x90/0xd0 [ 86.519443] print_report+0xf8/0x5b0 [ 86.519985] kasan_report+0xb4/0x100 [ 86.520526] __asan_report_load8_noabort+0x20/0x30 [ 86.521240] drm_atomic_helper_shutdown+0x33c/0x378 [ 86.521966] apagado_drm_mtk+0x54/0x80 [ 86.522546] apagado_plataforma+0x64/0x90 [ 86.523137] apagado_dispositivo+0x260/0x5b8 [ 86.523728] reinicio_núcleo+0x78/0xf0 [ 86.524282] __do_sys_reboot+0x258/0x2f0 [ 86.524871] __arm64_sys_reboot+0x90/0xd8 [ 86.525473] invocar_syscall+0x74/0x268 [ 86.526041] el0_svc_common.constprop.0+0xb0/0x240 [ 86.526751] do_el0_svc+0x4c/0x70 [ 86.527251] el0_svc+0x4c/0xc0 [ 86.527719] el0t_64_sync_handler+0x144/0x168 [ 86.528367] el0t_64_sync+0x198/0x1a0 [ 86.528920] [ 86.529157] La dirección con errores pertenece a la página física: [ 86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc [86.531319] indicadores: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff) [86.532267] sin procesar: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000 [86.533390] sin procesar: ffff0000d46fd4d0 000000000000000 00000000ffffffff 0000000000000000 [86.534511] página volcada porque: kasan: se detectó un acceso incorrecto [ 86.535323] [ 86.535559] Estado de la memoria alrededor de la dirección con errores: [ 86.536265] ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.537314] ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.538363] >ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.544733] ^ [ 86.551057] ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.557510] ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.563928] ===================================================================== [ 86.571093] Deshabilitando la depuración de bloqueo debido a una corrupción del kernel [ 86.577642] No se puede gestionar la solicitud de paginación del kernel en la dirección virtual e0e9c0920000000b [ 86.581834] KASAN: tal vez acceso a memoria salvaje en el rango [0x0752049000000058-0x075204900000005f] ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfs: Arreglar oops en nfs_netfs_init_request() al copiar a caché Cuando netfslib quiere copiar algunos datos que acaban de leerse en nombre de nfs, crea una nueva solicitud de escritura y llama a nfs_netfs_init_request() para inicializarla, pero con un puntero de archivo NULL. Esto hace que nfs_file_open_context() dé un error; sin embargo, en realidad no necesitamos el contexto nfs ya que solo vamos a escribir en la caché. Arregla esto simplemente devolviendo si no se nos da un puntero de archivo y emitiendo una advertencia si la solicitud fue para algo distinto a copiar a caché. Además, arregla nfs_netfs_free_request() para que no intente liberar el contexto si el puntero es NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfs: Arreglar la gestión de enomem en lecturas en búfer Si netfs_read_to_pagecache() obtiene un error de ->prepare_read() o de netfs_prepare_read_iterator(), necesita decrementar ->nr_outstanding, cancelar la subsolicitud y salir del bucle de emisión. Actualmente, solo hace esto para dos de los casos, pero hay dos más que no se gestionan. Arregle esto moviendo la gestión a un lugar común y saltando a él desde los cuatro lugares. Esto es preferible a insertar un contenedor alrededor de netfs_prepare_read_iterator() como lo propuso Dmitry Antipov[1].

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs: relajar las aserciones en caso de fallo en la codificación de identificadores de archivos La codificación de identificadores de archivos normalmente se realiza mediante un método >encode_fh() del sistema de archivos que puede fallar por varias razones. Los usuarios heredados de exportfs_encode_fh(), es decir, nfsd y la llamada al sistema name_to_handle_at(2) están preparados para hacer frente a la posibilidad de un fallo en la codificación de un identificador de archivo. Hay algunos otros usuarios de exportfs_encode_{fh,fid}() que actualmente tienen una aserción WARN_ON() cuando ->encode_fh() falla. Relajen esas aserciones porque son incorrectas. El segundo informe de error vinculado indica el commit 16aac5ad1fa9 ("ovl: compatibilidad con la codificación de identificadores de archivos no decodificables") en v6.6 como el commit regresiva, pero esto no es exacto. El commit mencionado anteriormente solo aumenta las posibilidades de la aserción y permite activar la aserción con el reproductor usando overlayfs, inotify y drop_caches. Activar esta aserción siempre fue posible con otros sistemas de archivos y otras razones de fallas de ->encode_fh() y, más particularmente, también fue posible con el mismo reproductor exacto usando overlayfs que está montado con las opciones index=on,nfs_export=on también en kernels < v6.6. Por lo tanto, no estoy listando el commit mencionado anteriormente como un commit de correcciones. Sugerencia de retroportación: este parche tendrá un conflicto trivial que se aplica a v6.6.y, y otros conflictos triviales que se aplican a kernels estables < v6.6.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Agregar comprobación de granularidad en los ayudantes dml ceil/floor [Por qué] Las funciones contenedoras para dcn_bw_ceil2() y dcn_bw_floor2() deben comprobar que la granularidad no sea cero para evitar errores de aserción y división por cero en las funciones dcn_bw_. [Cómo] Agregar comprobación de granularidad 0. (seleccionada de el commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: se corrige un error de comprobación del valor de retorno faltante En smb2_send_interim_resp(), si ksmbd_alloc_work_struct() no puede asignar un nodo, devuelve un puntero NULL al puntero in_work. Esto puede provocar una escritura de memoria ilegal de in_work->response_buf cuando allocate_interim_rsp_buf() intenta realizar un kzalloc() en él. Para solucionar este problema, la incorporación de una comprobación del valor de retorno de ksmbd_alloc_work_struct() garantiza que la función regrese inmediatamente después de un error de asignación, lo que evita el acceso ilegal a la memoria mencionado anteriormente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: light: bh1745: se corrige la fuga de información en el búfer activado La estructura local 'scan' se utiliza para enviar datos al espacio del usuario desde un búfer activado, pero no establece valores para canales inactivos, ya que solo utiliza iio_for_each_active_channel() para asignar nuevos valores. Inicialice la estructura a cero antes de usarla para evitar enviar información no inicializada al espacio del usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: typec: tcpci: soluciona el problema del puntero NULL en el caso de irq compartida. La función tcpci_irq() puede encontrarse con el siguiente problema de desreferencia de puntero NULL: [2.641851] No se puede gestionar la desreferencia de puntero NULL del kernel en la dirección virtual 0000000000000010 [2.641951] estado 0x1, 0x37f [2.650659] Información de aborto de memoria: [2.656490] ESR = 0x0000000096000004 [2.660230] EC = 0x25: DABT (EL actual), IL = 32 bits [2.665532] SET = 0, FnV = 0 [2.668579] EA = 0, S1PTW = 0 [ 2.671715] FSC = 0x04: error de traducción de nivel 0 [ 2.676584] Información de cancelación de datos: [ 2.679459] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 2.684936] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 2.689980] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 2.695284] [0000000000000010] dirección de usuario pero active_mm es intercambiador [ 2.701632] Error interno: Oops: 0000000096000004 [#1] PREEMPT SMP [ 2.707883] Módulos vinculados en: [ 2.710936] CPU: 1 UID: 0 PID: 87 Comm: irq/111-2-0051 No contaminado 6.12.0-rc6-06316-g7f63786ad3d1-dirty #4 [ 2.720570] Nombre del hardware: Placa NXP i.MX93 11X11 EVK (DT) [ 2.726040] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.732989] pc : tcpci_irq+0x38/0x318 [ 2.736647] lr : _tcpci_irq+0x14/0x20 [ 2.740295] sp : ffff80008324bd30 [ 2.743597] x29: ffff80008324bd70 x28: ffff800080107894 x27: ffff800082198f70 [ 2.750721] x26: ffff0000050e6680 x25: ffff000004d172ac x24: ffff0000050f0000 [ 2.757845] x23: ffff000004d17200 x22: 0000000000000001 x21: ffff0000050f0000 [ 2.764969] x20: ffff000004d17200 x19: 0000000000000000 x18: 0000000000000001 [ 2.772093] x17: 0000000000000000 x16: ffff80008183d8a0 x15: ffff00007fbab040 [ 2.779217] x14: ffff00007fb918c0 x13: 0000000000000000 x12: 000000000000017a [ 2.786341] x11: 0000000000000001 x10: 0000000000000a90 x9 : ffff80008324bd00 [ 2.793465] x8 : ffff0000050f0af0 x7 : ffff00007fbaa840 x6 : 0000000000000031 [ 2.800589] x5 : 000000000000017a x4 : 0000000000000002 x3 : 0000000000000002 [ 2.807713] x2 : ffff80008324bd3a x1 : 00000000000000010 x0 : 0000000000000000 [ 2.814838] Rastreo de llamadas: [ 2.817273] tcpci_irq+0x38/0x318 [ 2.820583] _tcpci_irq+0x14/0x20 [ 2.823885] irq_thread_fn+0x2c/0xa8 [ 2.827456] irq_thread+0x16c/0x2f4 [ 2.830940] kthread+0x110/0x114 [ 2.834164] ret_from_fork+0x10/0x20 [ 2.837738] Código: f9426420 f9001fe0 d2800000 52800201 (f9400a60) Esto puede suceder en el caso de irq compartido. Por ejemplo, dos puertos Tipo-C comparten un irq. Después de que el primer puerto terminó tcpci_register_port(), puede activar la interrupción. Sin embargo, si la interrupción llega por casualidad, el segundo puerto termina devm_request_threaded_irq(), el controlador de interrupción del segundo puerto se ejecutará primero. Entonces, el problema anterior ocurre debido a que tcpci sigue siendo un puntero NULL en tcpci_irq() cuando se desreferencia a regmap. devm_request_threaded_irq() <-- port1 irq viene deshabilitar_irq(client->irq); tcpci_register_port() Esto restaurará la lógica al estado anterior a el commit (77e85107a771 "usb: typec: tcpci: support edge irq"). Sin embargo, mover tcpci_register_port() antes crea un problema cuando se usa el irq de borde porque tcpci_init() se llamará antes que devm_request_threaded_irq(). tcpci_init() escribe ALERT_MASK en el hardware para indicarle que comience a generar interrupciones, pero aún no estamos listos para lidiar con ellas, entonces los eventos ALERT pueden perderse y la línea ALERT no se recuperará al nivel alto para siempre. Para evitar el problema, esto también establecerá el registro ALERT_MASK después del retorno de devm_request_threaded_irq().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: u_serial: Deshabilitar ep antes de configurar el puerto como nulo para corregir el bloqueo causado por el puerto nulo Teniendo en cuenta que en algunos casos extremos, al realizar la operación de desvinculación, gserial_disconnect ha borrado gser->ioport, lo que desencadena la reconfiguración del gadget y luego llama a gs_read_complete, lo que da como resultado el acceso a un puntero nulo. Por lo tanto, ep se deshabilita antes de que gserial_disconnect configure el puerto como nulo para evitar que esto suceda. Rastreo de llamadas: gs_read_complete+0x58/0x240 usb_gadget_giveback_request+0x40/0x160 dwc3_remove_requests+0x170/0x484 dwc3_ep0_out_start+0xb0/0x1d4 __dwc3_gadget_start+0x25c/0x720 kretprobe_trampoline.cfi_jt+0x0/0x8 kretprobe_trampoline.cfi_jt+0x0/0x8 udc_bind_to_driver+0x1d8/0x300 usb_gadget_probe_driver+0xa8/0x1dc gadget_dev_desc_UDC_store+0x13c/0x188 configfs_write_iter+0x160/0x1f4 vfs_write+0x2d0/0x40c ksys_write+0x7c/0xf0 __arm64_sys_write+0x20/0x30 invocar_llamada_al_sistema+0x60/0x150 el0_svc_common+0x8c/0xf8 do_el0_svc+0x28/0xa0 el0_svc+0x24/0x84

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: se corrige el error de página debido a la falta de coincidencia de la definición de superficie máxima. El controlador DC está usando dos valores diferentes para definir la cantidad máxima de superficies: MAX_SURFACES y MAX_SURFACE_NUM. Se consolida MAX_SURFACES como la definición única para las actualizaciones de superficie en DC. Corrige el error de página que enfrentan los usuarios de Cosmic en las versiones de pantalla AMD que admiten dos planos de superposición, desde la introducción del modo de superposición del cursor. [26 nov 21:33] ERROR: no se puede gestionar el error de página para la dirección: 0000000051d0f08b [ +0.000015] #PF: acceso de lectura del supervisor en modo kernel [ +0.000006] #PF: error_code(0x0000) - página no presente [ +0.000005] PGD 0 P4D 0 [ +0.000007] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000006] CPU: 4 PID: 71 Comm: kworker/u32:6 No contaminado 6.10.0+ #300 [ +0.000006] Nombre del hardware: Valve Jupiter/Jupiter, BIOS F7A0131 30/01/2024 [ +0.000007] Cola de trabajo: eventos_sin_enlace_confirmación_trabajo [drm_kms_helper] [ +0.000040] RIP: 0010:copiar_actualización_de_flujo_a_flujo.isra.0+0x30d/0x750 [amdgpu] [ +0.000847] Código: 8b 10 49 89 94 24 f8 00 00 00 48 8b 50 08 49 89 94 24 00 01 00 00 8b 40 10 41 89 84 24 08 01 00 00 49 8b 45 78 48 85 c0 74 0b <0f> b6 00 41 88 84 24 90 64 00 00 49 8b 45 60 48 85 c0 74 3b 48 8b [ +0.000010] RSP: 0018:ffffc203802f79a0 EFLAGS: 00010206 [ +0.000009] RAX: 0000000051d0f08b RBX: 0000000000000004 RCX: ffff9f964f0a8070 [ +0.000004] RDX: ffff9f9710f90e40 RSI: ffff9f96600c8000 RDI: ffff9f964f000000 [ +0.000004] RBP: ffffc203802f79f8 R08: 0000000000000000 R09: 0000000000000000 [ +0.000005] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9f96600c8000 [ +0.000004] R13: ffff9f9710f90e40 R14: ffff9f964f000000 R15: ffff9f96600c8000 [ +0.000004] FS: 000000000000000(0000) GS:ffff9f9970000000(0000) knlGS:0000000000000000 [ +0.000005] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000005] CR2: 0000000051d0f08b CR3: 00000002e6a20000 CR4: 0000000000350ef0 [ +0.000005] Rastreo de llamadas: [ +0.000011] [ +0.000010] ? __die_body.cold+0x19/0x27 [ +0.000012] ? exc_page_fault_oops+0x15a/0x2d0 [ +0.000014] ? exc_page_fault+0x7e/0x180 [ +0.000009] ? asm_exc_page_fault+0x26/0x30 [ +0.000013] ? copia_actualización_de_flujo_a_flujo.isra.0+0x30d/0x750 [amdgpu] [ +0.000739] ? estado_de_confirmación_dc_sin_verificación+0xd6c/0xe70 [amdgpu] [ +0.000470] actualización_de_planos_y_estado_de_flujo+0x49b/0x4f0 [amdgpu] [ +0.000450] ? srso_return_thunk+0x5/0x5f [ +0.000009] ? estado_transición_mínimo_confirmación+0x239/0x3d0 [amdgpu] [ +0.000446] planos_actualización_y_flujo_v2+0x24a/0x590 [amdgpu] [ +0.000464] ? srso_return_thunk+0x5/0x5f [ +0.000009] ? sort+0x31/0x50 [ +0.000007] ? amdgpu_dm_atomic_commit_tail+0x159f/0x3a30 [amdgpu] [ +0.000508] ? srso_return_thunk+0x5/0x5f [ +0.000009] ? amdgpu_crtc_get_scanout_position+0x28/0x40 [amdgpu] [ +0.000377] ? srso_return_thunk+0x5/0x5f [ +0.000009] ? drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x160/0x390 [drm] [ +0.000058] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? dma_fence_default_wait+0x8c/0x260 [ +0.000010] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? tiempo_espera_finalización+0x13b/0x170 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000005] ? tiempo_espera_finalización+0x108/0x140 [ +0.000010] ? cola_commit+0x94/0x130 [drm_kms_helper] [ +0.000024] ? proceso_una_obra+0x177/0x330 [ +0.000008] ? subproceso_trabajador+0x266/0x3a0 [ +0.000006] ? __pfx_worker_thread+0x10/0x10 [ +0.000004] ? kthread+0xd2/0x100 [ +0.000006] ? __pfx_kthread+0x10/0x10 [ +0.000006] ? ret_from_fork+0x34/0x50 [ +0.000004] ? __pfx_kthread+0x10/0x10 [ +0.000005] ? ret_from_fork_asm+0x1a/0x30 [ +0.000011] (seleccionado de el commit 1c86c81a86c60f9b15d3e3f43af0363cf56063e7)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: light: vcnl4035: corrige la fuga de información en el búfer activado La matriz local 'buffer' se utiliza para enviar datos al espacio de usuario desde un búfer activado, pero no establece un valor inicial para el elemento de datos único, que es un u16 alineado a 8 bytes. Eso deja al menos 4 bytes sin inicializar incluso después de escribir un valor entero con regmap_read(). Inicialice la matriz a cero antes de usarla para evitar enviar información no inicializada al espacio de usuario.