Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: corrige la falta de icsk_syn_mss con IPPROTO_SMC Eric informa un pánico en IPPROTO_SMC y proporciona los hechos de que cuando se configura INET_PROTOSW_ICSK, también se debe configurar icsk->icsk_sync_mss. Error: No se puede manejar la desreferencia del puntero NULL del núcleo en la dirección virtual 0000000000000000 Información de aborto de memoria: ESR = 0x0000000086000005 EC = 0x21: IABT (EL actual), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: error de traducción de nivel 1 usuario pgtable: 4k páginas, VA de 48 bits, pgdp=00000001195d1000 [000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=000000000000000 Error interno: Oops: 0000000086000005 [#1] Módulos PREEMPT SMP vinculados en: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 No contaminado 6.11.0-rc7-syzkaller-g5f5673607153 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9: 1fffe0001b16f0f1 x8: 0000000000000000 x7: 0000000000000000 x6: 000000000000003f x5: 0000000000000040 x4 : 00000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Rastreo de llamadas: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 seguridad/seguridad.c:4425 __sock_create+0x4c8/0x884 red/socket.c:1587 sock_create red/socket.c:1622 [en línea] __sys_socket_create red/socket.c:1659 [en línea] __sys_socket+0x134/0x340 red/socket.c:1706 __do_sys_socket red/socket.c:1720 [en línea] __se_sys_socket red/socket.c:1718 [en línea] __arm64_sys_socket+0x7c/0x94 red/socket.c:1718 __invoke_syscall arch/arm64/kernel/syscall.c:35 [en línea] invocar_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Código: ???????? ???????? ???????? ???????? (????????) ---[ fin del seguimiento 0000000000000000 ]--- Este parche agrega una implementación de juguete que realiza un retorno simple para evitar tal pánico. Esto se debe a que MSS se puede configurar en sock_create_kern o smc_setsockopt, de manera similar a como se hace en AF_SMC. Sin embargo, para AF_SMC, actualmente no hay forma de sincronizar MSS dentro de __sys_connect_file. Esta implementación de juguete sienta las bases para que admitamos dicha función para IPPROTO_SMC en el futuro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/fbdev-dma: Solo limpiar la E/S diferida si es necesario el commit 5a498d4d06d6 ("drm/fbdev-dma: Solo instalar la E/S diferida si es necesario") inicializa la E/S diferida solo si se usa. Sin embargo, drm_fbdev_dma_fb_destroy() llama a fb_deferred_io_cleanup() incondicionalmente con struct fb_info.fbdefio == NULL. KASAN con el controlador de pantalla de silicio de Apple fuera del árbol publica la siguiente advertencia de __flush_work() de una estructura aleatoria work_struct en lugar de las derefs de puntero NULL esperadas. [ 22.053799] ------------[ cortar aquí ]------------ [ 22.054832] ADVERTENCIA: CPU: 2 PID: 1 en kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Módulos vinculados en: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow No contaminado 6.11.2-asahi+ #asahi-dev [ 22.075612] Nombre del hardware: Apple MacBook Pro (13 pulgadas, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ [22.080345] sp: ffffc000836ef820 [22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [22.082678] x26: dfffc0000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [22.084263] x23: ffff80004b7862b8 x22: dfffc0000000000 x21: ffff80005aa1d470 [22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9: 1ffff800106ddf0e [22.092206] x8: 0000000000000000 x7: aaaaaaaaaaaaaaaa x6: 0000000000000001 [22.093790] x5: 00836ef728 x4: 0000000000000000 x3: 0000000000000020 [22.095368] x2: 00000000000000008 x1: 00000000000000aa x0: 00000000000000000 [ 22.096955] Rastreo de llamadas: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] anular registro de búfer de fotogramas+0x210/0x2f0 [ 22.102575] drm_fb_helper_anular registro de información+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] apagado_dispositivo+0x368/0x4d8 [ 22.112095] reinicio_kernel+0x6c/0x1d0 [ 22.112946] reinicio_del_sistema_arm64+0x1c8/0x328 [ 22.113868] invocar_llamada_al_sistema+0x78/0x1a8 [ 22.114703] hacer_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] controlador_sincronización_el0t_64+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Detener el perfmon activo antes de ser destruido Al ejecutar `kmscube` con uno o más monitores de rendimiento habilitados a través de `GALLIUM_HUD`, puede ocurrir el siguiente pánico del kernel: [ 55.008324] No se puede manejar la solicitud de paginación del kernel en la dirección virtual 00000000052004a4 [ 55.008368] Información de aborto de memoria: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (EL actual), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: error de traducción de nivel 1 [ 55.008434] Información de interrupción de datos: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] pgtable de usuario: páginas de 4k, VA de 39 bits, pgdp=00000001046c6000 [ 55.008497] [000000000052004a4] pgd=0000000000000000, p4d=00000000000000000, pud=0000000000000000 [ 55.008525] Error interno: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Módulos vinculados en: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Contaminado: GC 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Nombre del hardware: Raspberry Pi 4 Modelo B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9: ffffffda1bd04d04 [55.011162] x8: ffffff8102097b80 x7: 0000000000000000 x6: 00000000030a5857 [55.011880] x5: 00ffffffffffffff x4: 0300000005200470 x3: 0300000005200470 [55.012598] x2: ffffff8101238000 x1: 0000000000000021 x0 : 0300000005200470 [ 55.013292] Rastreo de llamadas: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Código: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ fin del seguimiento 000000000000000 ]--- [ 55.020411] nota: v3d_bin[166] salió con preempt_count 1 Este problema surge porque, al cerrar el descriptor de archivo (lo que sucede cuando interrumpimos `kmscube`), el monitor de rendimiento activo no se detiene. Aunque todos los monitores de rendimiento se destruyen en `v3d_perfmon_close_file()`, el puntero del monitor de rendimiento activo (`v3d->active_perfmon`) aún se conserva. Si se ejecuta de nuevo `kmscube`, el controlador intentará detener el monitor de rendimiento activo utilizando el puntero obsoleto en `v3d->active_perfmon`. Sin embargo, este puntero ya no es válido porque el proceso anterior ya ha finalizado y todos los monitores de rendimiento asociados con él se han destruido y liberado. Para solucionar esto, cuando el monitor de rendimiento activo pertenece a un proceso determinado, deténgalo explícitamente antes de destruirlo y liberarlo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: slip: hacer que slhc_remember() sea más robusto contra paquetes maliciosos syzbot descubrió que slhc_remember() no realizaba comprobaciones contra paquetes maliciosos [1]. slhc_remember() solo comprobaba que el tamaño del paquete fuera al menos 20, lo que no es suficiente. Necesitamos asegurarnos de que el paquete incluya los encabezados IPv4 y TCP que se supone que deben transportarse. Agregue punteros iph y th para que el código sea más legible. [1] ERROR: KMSAN: valor no inicializado en slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [en línea] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [en línea] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [en línea] __se_sys_sendmmsg net/socket.c:2768 [en línea] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit se creó en: slab_post_alloc_hook mm/slub.c:4091 [en línea] slab_alloc_node mm/slub.c:4134 [en línea] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [en línea] sock_wmalloc+0xfe/0x1a0 red/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec red/socket.c:729 [en línea] __sock_sendmsg+0x30f/0x380 red/socket.c:744 ____sys_sendmsg+0x903/0xb60 red/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 red/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 red/socket.c:2742 __do_sys_sendmmsg red/socket.c:2771 [en línea] __se_sys_sendmmsg net/socket.c:2768 [en línea] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 No contaminado 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ppp: se corrige el acceso ilegal a ppp_async_encode() syzbot informó un problema en ppp_async_encode() [1] En este caso, se llama a pppoe_sendmsg() con un tamaño cero. Luego, se llama a ppp_async_encode() con un skb vacío. ERROR: KMSAN: valor no inicializado en ppp_async_encode drivers/net/ppp/ppp_async.c:545 [en línea] ERROR: KMSAN: valor no inicializado en ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [en línea] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [en línea] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [en línea] __sock_sendmsg+0x30f/0x380 red/socket.c:744 ____sys_sendmsg+0x903/0xb60 red/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 red/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 red/socket.c:2742 __do_sys_sendmmsg red/socket.c:2771 [en línea] __se_sys_sendmmsg red/socket.c:2768 [en línea] __x64_sys_sendmmsg+0xbc/0x120 red/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit se creó en: slab_post_alloc_hook mm/slub.c:4092 [en línea] slab_alloc_node mm/slub.c:4135 [en línea] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 red/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [en línea] sock_wmalloc+0xfe/0x1a0 red/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec red/socket.c:729 [en línea] __sock_sendmsg+0x30f/0x380 red/socket.c:744 ____sys_sendmsg+0x903/0xb60 red/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 red/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 red/socket.c:2742 __do_sys_sendmmsg red/socket.c:2771 [en línea] __se_sys_sendmmsg red/socket.c:2768 [en línea] __x64_sys_sendmmsg+0xbc/0x120 red/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 No contaminado 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 13/09/2024

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: no retrasar dst_entries_add() en dst_release() dst_entries_add() usa datos por CPU que podrían liberarse en el desmantelamiento de netns de ip6_route_net_exit() llamando a dst_entries_destroy() Antes de que se pueda llamar a ip6_route_net_exit(), liberamos todos los dst asociados con este netns, a través de llamadas a dst_release(), que espera un período de gracia de rcu antes de llamar a dst_destroy() El uso de dst_entries_add() en dst_destroy() es arriesgado, porque dst_entries_destroy() ya podría haberse llamado. La disminución del número de dst debe ocurrir antes. Notas: 1) en el caso de CONFIG_XFRM, dst_destroy() puede llamar a dst_release_immediate(child), lo que también podría causar UAF si el hijo no tiene DST_NOCOUNT configurado. Los encargados del mantenimiento de IPSEC podrían echar un vistazo y ver cómo solucionar esto. 2) También se está discutiendo sobre la eliminación de este recuento de dst, lo que podría suceder en kernels futuros.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: xtables: evita NFPROTO_UNSPEC donde sea necesario syzbot logró llamar a xt_cluster match a través de ebtables: ADVERTENCIA: CPU: 0 PID: 11 en net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 El módulo se registra en NFPROTO_UNSPEC, pero asume el procesamiento de paquetes ipv4/ipv6. Como esto solo es útil para restringir el tráfico TCP/UDP que termina localmente, regístrelo solo para la familia ipv4 e ipv6. Pablo señala que este es un problema general, los usuarios directos de la interfaz set/getsockopt pueden llamar a destinos/coincidencias que solo estaban destinados a usarse con tablas ip(6). Compruebe todas las coincidencias y objetivos UNSPEC para ver si hay problemas similares: - las coincidencias y los objetivos están bien excepto si asumen que skb_network_header() es válido - esto solo es cierto cuando se llama desde la capa inet: la pila ip(6) extrae el encabezado ip/ipv6 en el área de datos lineales. - los objetivos que devuelven XT_CONTINUE u otros veredictos de xtables también deben restringirse, son incompatibles con el traverser de ebtables, por ejemplo, EBT_CONTINUE es un valor completamente diferente de XT_CONTINUE. La mayoría de las coincidencias/objetivos se cambian para registrarse para NFPROTO_IPV4/IPV6, ya que se proporcionan para su uso por ip(6)tables. El objetivo MARK también lo usan arptables, así que regístrese también para NFPROTO_ARP. Mientras tanto, abandone si connbytes no puede habilitar la familia conntrack correspondiente. Este cambio pasa las autopruebas en iptables.git.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: acepta TCA_STAB solo para qdisc raíz La mayoría de las qdisc mantienen su lista de espera utilizando qdisc_pkt_len(skb) asumiendo que es invariable entre los controladores enqueue() y dequeue(). Desafortunadamente, syzbot puede hacer que un host se bloquee con bastante facilidad utilizando una combinación TBF + SFQ, con un STAB en SFQ [1] No podemos admitir TCA_STAB en un nivel arbitrario, esto requeriría mantener el almacenamiento por qdisc. [1] [ 88.796496] ERROR: desreferencia de puntero NULL del núcleo, dirección: 0000000000000000 [ 88.798611] #PF: acceso de lectura del supervisor en modo núcleo [ 88.799014] #PF: error_code(0x0000) - página no presente [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 No contaminado 6.12.0-rc1-virtme #1117 [ 88.801107] Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Código: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 Todo el código ======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 suma %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- instrucción de captura 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (malo) ... Código que comienza con la instrucción que fallo ============================================= 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (malo) ... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.8 04560] RDX: ffff9a1f81bc1440 RSI: 00000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Seguimiento de llamadas: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncado---

En el mod de Minecraft "Command Block IDE" hasta la versión 0.4.9 incluida, una autorización faltante (CWE-862) permite a cualquier usuario modificar archivos de "función" utilizados por el juego cuando se instala en un servidor dedicado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: Se corrige el manejo incorrecto de refcount en ice_sriov_set_msix_vec_count() Este parche soluciona un problema con el manejo incorrecto del recuento de referencias en la función ice_sriov_set_msix_vec_count(). Primero, la función llama a ice_get_vf_by_id(), que incrementa el recuento de referencias del puntero vf. Si la llamada posterior a ice_get_vf_vsi() fallo, la función actualmente devuelve un error sin disminuir el recuento de referencias del puntero vf, lo que lleva a una pérdida del recuento de referencias. El comportamiento correcto, como se implementó en este parche, es disminuir el recuento de referencias usando ice_put_vf(vf) antes de devolver un error cuando vsi es NULL. En segundo lugar, la función llama a ice_sriov_get_irqs(), que establece vf->first_vector_idx. Si esta llamada devuelve un valor negativo, lo que indica un error, la función devuelve un error sin disminuir el recuento de referencia del puntero vf, lo que genera otra pérdida de recuento de referencia. El parche soluciona este problema agregando una llamada a ice_put_vf(vf) antes de devolver un error cuando vf->first_vector_idx < 0. Este error fue identificado por una herramienta de análisis estático experimental desarrollada por nuestro equipo. La herramienta se especializa en analizar operaciones de recuento de referencia e identificar posibles errores de administración de los recuentos de referencia. En este caso, la herramienta marcó la operación de disminución faltante como un problema potencial, lo que llevó a este parche.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: Se corrige el manejo incorrecto de refcount en ice_dpll_init_rclk_pins() Este parche soluciona un problema de manejo de recuento de referencias en la función ice_dpll_init_rclk_pins(). La función llama a ice_dpll_get_pins(), que incrementa el recuento de referencias de los recursos relevantes. Sin embargo, si se cumple la condición WARN_ON((!vsi || !vsi->netdev)), la función actualmente devuelve un error sin liberar correctamente los recursos adquiridos por ice_dpll_get_pins(), lo que lleva a una pérdida de recuento de referencias. Para resolver esto, la comprobación se ha movido a la parte superior de la función. Esto garantiza que la función verifique el estado antes de que se adquieran recursos, lo que evita la necesidad de una gestión de recursos adicional en la ruta de error. Este error fue identificado por una herramienta de análisis estático experimental desarrollada por nuestro equipo. La herramienta se especializa en analizar operaciones de recuento de referencias y detectar posibles problemas donde los recursos no se administran correctamente. En este caso, la herramienta marcó la operación de liberación faltante como un problema potencial, lo que llevó al desarrollo de este parche.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: phy: Eliminar la entrada LED de la lista de LED al anular el registro El commit c938ab4da0eb ("net: phy: Eliminar manualmente los LED para garantizar el orden correcto") corrigió correctamente un problema con el uso de devm_ pero no eliminó la entrada LED de la lista de LED. Esto causa pánico del kernel en un escenario específico donde el puerto para el PHY se desactiva y activa y se elimina el kmod para el PHY. Al desactivar el puerto la primera vez, los LED asociados se anulan correctamente el registro. El kmod asociado para el PHY ahora se elimina. El kmod ahora se agrega nuevamente y el puerto ahora se activa, los LED asociados se registran nuevamente. Al desactivar el puerto nuevamente por segunda vez después de estos pasos, la lista de LED ahora tiene 4 elementos. Con los primeros 2 ya anulados previamente y los 2 nuevos registrados nuevamente. Esto causa un pánico del kernel ya que los primeros 2 elementos deberían haberse eliminado. Arregle esto eliminando correctamente el elemento cuando el LED no está registrado.