Comment 11 for bug 591943

The flaw does effect actual physical NAT set ups as well... but to me it's more obvious that that set up exists, and that the NAT members are accessing privileges resources via the NAT router. With a VM, you click a few buttons, and the NAT is automatic and invisible, so you don't really know that it's happened.

I would however argue that the default for the SNAT and masquerading modules should be to NOT map to privileged ports, since that's really the root of this issue. If you're really in a situation where you have physical control over all the NAT participants, you can opt to open that up.

That would make the changes here a workaround, but push the actual fix to the kernel.