Code review is really good at finding certain types of bugs. If some unit test cases are missing, if you're not validating input parameters, if you're not checking for null or for an error condition, these are all easy that are easy to spot and just as easy to fix.
That last part is an often-overlooked attribute of code review: "easy to fix." And it's important, because a large part of the benefit of code review is in the fixing, not in the finding.
For example, when you discover you're not checking for an error condition in code review, it's often a matter of changing a single line of code. You know exactly where the problem is and the solution is often trivial as well.
Not so when QA discovers the problem, long after the code was checked in. Then you have to reproduce what they did, possibly with many more steps than are really required, hopefully able to simulate that error condition, then trying to run down the original cause of the problem (which might be far away from the code that dies or displays an error message), then fix it, then repeat this process to prove it worked.
And often someone other than the original code author is doing the fix, because at first it's not clear whose code is at fault. Which means someone less familiar with the code is having to dig through it and try not to break anything -- inherently more dangerous than if the original author made the fix immediately, while the code was still fresh in mind.
Code review isn't just about finding bugs faster, but fixing faster too.