Vulnerabilidades

En las plataformas FPGA de la serie 7130 afectadas que ejecutan MOS y versiones recientes de FPGA MultiAccess, la aplicación de ACL puede provocar un funcionamiento incorrecto de la ACL configurada para un puerto, lo que da como resultado que se permitan algunos paquetes que deberían negarse y algunos

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: IB/qib: corrige la pérdida de memoria en qib_user_sdma_queue_pkts() Se utilizó la etiqueta goto incorrecta para el caso de error y se omitió la limpieza de la asignación de paquetes. Direcciones-Coverity-ID: 1493352 ("Fuga de recursos")

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: xsk: devuelve los buffers xsk al grupo al limpiar el anillo. Actualmente solo hacemos NULL en el puntero xdp_buff en el anillo SW interno, pero nunca lo devolvemos al grupo de buffers xsk. Esto significa que los buffers se pueden filtrar fuera del grupo de buffers y no volver a usarse nunca más. Agregue la llamada xsk_buff_free() faltante a la rutina que se supone que limpia las entradas que quedan en el anillo para que otros sockets puedan usar estos buffers en el umem. Además, pase solo por el espacio que realmente queda por limpiar en lugar de por un anillo completo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: corrige use-after-free en nft_set_catchall_destroy() Necesitamos usar el iterador list_for_each_entry_safe() porque no podemos acceder a @catchall después de la llamada a kfree_rcu(). syzbot informó: ERROR: KASAN: use-after-free en nft_set_catchall_destroy net/netfilter/nf_tables_api.c:4486 [en línea] ERROR: KASAN: use-after-free en nft_set_destroy net/netfilter/nf_tables_api.c:4504 [en línea] ERROR : KASAN: use-after-free en nft_set_destroy+0x3fd/0x4f0 net/netfilter/nf_tables_api.c:4493 Lectura de tamaño 8 en la dirección ffff8880716e5b80 por tarea syz-executor.3/8871 CPU: 1 PID: 8871 Comm: syz-executor .3 No contaminado 5.16.0-rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl +0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x2ed mm/kasan/report.c:247 __kasan_report mm/kasan/report.c:433 [en línea] kasan_report.cold+0x83/ 0xdf mm/kasan/report.c:450 nft_set_catchall_destroy net/netfilter/nf_tables_api.c:4486 [en línea] nft_set_destroy net/netfilter/nf_tables_api.c:4504 [en línea] nft_set_destroy+0x3fd/0x4f0 net/netfilter/nf_tables_a foto.c:4493 __nft_release_table+0x79f/0xcd0 net/netfilter/nf_tables_api.c:9626 nft_rcv_nl_event+0x4f8/0x670 net/netfilter/nf_tables_api.c:9688 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83 blocking_notifier_call_chain kernel/ notificador.c:318 [en línea ] blocking_notifier_call_chain+0x67/0x90 kernel/notifier.c:306 netlink_release+0xcb6/0x1dd0 net/netlink/af_netlink.c:788 __sock_release+0xcd/0x280 net/socket.c:649 sock_close+0x18/0x20 net/socket.c: 1314 __fput+0x286/0x9f0 fs/file_table.c:280 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [en línea] exit_to_user_mode_loop kernel/entry/common.c:175 [en línea ] exit_to_user_mode_prepare+0x27e/0x290 kernel/entry/common.c:207 __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [en línea] syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300 do_syscall_64+0x42/ 0xb0 arco/x86 /entry/common.c:86 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f75fbf28adb Código: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 63 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 fc ff ff 8b 44 RSP: 002b:00007ffd8da7ec10 EFLAGS: 0000 0293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00007f75fbf28adb RDX: 00007f75fc08e828 RSI: ffffffffffffffff RDI: 00000000000000003 RBP: 00007f75fc08a960 R08: 000000 0000000000 R09: 00007f75fc08e830 R10: 00007ffd8da7ed10 R11: 0000000000000293 R12: 00000000002067c3 R13: 00007ffd8da7ed10 R14: 00007f75fc0 88f60 R15: 0000000000000032 Asignado por la tarea 8886 : kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:46 [en línea] set_alloc_info mm/kasan/common.c:434 [en línea] ____kasan_kmalloc mm/kasan/common.c: 513 [en línea] ____kasan_kmalloc mm/kasan/common.c:472 [en línea] __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:522 kasan_kmalloc include/linux/kasan.h:269 [en línea] kmem_cache_alloc_trace+0x1ea/0x4a0 mm /slab.c:3575 kmalloc include/linux/slab.h:590 [en línea] nft_setelem_catchall_insert net/netfilter/nf_tables_api.c:5544 [en línea] nft_setelem_insert net/netfilter/nf_tables_api.c:5562 [en línea] nft_add_set_elem+0x232e/0 x2f40 net/netfilter/nf_tables_api.c:5936 nf_tables_newsetelem+0x6ff/0xbb0 net/netfilter/nf_tables_api.c:6032 nfnetlink_rcv_batch+0x1710/0x25f0 net/netfilter/nfnetlink.c:513 nfnetlink_rcv_skb_batch net/netfilter/ nfnetlink.c:634 [en línea] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:652 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [en línea]---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFSD: corrige el desbordamiento del búfer READDIR Si un cliente envía un argumento de recuento READDIR que es demasiado pequeño (digamos, cero), entonces el cálculo del tamaño del búfer en las nuevas funciones auxiliares init_dirlist da como resultado un subdesbordamiento, lo que permite que las funciones de flujo XDR escriban más allá del búfer real. Este cálculo siempre ha sido sospechoso. NFSD nunca ha verificado la cordura del argumento de conteo READDIR, pero los codificadores de entrada antiguos manejaron el problema correctamente. Con las confirmaciones a continuación, la codificación de entrada cambió, exponiendo el desbordamiento a la aritmética del puntero en xdr_reserve_space(). Los clientes NFS modernos intentan recuperar la mayor cantidad de datos posible para cada solicitud READDIR. Además, no tenemos pruebas unitarias que ejerzan el comportamiento de READDIR en el límite inferior de los valores @count. Por lo tanto, este caso se pasó por alto durante las pruebas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/mediatek: hdmi: realice una verificación de puntero NULL para mtk_hdmi_conf En el commit 41ca9caaae0b ("drm/mediatek: hdmi: agregue verificación solo para modos CEA") se agregó una verificación para los modos CEA funcionar mtk_hdmi_bridge_mode_valid() para solucionar posibles problemas en MT8167; Además, con el commit c91026a938c2 ("drm/mediatek: hdmi: Agregar límite opcional en el reloj máximo en modo HDMI") se introdujo otra verificación similar. Desafortunadamente, al momento de escribir este artículo, MT8173 no proporciona ninguna estructura mtk_hdmi_conf y esto bloquea el kernel con un puntero NULL al ingresar a mtk_hdmi_bridge_mode_valid(), lo que sucede tan pronto como se conecta un cable HDMI. Para solucionar esta regresión, agregue un El puntero NULL comprueba hdmi->conf en dicha función, restaurando la funcionalidad HDMI y evitando pánicos del kernel del puntero NULL.

IBM Connect:Express para UNIX 1.5.0 es vulnerable a un desbordamiento de búfer que podría permitir a un atacante remoto provocar una denegación de servicio a través de la interfaz de usuario de su navegador. ID de IBM X-Force: 254979.

En JetBrains TeamCity antes de 2023.11.4 era posible omitir la autenticación permitiendo realizar acciones administrativas

En JetBrains TeamCity antes de 2023.11.4 era posible un path traversal permitiendo realizar acciones administrativas limitadas

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: elantech - arregla la pila fuera del acceso limitado en elantech_change_report_id() El parámetro de matriz[] en elantech_change_report_id() debe tener al menos 3 bytes, porque elantech_read_reg_params() está llamando a ps2_command( ) con PSMOUSE_CMD_GETINFO, que accederá a 3 bytes desde param[], pero está definido en la pila como una matriz de 2 bytes, por lo tanto, aquí tenemos un posible acceso fuera de los límites a la pila, también confirmado por KASAN: [6.512374 ] ERROR: KASAN: pila fuera de los límites en __ps2_command+0x372/0x7e0 [6.512397] Lectura del tamaño 1 en la dirección ffff8881024d77c2 por tarea kworker/2:1/118 [6.512416] CPU: 2 PID: 118 Comm: kworker/ 2:1 No contaminado 5.13.0-22-generic #22+arighi20211110 [6.512428] Nombre de hardware: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08) 14/08/2020 [6.512436] Cola de trabajo: events_long serio_handle_even t [6.512453] Seguimiento de llamadas: [6.512462] show_stack+0x52/0x58 [6.512474] dump_stack+0xa1/0xd3 [6.512487] print_address_description.constprop.0+0x1d/0x140 [6.512502]? __ps2_command+0x372/0x7e0 [6.512516] __kasan_report.cold+0x7d/0x112 [6.512527] ? _raw_write_lock_irq+0x20/0xd0 [6.512539]? __ps2_command+0x372/0x7e0 [ 6.512552] kasan_report+0x3c/0x50 [ 6.512564] __asan_load1+0x6a/0x70 [ 6.512575] __ps2_command+0x372/0x7e0 [ 6.512589] ? ps2_drain+0x240/0x240 [6.512601]? dev_printk_emit+0xa2/0xd3 [6.512612]? dev_vprintk_emit+0xc5/0xc5 [6.512621]? __kasan_check_write+0x14/0x20 [6.512634]? mutex_lock+0x8f/0xe0 [6.512643]? __mutex_lock_slowpath+0x20/0x20 [ 6.512655] ps2_command+0x52/0x90 [ 6.512670] elantech_ps2_command+0x4f/0xc0 [psmouse] [ 6.512734] elantech_change_report_id+0x1e6/0x256 [psmouse] [ 6.512799] ? elantech_report_trackpoint.constprop.0.cold+0xd/0xd [psmouse] [6.512863]? ps2_command+0x7f/0x90 [6.512877] elantech_query_info.cold+0x6bd/0x9ed [psmouse] [6.512943] ? elantech_setup_ps2+0x460/0x460 [psmouse] [6.513005]? psmouse_reset+0x69/0xb0 [psmouse] [6.513064]? psmouse_attr_set_helper+0x2a0/0x2a0 [psmouse] [6.513122]? phys_pmd_init+0x30e/0x521 [6.513137] elantech_init+0x8a/0x200 [psmouse] [6.513200]? elantech_init_ps2+0xf0/0xf0 [psmouse] [6.513249]? elantech_query_info+0x440/0x440 [psmouse] [6.513296]? synaptics_send_cmd+0x60/0x60 [psmouse] [6.513342]? elantech_query_info+0x440/0x440 [psmouse] [6.513388]? psmouse_try_protocol+0x11e/0x170 [psmouse] [6.513432] psmouse_extensions+0x65d/0x6e0 [psmouse] [6.513476]? psmouse_try_protocol+0x170/0x170 [psmouse] [6.513519]? mutex_unlock+0x22/0x40 [6.513526]? ps2_command+0x7f/0x90 [6.513536]? psmouse_probe+0xa3/0xf0 [psmouse] [ 6.513580] psmouse_switch_protocol+0x27d/0x2e0 [psmouse] [ 6.513624] psmouse_connect+0x272/0x530 [psmouse] [ 6.513669] serio_driver_probe+0x55/0x70 [ 6.513679] realmente_probe+0x190/0x720 [ 6.513689] driver_probe_device +0x160/0x1f0 [6.513697] dispositivo_driver_attach+0x119/0x130 [6.513705] ? dispositivo_driver_attach+0x130/0x130 [6.513713] __driver_attach+0xe7/0x1a0 [6.513720]? device_driver_attach+0x130/0x130 [6.513728] bus_for_each_dev+0xfb/0x150 [6.513738]? subsys_dev_iter_exit+0x10/0x10 [6.513748]? _raw_write_unlock_bh+0x30/0x30 [ 6.513757] driver_attach+0x2d/0x40 [ 6.513764] serio_handle_event+0x199/0x3d0 [ 6.513775] Process_one_work+0x471/0x740 [ 6.513785] trabajador_thread+0x2d2 /0x790 [6.513794] ? Process_one_work+0x740/0x740 [6.513802] kthread+0x1b4/0x1e0 [6.513809]? set_kthread_struct+0x80/0x80 [6.513816] ret_from_fork+0x22/0x30 [6.513832] La dirección del error pertenece a la página: [6.513838] página:00000000bc35e189 refcount:0 mapcount:0 mapeo:0000000000000000 index:0x0 pfn:0x1024d7 [6.513847] banderas: 0x17ffffc0000000(nodo=0|zona=2|lastcpupid=0x1fffff) [6.513860] sin procesar: 0

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (lm90) Previene el desbordamiento/desbordamiento insuficiente de enteros en los cálculos de histéresis del commit b50aa49638c7 ("hwmon: (lm90) Evita el desbordamiento insuficiente de enteros en los cálculos de temperatura") abordó una serie de situaciones de desbordamiento insuficiente al escribir. límites de temperatura. Sin embargo, omitió una situación, vista cuando se intenta establecer el valor de histéresis en MAX_LONG y el límite de temperatura crítica es negativo. Utilice abrazadera_val() al configurar la temperatura de histéresis para garantizar que el valor proporcionado nunca pueda desbordarse o subestimarse.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: veth: asegúrese de que los skb que ingresan a GRO no estén clonados. Después de confirmar d3256efd8e8b ("veth: permitir habilitar NAPI incluso sin XDP"), si GRO está habilitado en un dispositivo veth y TSO está deshabilitado en el dispositivo par, los skbs TCP pasarán por la devolución de llamada de NAPI. Si no hay ningún programa XDP adjunto, el código veth no realiza ninguna verificación compartida y los skbs compartidos/clonados podrían ingresar al motor GRO. Ignat informó de un ERROR que se activó más tarde debido a la condición anterior: [53.970529][C1] ERROR del kernel en net/core/skbuff.c:3574. [ 53.981755][ C1] código de operación no válido: 0000 [#1] PREEMPT SMP KASAN PTI [ 53.982634][ C1] CPU: 1 PID: 19 Comm: ksoftirqd/1 No contaminado 5.16.0-rc5+ #25 [ 53.982634][ C1] Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 0.0.0 06/02/2015 [ 53.982634][ C1] RIP: 0010:skb_shift+0x13ef/0x23b0 [ 53.982634][ C1] Código: ea 03 0f b6 04 02 48 89 fa 83 e2 07 38 d0 7f 08 84 c0 0f 85 41 0c 00 00 41 80 7f 02 00 4d 8d b5 d0 00 00 00 0f 85 74 f5 ff ff <0f> 0b 4d 8d 77 20 be 04 00 00 00 4c 89 44 24 78 4c 89 f7 4c 89 8c [ 53.982634][ C1] RSP: 0018:ffff8881008f7008 EFLAGS: 00010246 [ 53.982634][ C1] RAX: 0000000000000000000000 RB X: ffff8881180b4c80 RCX: 0000000000000000 [ 53.982634][ C1] RDX: 00000000000000002 RSI: ffff8881180b4d3c RDI: ffff88810bc9cac2 [ 53.982634][ C1] RBP: ffff8881008f70b8 R08: ffff8881180b4cf4 R09: ffff8881180b4cf0 [ 53.982634][ C1] R10: ff ffed1022999e5c R11: 0000000000000002 R12: 0000000000000590 [ 53.982634][ C1] R13: ffff88810f940c80 R14: ffff88810f940d50 R15: ffff88810bc9cac0 [ 53.982634][ C1] FS: 00000000000000000(0000) GS:ffff888235880000(0000) knlGS:00000000000000000 [ 53.982634][ C1] CS: 0010 DS: 00 00 ES: 0000 CR0: 0000000080050033 [ 53.982634][ C1] CR2: 00007ff5f9b86680 CR3 : 0000000108ce8004 CR4: 0000000000170ee0 [ 53.982634][ C1] Seguimiento de llamadas: [ 53.982634][ C1] [ 53.982634][ C1] tcp_sacktag_walk+0xaba/0x18e0 [ 53.982634][ C1] t cp_sacktag_write_queue+0xe7b/0x3460 [ 53.982634][ C1 ] tcp_ack+0x2666/0x54b0 [ 53.982634][ C1] tcp_rcv_establecido+0x4d9/0x20f0 [ 53.982634][ C1] tcp_v4_do_rcv+0x551/0x810 [ 53.982634][ C1] tcp_v4_rcv+0x 22ed/0x2ed0 [ 53.982634][ C1] ip_protocol_deliver_rcu+0x96/0xaf0 [ 53.982634][ C1] ip_local_deliver_finish+0x1e0/0x2f0 [ 53.982634][ C1] ip_sublist_rcv_finish+0x211/0x440 [ 53.982634][ C1] ip_list_rcv_finish.constprop.0+0x424/0x660 [ 53.9 82634][C1] ip_list_rcv+0x2c8/0x410 [ 53.982634 ][ C1] __netif_receive_skb_list_core+0x65c/0x910 [ 53.982634][ C1] netif_receive_skb_list_internal+0x5f9/0xcb0 [ 53.982634][ C1] napi_complete_done+0x188/0x6e0 [ 53.982634][ C1] gro_cell_ encuesta+0x10c/0x1d0 [ 53.982634][ C1] __napi_poll+ 0xa1/0x530 [ 53.982634][ C1] net_rx_action+0x567/0x1270 [ 53.982634][ C1] __do_softirq+0x28a/0x9ba [ 53.982634][ C1] run_ksoftirqd+0x32/0x60 [ 53.982634][ C1] smpboot_thread_fn+0x559/0x8c0 [53.982634] [ C1] kthread+0x3b9/0x490 [ 53.982634][ C1] ret_from_fork+0x22/0x30 [ 53.982634][ C1] Solucione el problema omitiendo la etapa GRO para skbs compartidos o clonados. Para reducir la posibilidad de OoO, intente desbloquear los skbs antes de darse por vencido. v1 -> v2: - use evitar skb_copy y recurra a netif_receive_skb - Eric