I would hope that by now you would have frozen scope as you have cited new requirements entering at the testing stage as a problem. That has to stop otherwise you are in an endless cycle.
Once you have stopped the scope creep there are a number of areas you need to look at. But the one that leaps out at me is System Testing. If the users are finding issues in UAT that presumably means you didn't find them in system testing? No matter where you find them, the bugs are there, but it is preferable to find them (and fix them) before going into UAT. I would start measuring the number of issues found during System Testing and during UAT so that you have a quantitative picture. Then strengthen your System Testing; do more of it, use more (or better) testers, work from proper test scripts, make sure you have the right amount of test coverage (i.e. you can't test everything so make sure you are testing the areas that are right for your users in as much depth as required to assure quality in those areas).
Make sure that in each cycle of UAT all applicable test scripts are exercised. Don't let the users just stop testing just because they found an issue in one area. Make sure they test the other areas.
Introduce Regression testing into your system testing to some extent- For every release go back and re-test work that has already be validated and do it before the users see it.
Track the issues situation on a daily basis. Log everything and make sure you have prioritised the issues list (on a daily basis if necessary) so that the developers are focussing on the most important issues.
Grit your teeth, put your head down, and just get through it :) This can be hard, but if issues exist in the system you just have to keep going until everyone is happy that the release can go out (i.e. not necessarily when all the defects are fixed!). But be sure to make sure you are not making it worse by changing code during testing, other than to fix issues.
Lastly, after the dust has settled, take a long hard look at the process to try and figure out how and why the output was not of sufficient quality and try, as an organisation, to learn those lessons for next time.