Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtnetlink: Asignar tamaño de vfinfo para GUID de VF cuando sea compatible. el commit 30aad41721e0 ("net/core: Agregar soporte para obtener GUID de VF") agregó soporte para obtener GUID de puerto y nodo de VF en mensajes ifinfo de netlink, pero su tamaño no se tuvo en cuenta en la función que asigna el mensaje de netlink, lo que causa la siguiente advertencia cuando un mensaje de netlink se llena con muchos GUID de puerto y nodo de VF: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK responde: Mensaje demasiado largo. No se puede enviar solicitud de obtención de enlace: Mensaje demasiado largo. Advertencia del kernel: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: fgraph: Se corrige el diseño de la pila para que coincida con el argumento __arch_ftrace_regs de ftrace_return_to_handler Naresh Kamboju informó una advertencia del kernel "Puntero de marco incorrecto" mientras ejecutaba el seguimiento LTP ftrace_stress_test.sh en riscv. Podemos reproducir el mismo problema con el siguiente comando: ``` $ cd /sys/kernel/debug/tracing $ echo 'f:myprobe do_nanosleep%return args1=$retval' > dynamic_events $ echo 1 > events/fprobes/enable $ echo 1 > tracing_on $ sleep 1 ``` Y podemos obtener la siguiente advertencia del kernel: [ 127.692888] ------------[ cortar aquí ]------------ [ 127.693755] Puntero de marco incorrecto: se esperaba ff2000000065be50, se recibió ba34c141e9594000 [ 127.693755] de func do_nanosleep return a ffffffff800ccb16 [ 127.698699] ADVERTENCIA: CPU: 1 PID: 129 en kernel/trace/fgraph.c:755 ftrace_return_to_handler+0x1b2/0x1be [ 127.699894] Módulos vinculados en: [ 127.700908] CPU: 1 UID: 0 PID: 129 Comm: sleep No contaminado 6.14.0-rc3-g0ab191c74642 #32 [ 127.701453] Nombre del hardware: riscv-virtio,qemu (DT) [ 127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be [ 127.702032] ra : ftrace_return_to_handler+0x1b2/0x1be [ 127.702151] epc : ffffffff8013b5e0 ra : ffffffff8013b5e0 sp : ff2000000065bd10 [ 127.702221] gp : ffffffff819c12f8 tp : ff60000080853100 t0 : 6e00000000000000 [ 127.702284] t1 : 0000000000000020 t2 : 6e7566206d6f7266 s0 : ff2000000065bd80 [ 127.702346] s1 : ff60000081262000 a0 : 000000000000007b a1: ffffffff81894f20 [127.702408] a2: 0000000000000010 a3: fffffffffffffffffe a4: 00000000000000000 [127.702470] a5: 0000000000000000 a6: 0000000000000008 a7: 0000000000000038 [127.702530] s2: ba34c141e9594000 s3: 0000000000000000 s4: ff2000000065bdd0 [127.702591] s5: 00007fff8adcf400 s6: 000055556dc1d8c0 s7: 00000000000000068 [127.702651] s8: 00007fff8adf5d10 s9: 000000000000006d s10: 0000000000000001 [127.702710] s11: 00005555737377c8 t3: ffffffff819d899e t4: ffffffff819d899e [ 127.702769] t5: ffffffff819d89a0 t6: ff2000000065bb18 [127.702826] estado: 0000000200000120 dirección incorrecta: 0000000000000000 causa: 0000000000000003 [127.703292] [] ftrace_return_to_handler+0x1b2/0x1be [127.703760] [] return_to_handler+0x16/0x26 [127.704009] [] retorno_al_controlador+0x0/0x26 [ 127.704057] [] suspensión_común+0x42/0x54 [ 127.704117] [] __riscv_sys_clock_nanosleep+0xba/0x10a [ 127.704176] [] hacer_trampa_ecall_u+0x188/0x218 [ 127.704295] [] controlar_excepción+0x14a/0x156 [ 127.705436] ---[ fin de seguimiento 0000000000000000 ]--- La razón es que el diseño de la pila para construir el argumento para ftrace_return_to_handler en return_to_handler no coincide con la estructura __arch_ftrace_regs de riscv, lo que genera resultados inesperados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: no anular el registro del gancho cuando la tabla está inactiva. Cuando nf_tables_updchain detecta un error, es necesario revertir el registro del gancho. Esto solo debe hacerse si el gancho ya está registrado, lo cual no ocurrirá si la tabla está inactiva. Simplemente mueva la asignación al bloque de registro.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: idpf: corrección de la desreferencia de puntero nulo del adaptador al reiniciar. Con SRIOV habilitado, idpf termina llamando a idpf_remove() dos veces. Primero mediante idpf_shutdown() y luego de nuevo cuando idpf_remove() llama a sriov_disable(), porque los dispositivos VF usan el controlador idpf, de ahí la misma rutina de eliminación. Cuando esto sucede, es posible que el adaptador sea nulo desde la primera llamada a idpf_remove(), lo que provoca una desreferencia de puntero nulo. echo 1 > /sys/class/net//device/sriov_numvfs reboot BUG: desreferencia de puntero nulo del kernel, dirección: 000000000000020 ... RIP: 0010:idpf_remove+0x22/0x1f0 [idpf] ... ? idpf_remove+0x22/0x1f0 [idpf] ? idpf_remove+0x1e4/0x1f0 [idpf] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19f/0x200 pci_stop_bus_device+0x6d/0x90 pci_stop_and_remove_bus_device+0x12/0x20 pci_iov_remove_virtfn+0xbe/0x120 sriov_disable+0x34/0xe0 idpf_sriov_configure+0x58/0x140 [idpf] idpf_remove+0x1b9/0x1f0 [idpf] idpf_shutdown+0x12/0x30 [idpf] pci_device_shutdown+0x35/0x60 device_shutdown+0x156/0x200 ... Reemplace la llamada directa a idpf_remove() en idpf_shutdown() con idpf_vc_core_deinit() e idpf_deinit_dflt_mbx(), que realizan la mayor parte de la limpieza, como detener la tarea de inicialización, liberar IRQ, destruir los puertos virtuales y liberar el buzón. Esto evita las llamadas a sriov_disable(), además de una pequeña limpieza de netdev y la destrucción de las colas de trabajo, que no parecen necesarias al apagar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: cadence: Se corrige el acceso fuera de los límites a la matriz en cdns_mrvl_xspi_setup_clock(). Si request_clk > 128, cdns_mrvl_xspi_setup_clock() itera sobre toda la matriz cdns_mrvl_xspi_clk_div_list sin interrumpir la ejecución antes de tiempo, lo que provoca que 'i' sobrepase los límites de la matriz. Para solucionarlo, se detiene el bucle al llegar a la última entrada y se fija el reloj al mínimo de 6,25 MHz. Se corrige la siguiente advertencia con un kernel UBSAN: vmlinux.o: advertencia: objtool: cdns_mrvl_xspi_setup_clock: fin inesperado de la sección .text.cdns_mrvl_xspi_setup_clock

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: imx-card: Añadir comprobación de NULL en imx_card_probe(). Devm_kasprintf() devuelve NULL cuando falla la asignación de memoria. Actualmente, imx_card_probe() no comprueba este caso, lo que provoca una desreferencia de puntero NULL. Añadir comprobación de NULL después de devm_kasprintf() para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: disminuir los contadores dst en caché en dst_release La corrección ascendente ac888d58869b ("net: no retrasar dst_entries_add() en dst_release()") se movió y disminuyó el recuento dst de dst_destroy a dst_release para evitar acceder a datos ya liberados en caso de desmantelamiento de netns. Sin embargo, en caso de que CONFIG_DST_CACHE esté habilitado y se usen túneles OvS+, esta corrección está incompleta ya que se verá el mismo problema para los dst en caché: No se puede manejar la solicitud de paginación del núcleo en la dirección virtual ffff5aabf6b5c000 Rastreo de llamadas: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30 Corrija esto invalidando el caché y, por lo tanto, disminuyendo los contadores dst en caché. dst_release también.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: airoha: Se corrige el informe qid en airoha_tc_get_htb_get_leaf_queue() Se corrige la siguiente advertencia del kernel que elimina las hojas descargadas de HTB y/o el qdisc de HTB raíz en el controlador airoha_eth que informa correctamente el qid en la rutina airoha_tc_get_htb_get_leaf_queue. $tc qdisc replace dev eth1 root handle 10: htb offload $tc class add dev eth1 arent 10: classid 10:4 htb rate 100mbit ceil 100mbit $tc qdisc replace dev eth1 parent 10:4 handle 4: ets bands 8 \ quanta 1514 3028 4542 6056 7570 9084 10598 12112 $tc qdisc del dev eth1 root [ 55.827864] ------------[ cortar aquí ]------------ [ 55.832493] ADVERTENCIA: CPU: 3 PID: 2678 en 0xffffffc0798695a4 [ 55.956510] CPU: 3 PID: 2678 Comm: tc Tainted: GO 6.6.71 #0 [ 55.963557] Nombre del hardware: Placa de evaluación Airoha AN7581 (DT) [ 55.969383] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.976344] pc : 0xffffffc0798695a4 [ 55.979851] lr : 0xffffffc079869a20 [ 55.983358] sp : ffffffc0850536a0 [ 55.986665] x29: ffffffc0850536a0 x28: 0000000000000024 x27: 0000000000000001 [ 55.993800] x26: 0000000000000000 x25: ffffff8008b19000 x24: ffffff800222e800 [ 56.000935] x23: 000000000000001 x22: 0000000000000000 x21: ffffff8008b19000 [ 56.008071] x20: ffffff8002225800 x19: ffffff800379d000 x18: 000000000000000 [ 56.015206] x17: ffffffbf9ea59000 x16: ffffffc080018000 x15: 0000000000000000 [ 56.022342] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000001 [ 56.029478] x11: fffffc081471008 x10: fffffc081575a98 x9: 0000000000000000 [ 56.036614] x8: fffffc08167fd40 x7: fffffc08069e104 x6 : ffffff8007f86000 [ 56.043748] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000001 [ 56.050884] x2 : 0000000000000000 x1 : 0000000000000250 x0 : ffffff800222c000 [ 56.058020] Rastreo de llamadas: [ 56.060459] 0xffffffc0798695a4 [ 56.063618] 0xffffffc079869a20 [ 56.066777] __qdisc_destroy+0x40/0xa0 [ 56.070528] qdisc_put+0x54/0x6c [ 56.073748] qdisc_graft+0x41c/0x648 [ 56.077324] tc_get_qdisc+0x168/0x2f8 [ 56.080978] rtnetlink_rcv_msg+0x230/0x330 [ 56.085076] netlink_rcv_skb+0x5c/0x128 [ 56.088913] rtnetlink_rcv+0x14/0x1c [ 56.092490] netlink_unicast+0x1e0/0x2c8 [ 56.096413] netlink_sendmsg+0x198/0x3c8 [ 56.100337] ____sys_sendmsg+0x1c4/0x274 [ 56.104261] ___sys_sendmsg+0x7c/0xc0 [ 56.107924] __sys_sendmsg+0x44/0x98 [ 56.111492] __arm64_sys_sendmsg+0x20/0x28 [ 56.115580] invocar_syscall.constprop.0+0x58/0xfc [ 56.120285] do_el0_svc+0x3c/0xbc [ 56.123592] el0_svc+0x18/0x4c [ 56.126647] el0t_64_sync_handler+0x118/0x124 [ 56.131005] el0t_64_sync+0x150/0x154 [ 56.134660] ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: Se corrigen múltiples encapsulamientos de sk->sk_rmem_alloc. __udp_enqueue_schedule_skb() tiene la siguiente condición: if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop; sk->sk_rcvbuf se inicializa con net.core.rmem_default y posteriormente se puede configurar con SO_RCVBUF, que está limitado por net.core.rmem_max o SO_RCVBUFFORCE. Si se establece INT_MAX en sk->sk_rcvbuf, la condición siempre es falsa, ya que sk->sk_rmem_alloc también es un entero con signo. En ese caso, el tamaño del skb entrante se añade a sk->sk_rmem_alloc incondicionalmente. Esto provoca un desbordamiento de enteros (posiblemente varias veces) en sk->sk_rmem_alloc y permite que un único socket tenga skb hasta net.core.udp_mem[1]. Por ejemplo, si establecemos un valor grande en udp_mem[1] e INT_MAX en sk->sk_rcvbuf e inundamos el socket con paquetes, podemos ver múltiples desbordamientos: # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 7956736 <-- (7956736 << 12) bytes > INT_MAX * 15 ^- PAGE_SHIFT # ss -uam State Recv-Q ... UNCONN -1757018048 ... <-- invirtiendo el signo repetidamente skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0) Anteriormente, teníamos una verificación de límite para INT_MAX, que se eliminó mediante el commit 6a1f12dd85a8 ("udp: relajar la operación atómica en sk->sk_rmem_alloc"). Una solución completa sería revertirlo y limitar el operando derecho con INT_MAX: rmem = atomic_add_return(size, &sk->sk_rmem_alloc); if (rmem > min(size + (unsigned int)sk->sk_rcvbuf, INT_MAX)) goto uncharge_drop; pero no queremos añadir el costoso atomic_add_return() solo para casos excepcionales. Convertir rmem a unsigned int evita múltiples encapsulamientos, pero aún permite un único encapsulamiento. # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> 12 # ss -uam State Recv-Q ... UNCONN -2147482816 ... <-- INT_MAX + 831 bytes skmem:(r2147484480,rb2147483646,t0,tb212992,f3264,w0,o0,bl0,d14468947) Por lo tanto, definamos rmem y rcvbuf como unsigned int y verifiquemos skb->truesize solo cuando rcvbuf sea lo suficientemente grande como para reducir la posibilidad de desbordamiento. Tenga en cuenta que aún existe una pequeña probabilidad de ver un desbordamiento si se procesan múltiples skbs al mismo socket en diferentes núcleos al mismo tiempo y cada tamaño no excede el límite, pero el tamaño total sí. Tenga en cuenta también que debemos ignorar skb->truesize para un buffer pequeño como se explica en el commit 363dc73acacb ("udp: sea menos conservador con la contabilidad de sock rmem").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_tunnel: corrección de la adición por confusión de tipos en geneve_opt. Al gestionar varios atributos NFTA_TUNNEL_KEY_OPTS_GENEVE, la lógica de análisis debería colocar cada estructura geneve_opt una a una de forma compacta. Por lo tanto, al determinar la siguiente posición de geneve_opt, la adición del puntero debería realizarse en unidades de char *. Sin embargo, la implementación actual realiza erróneamente la conversión de tipos antes de la adición, lo que provoca escrituras fuera de los límites en el montículo. [ 6.989857] ======================================================================= [ 6.990293] ERROR: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] [ 6.992586] dump_stack_lvl+0x44/0x5c [ 6.992801] print_report+0x184/0x4be [ 6.993790] kasan_report+0xc5/0x100 [ 6.994252] kasan_check_range+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nft_tunnel_obj_init+0x977/0xa70 [ 6.995677] nft_obj_init+0x10c/0x1b0 [ 6.995891] nf_tables_newobj+0x585/0x950 [ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020 [ 6.998997] nfnetlink_rcv+0x1df/0x220 [ 6.999537] netlink_unicast+0x395/0x530 [ 7.000771] netlink_sendmsg+0x3d0/0x6d0 [ 7.001462] __sock_sendmsg+0x99/0xa0 [ 7.001707] ____sys_sendmsg+0x409/0x450 [ 7.002391] ___sys_sendmsg+0xfd/0x170 [ 7.003145] __sys_sendmsg+0xea/0x170 [ 7.004359] do_syscall_64+0x5e/0x90 [ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8 Corrija este error con la correcta adición y conversión de punteros en el código de análisis y volcado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udp: Se corrige la fuga de contabilidad de memoria. Matt Dowling informó de un extraño problema de uso de memoria UDP. En condiciones normales de funcionamiento, el uso de memoria UDP informado en /proc/net/sockstat se mantiene cercano a cero. Sin embargo, ocasionalmente alcanzaba 524 288 páginas y nunca se reducía. Además, el valor se duplicaba al finalizar la aplicación. Finalmente, causaba pérdidas intermitentes de paquetes. Podemos reproducir el problema con el siguiente script [0]: 1. /proc/net/sockstat informa 0 páginas # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Ejecute el script hasta que el informe alcance 524 288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Matar el socket y confirmar que el número nunca baje # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necesario desde v6.0) Desencadenar proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. El número se duplica # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577 La aplicación estableció INT_MAX en SO_RCVBUF, lo que desencadenó un desbordamiento de entero en udp_rmem_release(). Cuando se cierra un socket, udp_destruct_common() purga su cola de recepción y suma skb->truesize en ella. Este total se calcula y se almacena en una variable local de entero sin signo. El tamaño total se pasa a udp_rmem_release() para ajustar la memoria. Sin embargo, dado que la función acepta un argumento de entero con signo, el tamaño total puede volver a la normalidad, provocando un desbordamiento. La cantidad liberada se calcula de la siguiente manera: 1) Sumar size a sk->sk_forward_alloc. 2) Redondear sk->sk_forward_alloc al múltiplo inferior más cercano de PAGE_SIZE y asignarlo a amount. 3) Restar amount de sk->sk_forward_alloc. 4) Pasar amount >> PAGE_SHIFT a __sk_mem_reduce_allocated(). Cuando se produjo el problema, el total en udp_destruct_common() era 2147484480 (INT_MAX + 833), que se convirtió a -2147482816 en udp_rmem_release(). En 1) sk->sk_forward_alloc se cambia de 3264 a -2147479552, y 2) se establece -2147479552 en cantidad. 3) revierte el ajuste, por lo que no vemos ninguna advertencia en inet_sock_destruct(). Sin embargo, udp_memory_allocated se duplica en 4). Desde el commit 3cd3399dd7a8 ("net: implementar reservas por CPU para memory_allocated"), el uso de memoria ya no se duplica inmediatamente después de cerrar un socket, ya que __sk_mem_reduce_allocated() almacena en caché la cantidad en udp_memory_per_cpu_fw_alloc. Sin embargo, la siguiente vez que un socket UDP recibe un paquete, la resta se aplica, duplicando el uso de memoria UDP. Este problema provoca que la asignación de memoria posterior falle una vez que el valor de sk->sk_rmem_alloc del socket supere net.ipv4.udp_rmem_min, lo que provoca la pérdida de paquetes. Para evitar este problema, usemos unsigned int para el cálculo y llamemos a sk_forward_alloc_add() solo una vez para la delta pequeña. Tenga en cuenta que first_packet_length() también podría tener el mismo problema. [0]: desde la importación de socket * SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1 s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX) c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname()) datos = b'a' * 100 mientras sea verdadero: c.send(datos)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mvpp2: Prevenir la corrupción de memoria TCAM del analizador Proteja la memoria TCAM/SRAM del analizador y la información SRAM en caché (shadow) de modificaciones simultáneas. Se accede indirectamente a las tablas TCAM y SRAM configurando un registro de índice que selecciona la fila en la que leer o escribir. Esto significa que las operaciones deben ser atómicas para, por ejemplo, evitar propagar escrituras en varias filas. Dado que la matriz shadow SRAM se utiliza para encontrar filas libres en la tabla de hardware, también debe protegerse para evitar errores TOCTOU en los que varios núcleos asignan la misma fila. Este problema se detectó en una situación en la que `mvpp2_set_rx_mode()` se ejecutaba simultáneamente en dos CPU. En este caso particular, la entrada MVPP2_PE_MAC_UC_PROMISCUOUS estaba dañada, lo que provocaba que la unidad clasificadora descartara toda la unidifusión entrante, lo que se indica mediante el contador `rx_classifier_drops`.