Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: dummy: iio_simply_dummy_buffer: corrige la fuga de información en el búfer activado La matriz 'data' se asigna a través de kmalloc() y 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. Utilice kzalloc para la asignación de memoria para evitar enviar información no inicializada al espacio del usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: pressure: zpa2326: fix information leak in triggered buffer La estructura local 'sample' se usa para enviar datos al espacio de usuario desde un búfer activado, pero tiene un agujero entre la temperatura y la marca de tiempo (presión u32, temperatura u16, GAP, marca de tiempo u64). Este agujero nunca se inicializa. Inicialice la estructura a cero antes de usarla para evitar enviar información no inicializada al espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: f_fs: eliminar WARN_ON en functionfs_bind Esta confirmación soluciona un problema relacionado con el pánico del kernel que se muestra a continuación, donde panic_on_warn está habilitado. Es causado por el uso innecesario de WARN_ON en functionsfs_bind, lo que fácilmente conduce a los siguientes escenarios. 1.adb_write en adbd 2. Escritura de UDC a través de configfs ================= ====================== ->usb_ffs_open_thread() ->Escritura de UDC ->open_functionfs() ->configfs_write_iter() ->adb_open() ->gadget_dev_desc_UDC_store() ->adb_write() ->usb_gadget_register_driver_owner ->driver_register() ->StartMonitor() ->bus_add_driver() ->adb_read() ->gadget_bind_driver() ->configfs_composite_bind() ->usb_add_function() ->open_functionfs() ->ffs_func_bind() ->adb_open() ->functionfs_bind() state !=FFS_ACTIVE> Las operaciones adb_open, adb_read y adb_write se invocan desde el daemon, pero intentar vincular la función es un proceso que se invoca mediante escritura UDC a través de configfs, lo que abre la posibilidad de una condición de ejecución entre las dos rutas. En este escenario de ejecución, el pánico del kernel se produce debido al WARN_ON de functionfs_bind cuando panic_on_warn está habilitado. Esta confirmación corrige el pánico del kernel eliminando el WARN_ON innecesario. Pánico del núcleo: no se sincroniza: núcleo: panic_on_warn establecido ... [ 14.542395] Seguimiento de llamadas: [ 14.542464] ffs_func_bind+0x1c8/0x14a8 [ 14.542468] usb_add_function+0xcc/0x1f0 [ 14.542473] configfs_composite_bind+0x468/0x588 [ 14.542478] gadget_bind_driver+0x108/0x27c [ 14.542483] really_probe+0x190/0x374 [ 14.542488] __driver_probe_device+0xa0/0x12c [ 14.542492] controlador_probe_device+0x3c/0x220 [ 14.542498] __driver_attach+0x11c/0x1fc [ 14.542502] bus_for_each_dev+0x104/0x160 [ 14.542506] controlador_attach+0x24/0x34 [ 14.542510] bus_add_driver+0x154/0x270 [ 14.542514] controlador_register+0x68/0x104 [ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4 [ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144 [ 14.542526] configfs_write_iter+0xf0/0x138

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: microchip: pci1xxxx: Resuelve el pánico del kernel durante la gestión de IRQ GPIO Resuelve el pánico del kernel causado por la gestión incorrecta de IRQ mientras se accede a valores GPIO. Esto se hace reemplazando generic_handle_irq con handle_nested_irq.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: topología: mantener la cpumask sin cambios al imprimir cpumap Durante las pruebas fuzz, se descubrió la siguiente advertencia: diferentes valores de retorno (15 y 11) de vsnprintf("%*pbl ", ...) test:keyward es WARNING en kvasprintf WARNING: CPU: 55 PID: 1168477 en lib/kasprintf.c:30 kvasprintf+0x121/0x130 Seguimiento de llamadas: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmap_print_to_buf+0x89/0x100 core_siblings_list_read+0x7e/0xb0 kernfs_file_read_iter+0x15b/0x270 new_sync_read+0x153/0x260 vfs_read+0x215/0x290 ksys_read+0xb9/0x160 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2 El seguimiento de la llamada muestra que kvasprintf() informó esta advertencia durante la impresión de core_siblings_list. kvasprintf() tiene varios pasos: (1) Primero, calcule la longitud de la cadena formateada resultante. (2) Asignar un búfer en función de la longitud devuelta. (3) Luego, realice el formateo de la cadena real. (4) Verifique si las longitudes de las cadenas formateadas devueltas en los pasos (1) y (2) son consistentes. Si se modifica core_cpumask entre los pasos (1) y (3), las longitudes obtenidas en estos dos pasos pueden no coincidir. De hecho, nuestra prueba incluye la conexión en caliente de la CPU, que debería modificar core_cpumask durante la impresión. Para solucionar este problema, almacene en caché cpumask en una variable temporal antes de llamar a cpumap_print_{list, cpumask}_to_buf(), para mantenerla sin cambios durante el proceso de impresión.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: ti-ads1119: se corrige la fuga de información en el búfer activado La estructura local 'scan' se usa para enviar datos al espacio de usuario desde un búfer activado, pero tiene un agujero entre la muestra (unsigned int) y la marca de tiempo. Este agujero nunca se inicializa. Inicialice la estructura a cero antes de usarla para evitar enviar información no inicializada al espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: ti-ads8688: se 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 valores para canales inactivos, ya que solo utiliza iio_for_each_active_channel() para asignar nuevos valores. Inicialice la matriz a cero antes de usarla para evitar enviar información no inicializada al espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: adc: rockchip_saradc: corrige pérdida de información en búfer activado La estructura local 'data' se usa para enviar datos al espacio de usuario desde un búfer activado, pero no establece valores para canales inactivos, ya que solo usa 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 de usuario.