These are some nasty implementation bugs, but honestly, there are some way more serious design issues at hand here.
A user-configured VPN should not run as root and affect networking for the entire system; the whole VPN process should run in its own network namespace with no more privileges beyond those of the user activating it. Processes that need to use the VPN (rather than clearnet) should be attached to that same network namespace. If necessary, you can even avoid attaching a NAT (e.g.: slirp4netns) to the namespace so that if the VPN dies there is no data leakage.
I get that running things as root has a bit more performance, but compromising on security for the sake of performance doesn't sound like the right approach for this kind of software.
I can't imagine that root is any faster. It's just a lot easier to run things as root vs splitting out separate processes with their own isolation mechanisms.
That the service runs as root isn't really the issue here. None of the attack relies on the abuse of some root capabilities, it's an authentication issue that abuses how the service works. Even if it were unprivileged somehow, this would still be the same impact.
Even with netns you'll need to run some parts as root, so you'll need to use privsep. Network namespaces are a really cool Linux feature, they're great for using multiple VPNs for different things. But for the average user, I'm not sure if netns has great integration with common desktop environments and it's on the user to make sure they don't accidentally run their program in the wrong/default network namespace.
Yeah, because it affects networking in the entire system.
If some pam session module were to set up its own network namespace that is shared by all user processes after login, this could be (mostly) solved. The result would be some surprising behaviour though, as processes outside have a possibly vastly different view of the network.
A user-configured VPN should not run as root and affect networking for the entire system; the whole VPN process should run in its own network namespace with no more privileges beyond those of the user activating it. Processes that need to use the VPN (rather than clearnet) should be attached to that same network namespace. If necessary, you can even avoid attaching a NAT (e.g.: slirp4netns) to the namespace so that if the VPN dies there is no data leakage.
I get that running things as root has a bit more performance, but compromising on security for the sake of performance doesn't sound like the right approach for this kind of software.