That's somewhat different from the Veracrypt case, afaict. And it doesn't seem like this is what bonzini meant by mentioning sudo.

You still need to gain the privilege to mount filesystems in order to exploit the flaw. So it is a privilege escalation in that you can go from "sudo mount" to a root shell, but it is: 1) not exploitable unless you have sudo 2) pointless if you are authorized to "sudo" any command.

This depends on the setup really; it's possible to limit sudo access to only some commands, like so:

  %veracryptusers ALL=(root) NOPASSWD:/usr/bin/veracrypt

An inexperienced systems administrator might use this to allow some users access to the mount command so that users can use their encrypted USB drives to carry around sensitive data, not realizing that through the intricacies of the Linux filesystem this can lead to privilege escalation.

Such a config would normally give you sudo, but not a root shell; allowing certain users to use ping floods to test the network by giving them access to the ping command as root, for example, would not expose much security risks other than flooding the network.

I see now that you consider sudo necessary for mounting the filesystem, but

a) it seems the point in the report is that Truecrypt allowed to grant this ability without using sudo (I guess either via a daemon or just a setuid executable)

b) iirc in case of other filesystems you can allow users to mount them without being root—which is how removable devices work in unixes. So this goes around the whole sudo/setuid system and probably might be another option for this feature in Truecrypt too.

Lastly, as jeroenhd noted, even with sudo the root privilege can be granted for a script that mounts a volume, or for one particular command. Sudo, by default, doesn't allow the user to add options to the command specified in `sudoers`.