Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: agregar descriptores de acceso para leer/establecer tp->snd_cwnd Tuvimos varios errores a lo largo de los años con código que rompía la suposición de que tp->snd_cwnd es mayor que cero. Últimamente, syzbot informó que se puede activar WARN_ON_ONCE(!tp->prior_cwnd) agregado en el commit 8b8a321ff72c ("tcp: corregir cwnd cero en tcp_cwnd_reduction"), y sin una reproducción tendríamos que dedicar un tiempo considerable a encontrar el error. En lugar de quejarnos demasiado tarde, queremos detectar dónde y cuándo tp->snd_cwnd se establece en un valor ilegal.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd syzbot recibió un nuevo informe [1] que finalmente apunta a un error muy antiguo, agregado en el soporte inicial para el sondeo de MTU. tcp_mtu_probe() tiene comprobaciones sobre el inicio de un sondeo de MTU si tcp_snd_cwnd(tp) >= 11. Pero nada impide que tcp_snd_cwnd(tp) se reduzca más tarde y antes de que el sondeo de MTU tenga éxito. Este error conduciría a posibles divisiones por cero. La depuración agregada en el commit 40570375356c ("tcp: add accessors to read/set tp->snd_cwnd") ha valido la pena :) Mientras estamos en ello, aborde los posibles desbordamientos en este código. [1] ADVERTENCIA: CPU: 1 PID: 14132 en include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712 Módulos vinculados en: CPU: 1 PID: 14132 Comm: syz-executor.2 No contaminado 5.18.0-syzkaller-07857-gbabf0bb978e3 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [en línea] RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712 Código: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287 RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000 RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520 R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50 R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000 FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356 tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861 tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973 tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476 sk_backlog_rcv include/net/sock.h:1061 [en línea] __release_sock+0x1d8/0x4c0 net/core/sock.c:2849 release_sock+0x5d/0x1c0 net/core/sock.c:3404 sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145 tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410 tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448 sock_sendmsg_nosec net/socket.c:714 [en línea] sock_sendmsg net/socket.c:734 [en línea] __sys_sendto+0x439/0x5c0 net/socket.c:2119 __do_sys_sendto net/socket.c:2131 [en línea] __se_sys_sendto net/socket.c:2127 [en línea] __x64_sys_sendto+0xda/0xf0 net/socket.c:2127 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entrada_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f6431289109 Código: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109 RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 00000000000000246 R12: 0000000000000000 R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drivers: staging: rtl8192e: Corregir bloqueo en rtllib_beacons_stop() Hay un bloqueo en rtllib_beacons_stop(), que se muestra a continuación: (Hilo 1) | (Hilo 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (esperar un tiempo) ... | rtllib_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (esperar 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, rtllib_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: 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: 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: 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: drivers: usb: host: Corregir interbloqueo en oxu_bus_suspend() Hay un interbloqueo en oxu_bus_suspend(), que se muestra a continuación: (Hilo 1) | (Hilo 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (esperar un tiempo) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (esperar a que el temporizador se detenga) | ... Mantenemos oxu->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 oxu->lock en la posición (2) del hilo 2. Como resultado, oxu_bus_suspend() se bloqueará para siempre. Este parche extrae del_timer_sync() de la protección de spin_lock_irq(), 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: tty: corrige una posible pérdida de recursos en icom_probe Cuando pci_read_config_dword falla, llama a pci_release_regions() y pci_disable_device() para reciclar el recurso previamente asignado.

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: 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: staging: rtl8712: corrige una posible pérdida de memoria en r871xu_drv_init() En r871xu_drv_init(), si r8712_init_drv_sw() falla, entonces la memoria asignada por r8712_alloc_io_queue() en r8712_usb_dvobj_init() no se libera correctamente ya que r8712_usb_dvobj_deinit() no realizará ninguna acción. Para liberarla correctamente, debemos llamar a r8712_free_io_queue() en r8712_usb_dvobj_deinit(). Además, en r871xu_dev_remove(), r8712_usb_dvobj_deinit() será llamado por r871x_dev_unload() bajo la condición `padapter->bup` y r8712_free_io_queue() será llamado por r8712_free_drv_sw(). Sin embargo, r8712_usb_dvobj_deinit() no depende de `padapter->bup` y llamar a r8712_free_io_queue() en r8712_free_drv_sw() es negativo para una mejor comprensión del código. Entonces muevo r8712_usb_dvobj_deinit() a r871xu_dev_remove() y elimino r8712_free_io_queue() de r8712_free_drv_sw().