Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: wilc1000: use vmm_table como matriz en wilc struct. Al habilitar KASAN y ejecutar algunas pruebas de iperf se generan algunos problemas de memoria con vmm_table: BUG: KASAN: slab-out-of-bounds en wilc_wlan_handle_txq +0x6ac/0xdb4 Escritura de tamaño 4 en la dirección c3a61540 mediante la tarea wlan0-tx/95 KASAN detecta que estamos escribiendo datos más allá del rango asignado a vmm_table. De hecho, existe una discrepancia entre el tamaño pasado al asignador en wilc_wlan_init y el rango de posibles índices utilizados más adelante: al tamaño de la asignación le falta una multiplicación por sizeof(u32)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: corrige slab-use-after-free en gfs2_qd_dealloc. En gfs2_put_super(), ya sea retirada o no, gfs2_quota_cleanup() debe limpiar la cuota. De lo contrario, la estructura gfs2_sbd se liberará antes de que se ejecute gfs2_qd_dealloc (devolución de llamada de rcu) para todos los objetos gfs2_quota_data, lo que dará como resultado un use after free. Además, gfs2_destroy_threads() y gfs2_quota_cleanup() ya son llamados por gfs2_make_fs_ro(), por lo que en gfs2_put_super(), después de llamar a gfs2_make_fs_ro(), no es necesario volver a llamarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: client: corrige un posible punto muerto al liberar mids. Todos los llamadores de release_mid() parecen tener una referencia de @mid, por lo que no hay necesidad de llamar a kref_put(&mid->refcount, __release_mid ) en @servidor->mid_lock spinlock. Si no lo hacen, de todos modos se habría producido un error de use after free. Al deshacerse de dicho bloqueo de giro, también se soluciona un posible punto muerto como se muestra a continuación CPU 0 CPU 1 -------------------------------- ---------------------------------- cifs_demultiplex_thread() cifs_debug_data_proc_show() release_mid() spin_lock(&servidor->mid_lock) ; spin_lock(&cifs_tcp_ses_lock) spin_lock(&servidor->mid_lock) __release_mid() smb2_find_smb_tcon() spin_lock(&cifs_tcp_ses_lock) *punto muerto*

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: corrige el use after free en rdata->read_into_pages(). Cuando el estado de la red es inestable, puede ocurrir el use after free al leer datos del servidor. BUG: KASAN: use after free en readpages_fill_pages+0x14c/0x7e0 Seguimiento de llamadas: dump_stack_lvl+0x38/0x4c print_report+0x16f/0x4a6 kasan_report+0xb7/0x130 readpages_fill_pages+0x14c/0x7e0 cifs_readv_receive+0x 46d/0xa40 cifs_demultiplex_thread+0x121c/ 0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 Asignado por tarea 2535: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x82/0x90 cifs_readdata_direct_alloc+0x2c /0x110 cifs_readdata_alloc+0x2d/0x60 cifs_readahead+0x393/0xfe0 read_pages+0x12f/0x470 page_cache_ra_unbounded+0x1b1/0x240 filemap_get_pages+0x1c8/0x9a0 filemap_read+0x1c0/0x540 cifs_strict_readv+0x21b/0x240 vfs_read+0x395/0x4b0 ksys_read+0xb8/0 x150 do_syscall_64+0x3f/0x90 Entry_SYSCALL_64_after_hwframe+0x72/0xdc Liberado por la tarea 79: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2e/0x50 __kasan_slab_free+0x10e/0x1a0 __kmem_cache_free+0x7a/0x1a0 cifs_readdata_release+0x49/0x60 Process_one_work+0x46c /0x760 worker_thread+0x2a4/0x6f0 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 Última creación de trabajo potencialmente relacionado: kasan_save_stack+0x22/0x50 __kasan_record_aux_stack+0x95/0xb0 insert_work+0x2b/0x130 __queue_work+0x1fe/0x660 queue_work_on+0x4b/0x60 smb2_readv_callback+0x396/0x800 ion+0x474/0x6a0 cifs_reconnect+0x5cb/0xa50 cifs_readv_from_socket.cold+ 0x22/0x6c cifs_read_page_from_socket+0xc1/0x100 readpages_fill_pages.cold+0x2f/0x46 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 x2c/0x50 Las siguientes llamadas a funciones causarán UAF del puntero rdata. readpages_fill_pages cifs_read_page_from_socket cifs_readv_from_socket cifs_reconnect __cifs_reconnect cifs_abort_connection mid->callback() --> smb2_readv_callback queue_work(&rdata->work) # si el trabajador completa primero, # los rdata se liberan cifs_readv_complete kref_put cifs_readdata_release kfree( rdata) devolver rdata->... # UAF en readpages_fill_pages() De manera similar, este problema también ocurre en uncache_fill_pages(). Solucione este problema ajustando el orden del juicio de condición en la declaración de devolución.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: USB: corrija la dirección incorrecta ADVERTENCIA en plusb.c. El syzbot fuzzer detectó un error en el controlador de red plusb: una transferencia de control de salida de longitud cero se trató como una lectura en lugar de escribir. En los kernels modernos, este error provoca una ADVERTENCIA: usb 1-1: directorio de control BOGUS, la tubería 80000280 no coincide con bRequestType c0 ADVERTENCIA: CPU: 0 PID: 4645 en drivers/usb/core/urb.c:411 usb_submit_urb+0x14a7/ 0x1880 drivers/usb/core/urb.c:411 Módulos vinculados en: CPU: 1 PID: 4645 Comm: dhcpcd Not tainted 6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Motor, BIOS Google 12/01/2023 RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411... Seguimiento de llamadas: usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message .c:58 controladores usb_internal_control_msg/usb/core/message.c:102 [en línea] usb_control_msg+0x320/0x4a0 controladores/usb/core/message.c:153 __usbnet_read_cmd+0xb9/0x390 controladores/net/usb/usbnet.c: 2010 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068 pl_vendor_req drivers/net/usb/plusb.c:60 [en línea] pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [en línea] pl_reset+0x2f /0xf0 drivers/net/usb/plusb.c:85 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889 __dev_open+0x297/0x4d0 net/core/dev.c:1417 __dev_change_flags+0x587/0x750 net/ core/dev.c:8530 dev_change_flags+0x97/0x170 net/core/dev.c:8602 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979 sock_do_ioctl +0xcc/0x230 net/socket.c:1169 sock_ioctl+0x1f8/0x680 net/socket.c:1286 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:870 [en línea] __se_sys_ioctl fs/ioctl. c:856 [en línea] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_h marco w +0x63/0xcd La solución es llamar a usbnet_write_cmd() en lugar de usbnet_read_cmd() y eliminar el indicador USB_DIR_IN.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: no utilice el indicador WQ_MEM_RECLAIM para la cola de trabajo. Cuando se cargan ice y el controlador irdma, se activa una advertencia en check_flush_dependency. Esto se debe a que la cola de trabajo del controlador de hielo está asignada con el indicador WQ_MEM_RECLAIM y el de irdma no. Según la documentación del kernel, este indicador debe establecerse si la cola de trabajo participará en el flujo de recuperación de memoria del kernel. Como no es así, no es necesario que el WQ del conductor de hielo tenga esta bandera configurada, así que elimínela. Seguimiento de ejemplo: [+0.000004] cola de trabajo: WQ_MEM_RECLAIM ice:ice_service_task [ice] se está vaciando! WQ_MEM_RECLAIM infiniband:0x0 [+0.000139] ADVERTENCIA: CPU: 0 PID: 728 en kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0 [ + 0.000011] Módulos vinculados en: vinculación tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc fkill vfat fat intel_rapl_msr intel _rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1 0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc ucm ib_srpt ib_isert iscsi_target_mod target_ core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse [+0.000161] [última descarga: unión] [+0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Contaminado: GS 6.2.0-rc2_next-queue-13jan-0045 8- gc20aabd57164 #1 [ +0.000006] Nombre del hardware: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 06/01/2020 [ +0.000003] Cola de trabajo: ice ice_service_task [ice] [ +0.00 0127] RIP: 0010:check_flush_dependency+ 0x178/0x1a0 [ +0.000005] Código: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08 9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06 [ +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282 [ +0.000005] RAX: 000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000 [ +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80 [ +0.000003] RBP: ffff888194bf3400 R08: fffffed117b306112 R09: 306112 [ +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000 [ +0.000003] R13: ffff888111f84d00 R14: 15 : ffff888194bf3400 [ +0.000004] FS: 0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:00000000000000000 [ +0.000003] CS: 0010 DS: 0000 0000 CR0: 0000000080050033 [+0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0 [ +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000003] DR3: 00000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000002] PKRU: 55555554 [ +0.000003] Seguimiento de llamadas: [ +0.000002] [ +0.000003 ] __flush_workqueue+0x203/0x840 [ +0.000006] ? mutex_unlock+0x84/0xd0 [+0.000008]? __pfx_mutex_unlock+0x10/0x10 [+0.000004]? __pfx___flush_workqueue+0x10/0x10 [+0.000006]? mutex_lock+0xa3/0xf0 [ +0.000005] ib_cache_cleanup_one+0x39/0x190 [ib_core] [ +0.000174] __ib_unregister_device+0x84/0xf0 [ib_core] [ +0.000094] ib_unregister_device+0x25/0x30 [ib_core] [ + 0.000093] irdma_ib_unregister_device+0x97/0xc0 [irdma] [ +0.000064] ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma] [ +0.000059] ? up_write+0x5c/0x90 [ +0.000005] irdma_remove+0x36/0x90 [irdma] [ +0.000062] auxiliar_bus_remove+0x32/0x50 [ +0.000007] dispositivo_r ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/irdma: se corrige una posible referencia NULL-ptr-dereference in_dev_get() que puede devolver NULL, lo que provocará una falla una vez que se elimine la referencia a idev en in_dev_for_each_ifa_rtnl(). Este parche agrega una verificación previa del valor NULL en idev. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: IB/IPoIB: corrige el IPoIB heredado debido a un número incorrecto de colas. La confirmación citada crea interfaces PKEY secundarias a través de netlink y tendrá múltiples colas de transmisión y recepción, pero algunos dispositivos no admiten más de Colas 1 tx y 1 rx. Esto provoca un bloqueo cuando el tráfico se envía a través de la interfaz PKEY debido a que el padre tiene una sola cola pero el hijo tiene varias colas. Este parche fija el número de colas en 1 para IPoIB heredado lo antes posible. ERROR: desreferencia del puntero NULL del kernel, dirección: 000000000000036b PGD 0 P4D 0 Ups: 0000 [#1] SMP CPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1 Nombre de hardware: PC estándar (Q35 + ICH9, 2009 ), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 RIP: 0010:kmem_cache_alloc+0xcb/0x450 Código: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a 01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 4 c0 74 b8 41 8b RSP: 0018:ffff88822acbbab8 EFLAGS: 00010202 RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae RDX: 00000000064f8dad RSI: 00000a20 RDI: 0000000000030d00 RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40 R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000 R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000 FS: 00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0050033 CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0 DR0: 00000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 0DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: skb_clone+0x55/0xd0 ip6_finish_output2+0x3fe/0x690 ip6_finish_output+0xfa/0x310 _skb+0x1e/0x60 udp_v6_send_skb+0x1e5/0x420 udpv6_sendmsg+0xb3c/0xe60 ? ip_mc_finish_output+0x180/0x180? __switch_to_asm+0x3a/0x60? __switch_to_asm+0x34/0x60 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x160 ? _copy_to_user+0x21/0x30 ? kvm_clock_get_cycles+0xd/0x10? ktime_get_ts64+0x49/0xe0 __x64_sys_sendto+0x25/0x30 do_syscall_64+0x3d/0x90 Entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f9374f1ed14 Código: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b RSP 002 b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14 RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030 RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c R10: 0000000000000000 R11: 00000000000000293 R 12: 0000000000000000 R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc < /TAREA>

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm/compat: previene el posible gadget spectre v1 en xfrm_xlate32_attr() int type = nla_type(nla); if (tipo > XFRMA_MAX) { return -EOPNOTSUPP; } @type luego se usa como índice de matriz y se puede usar como un gadget Spectre v1. if (nla_len(nla) < compat_policy[type].len) { array_index_nospec() se puede utilizar para evitar la filtración de contenido de la memoria del kernel a usuarios malintencionados.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: IB/hfi1: restaurar los recursos asignados en caso de copia fallida. Reparar una fuga de recursos si se produce un error.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: f2fs: evitar aviso de desbordamiento de formato. Con la opción gcc y W=1, aparece un aviso como este: fs/f2fs/compress.c: En la función 'f2fs_init_page_array_cache': fs/f2fs /compress.c:1984:47: error: directiva '%u' escribiendo entre 1 y 7 bytes en una región de tamaño entre 5 y 8 [-Werror=format-overflow=] 1984 | sprintf(slab_name, "f2fs_page_array_entry-%u:%u", MAJOR(dev), MINOR(dev)); | ^~ La cadena "f2fs_page_array_entry-%u:%u" puede tener hasta 35. El primer "%u" puede tener hasta 4 y el segundo "%u" puede hasta 7, por lo que el tamaño total es "24 + 4 + 7 = 35". El tamaño de slab_name debe ser 35 en lugar de 32.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: spi: corrige la desreferencia nula en suspensión. Existe una condición de ejecución donde una transferencia sincrónica (sin cola) puede estar activa durante una suspensión del sistema. Esto puede provocar que se produzca una excepción de desreferencia de puntero null cuando se reanude el sistema. Ejemplo de orden de eventos que conducen a la excepción: 1. spi_sync() llama a __spi_transfer_message_noqueue() que configura ctlr->cur_msg 2. La transferencia Spi comienza a través de spi_transfer_one_message() 3. El sistema se suspende interrumpiendo el contexto de transferencia 4. El sistema se reanuda 6. spi_controller_resume () llama a spi_start_queue(), lo que restablece cur_msg a NULL 7. El contexto de transferencia de Spi se reanuda y se llama a spi_finalize_current_message(), lo que desreferencia cur_msg (que ahora es NULL) Espere a que se completen las transferencias sincrónicas antes de suspender adquiriendo el mutex del bus y configurando/verificando una bandera suspendida.