Vulnerabilidad en kernel de Linux (CVE-2023-53076)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Ajuste insuficiente del valor predeterminado bpf_jit_limit Hemos visto informes recientes de usuarios de AWS EKS (Kubernetes) como el siguiente: Después de actualizar los nodos EKS de v20230203 a v20230217 en nuestros clústeres EKS 1.24 después de unos días, varios de los nodos tienen contenedores atascados en el estado ContainerCreating o las sondas de actividad/preparación informan el siguiente error: Sonda de preparación con error: error de rpc: código = desconocido desc = no se pudo ejecutar en el contenedor: no se pudo iniciar el ejecutable "4a11039f730203ffc003b7[...]": OCI runtime exec failed: exec failed: cannot start container process: cannot init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524: unknown Sin embargo, no habíamos visto este problema en las AMI anteriores y El problema solo comenzó a ocurrir en la versión v20230217 (tras la actualización del kernel 5.4 a la 5.10), sin otros cambios en el clúster subyacente ni en las cargas de trabajo. Probamos las sugerencias de ese problema (sysctl net.core.bpf_jit_limit=452534528), lo que permitió crear contenedores y ejecutar sondas de inmediato. Sin embargo, después de aproximadamente un día, el problema reapareció y el valor devuelto por cat /proc/vmallocinfo | grep bpf_jit | awk '{s+=$2} END {print s}' aumentó de forma constante. Probé el árbol BPF para observar los tamaños de bpf_jit_charge_modmem y bpf_jit_uncharge_modmem, así como bpf_jit_current bajo el filtro BPF tcpdump, BPF seccomp y programas nativos (e)BPF. El comportamiento parece sensato y esperado, sin ninguna fuga de datos desde la perspectiva del servidor. El control bpf_jit_limit se añadió originalmente para evitar que las aplicaciones sin privilegios que cargaban programas BPF (por ejemplo, políticas BPF seccomp) consumieran toda la memoria del módulo mediante BPF JIT, impidiendo así la carga de módulos del kernel. El límite predeterminado se definió en 2018 y, si bien era adecuado en aquel entonces, hoy en día vemos muchos más consumidores de BPF. Ajuste el límite del pool BPF JIT de 1/4 a la mitad del espacio de memoria del módulo para reflejar mejor las necesidades actuales y evitar que más usuarios se enfrenten a problemas potencialmente difíciles de depurar.