Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSv4: No mantenga los bloqueos layoutget en múltiples llamadas RPC Al realizar layoutget como parte del compuesto open(), debemos tener cuidado de liberar los bloqueos layout antes de poder realizar más llamadas RPC, como setattr(). La razón es que esas llamadas podrían activar una recuperación, lo que podría generar un bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: evitar bucle infinito para vaciar páginas de nodos xfstests/generic/475 puede dar EIO todo el tiempo, lo que da un bucle infinito para vaciar la página de nodos como se muestra a continuación. Vamos a evitarlo. [16418.518551] Seguimiento de llamadas: [16418.518553] ? dm_submit_bio+0x48/0x400 [16418.518574] ? submit_bio_checks+0x1ac/0x5a0 [16418.525207] __submit_bio+0x1a9/0x230 [16418.525210] ? kmem_cache_alloc+0x29e/0x3c0 [16418.525223] submit_bio_noacct+0xa8/0x2b0 [16418.525226] submit_bio+0x4d/0x130 [16418.525238] __submit_bio+0x49/0x310 [f2fs] [16418.525339] ? bio_add_page+0x6a/0x90 [16418.525344] f2fs_submit_page_bio+0x134/0x1f0 [f2fs] [16418.525365] read_node_page+0x125/0x1b0 [f2fs] [16418.525388] __get_node_page.part.0+0x58/0x3f0 [f2fs] [16418.525409] __get_node_page+0x2f/0x60 [f2fs] [16418.525431] f2fs_get_dnode_of_data+0x423/0x860 [f2fs] [16418.525452] ? asm_sysvec_apic_timer_interrupt+0x12/0x20 [16418.525458] ? __mod_memcg_state.part.0+0x2a/0x30 [16418.525465] ? __mod_memcg_lruvec_state+0x27/0x40 [16418.525467] ? __xa_set_mark+0x57/0x70 [16418.525472] f2fs_do_write_data_page+0x10e/0x7b0 [f2fs] [16418.525493] f2fs_write_single_data_page+0x555/0x830 [f2fs] [16418.525514] ? sysvec_apic_timer_interrupt+0x4e/0x90 [16418.525518] ? asm_sysvec_apic_timer_interrupt+0x12/0x20 [16418.525523] f2fs_write_cache_pages+0x303/0x880 [f2fs] [16418.525545] ? blk_flush_plug_list+0x47/0x100 [16418.525548] f2fs_write_data_pages+0xfd/0x320 [f2fs] [16418.525569] do_writepages+0xd5/0x210 [16418.525648] filemap_fdatawrite_wbc+0x7d/0xc0 [16418.525655] filemap_fdatawrite+0x50/0x70 [16418.525658] f2fs_sync_dirty_inodes+0xa4/0x230 [f2fs] [16418.525679] f2fs_write_checkpoint+0x16d/0x1720 [f2fs] [16418.525699] ? ttwu_do_wakeup+0x1c/0x160 [16418.525709] ? ttwu_do_activate+0x6d/0xd0 [16418.525711] ? __wait_for_common+0x11d/0x150 [16418.525715] kill_f2fs_super+0xca/0x100 [f2fs] [16418.525733] deactivate_locked_super+0x3b/0xb0 [16418.525739] deactivate_super+0x40/0x50 [16418.525741] cleanup_mnt+0x139/0x190 [16418.525747] __cleanup_mnt+0x12/0x20 [16418.525749] task_work_run+0x6d/0xa0 [16418.525765] exit_to_user_mode_prepare+0x1ad/0x1b0 [16418.525771] syscall_exit_to_user_mode+0x27/0x50 [16418.525774] do_syscall_64+0x48/0xc0 [16418.525776] entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: eliminar WARN_ON en f2fs_is_valid_blkaddr Syzbot activa dos WARN en f2fs_is_valid_blkaddr y __is_bitmap_valid. Por ejemplo, en f2fs_is_valid_blkaddr, si el tipo es DATA_GENERIC_ENHANCE o DATA_GENERIC_ENHANCE_READ, invoca WARN_ON si blkaddr no está en el rango correcto. El seguimiento de la llamada es el siguiente: f2fs_get_node_info+0x45f/0x1070 read_node_page+0x577/0x1190 __get_node_page.part.0+0x9e/0x10e0 __get_node_page f2fs_get_node_page+0x109/0x180 do_read_inode f2fs_iget+0x2a5/0x58b0 f2fs_fill_super+0x3b39/0x7ca0 Corrija estas dos ADVERTENCIAS reemplazando WARN_ON con dump_stack.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/arm-smmu-v3: verificar el valor de retorno después de llamar a platform_get_resource() Causará null-ptr-deref si platform_get_resource() devuelve NULL, necesitamos verificar el valor de retorno.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dmaengine: zynqmp_dma: En el tipo de datos fix desc_size de struct zynqmp_dma_chan En las funciones zynqmp_dma_alloc/free_chan_resources hay un desbordamiento potencial en las siguientes expresiones. dma_alloc_coherent(chan->dev, (2 * chan->desc_size * ZYNQMP_DMA_NUM_DESCS), &chan->desc_pool_p, GFP_KERNEL); dma_free_coherent(chan->dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) * ZYNQMP_DMA_NUM_DESCS), chan->desc_pool_v, chan->desc_pool_p); Los argumentos desc_size y ZYNQMP_DMA_NUM_DESCS eran de 32 bits. Aunque esta condición de desbordamiento no se observa, es un problema potencial en el caso de la multiplicación de 32 bits. Por lo tanto, corríjala cambiando el tipo de datos desc_size a size_t. Además de corregir la cobertura, también reutilice la macro ZYNQMP_DMA_DESC_SIZE en el argumento de API dma_alloc_coherent. Direcciones: cobertura: evento overflow_before_widen.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xprtrdma: trata todas las llamadas como no bcall cuando bc_serv es NULL Cuando un servidor rdma devuelve una respuesta en formato de error, el cliente nfs v3 puede tratarla como una bcall cuando el servicio bc no existe. El mensaje de depuración en rpcrdma_bc_receive_call es, [56579.837169] RPC: rpcrdma_bc_receive_call: callback XID 00000001, length=20 [56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 Después de eso, rpcrdma_bc_receive_call encontrará un puntero NULL como, [ 226.057890] ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en 00000000000000c8 ... [ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20 ... [ 226.059732] Call Trace: [ 226.059878] rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma] [ 226.060011] __ib_process_cq+0x89/0x170 [ib_core] [ 226.060092] ib_cq_poll_work+0x26/0x80 [ib_core] [ 226.060257] process_one_work+0x1a7/0x360 [ 226.060367] ? create_worker+0x1a0/0x1a0 [ 226.060440] worker_thread+0x30/0x390 [ 226.060500] ? create_worker+0x1a0/0x1a0 [ 226.060574] kthread+0x116/0x130 [ 226.060661] ? kthread_flush_work_fn+0x10/0x10 [ 226.060724] ret_from_fork+0x35/0x40 ...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: host: isp116x: verificar el valor de retorno después de llamar a platform_get_resource() Causará null-ptr-deref si platform_get_resource() devuelve NULL, necesitamos verificar el valor de retorno.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: staging: rtl8192eu: Corregir bloqueo en rtw_joinbss_event_prehandle Hay un bloqueo en rtw_joinbss_event_prehandle(), que se muestra a continuación: (Hilo 1) | (Hilo 2) | _set_timer() rtw_joinbss_event_prehandle()| mod_timer() spin_lock_bh() //(1) | (esperar un tiempo) ... | rtw_join_timeout_handler() | _rtw_join_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (esperar a que el temporizador se detenga) | ... Mantenemos pmlmepriv->lock en la posición (1) del hilo 1 y usamos del_timer_sync() para esperar a que el temporizador se detenga, pero el controlador del temporizador también necesita pmlmepriv->lock en la posición (2) del hilo 2. Como resultado, rtw_joinbss_event_prehandle() se bloqueará para siempre. Este parche extrae del_timer_sync() de la protección de spin_lock_bh(), lo que podría permitir que el controlador del temporizador obtenga el bloqueo necesario. Además, cambiamos spin_lock_bh() por spin_lock_irq() en _rtw_join_timeout_handler() para evitar el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: tty: serial: Arreglar interbloqueo en sa1100_set_termios() Hay un interbloqueo en sa1100_set_termios(), que se muestra a continuación: (Hilo 1) | (Hilo 2) | sa1100_enable_ms() sa1100_set_termios() | mod_timer() spin_lock_irqsave() //(1) | (esperar un tiempo) ... | sa1100_timeout() del_timer_sync() | spin_lock_irqsave() //(2) (esperar a que el temporizador se detenga) | ... Mantenemos sport->port.lock en la posición (1) del hilo 1 y usamos del_timer_sync() para esperar a que el temporizador se detenga, pero el controlador del temporizador también necesita sport->port.lock en la posición (2) del hilo 2. Como resultado, sa1100_set_termios() se bloqueará para siempre. Este parche mueve del_timer_sync() antes de spin_lock_irqsave() para evitar el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: staging: rtl8192u: Corregir bloqueo en ieee80211_beacons_stop() Hay un bloqueo en ieee80211_beacons_stop(), que se muestra a continuación: (Hilo 1) | (Hilo 2) | ieee80211_send_beacon() ieee80211_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (esperar un tiempo) ... | ieee80211_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (esperar a que el temporizador se detenga) | ... Mantenemos ieee->beacon_lock en la posición (1) del hilo 1 y usamos del_timer_sync() para esperar a que el temporizador se detenga, pero el controlador del temporizador también necesita ieee->beacon_lock en la posición (2) del hilo 2. Como resultado, ieee80211_beacons_stop() se bloqueará para siempre. Este parche extrae del_timer_sync() de la protección de spin_lock_irqsave(), lo que podría permitir que el controlador del temporizador obtenga el bloqueo necesario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: host: Detener la configuración del compañero ACPI Ya no es necesario. El puntero sysdev ahora se utiliza al asignar los compañeros ACPI a los puertos xHCI y dispositivos USB. Asignar el compañero ACPI aquí resultó en que el puntero fwnode->secondary también se reemplazara para el dispositivo dwc3 principal ya que el fwnode primario (el compañero ACPI) se compartía. Eso no fue intencional y creó posibles efectos secundarios como fugas de recursos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: synclink_gt: Fix null-pointer-dereference in slgt_clean() Cuando el controlador falla en alloc_hdlcdev() y luego eliminamos el módulo del controlador, obtendremos el siguiente splat: [ 25.065966] error de protección general, probablemente para la dirección no canónica 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI [ 25.066914] KASAN: null-ptr-deref en el rango [0x000000000000c10-0x0000000000000c17] [ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0 [ 25.077709] Seguimiento de llamadas: [ 25.077924] [ 25.078108] unregister_hdlc_device+0x16/0x30 [ 25.078481] slgt_cleanup+0x157/0x9f0 [synclink_gt] Solucione esto comprobando primero si 'info->netdev' es un puntero nulo.