Pushing non committed work at end of iteration

Points are a strange thing to commit to. What commitments are described in the Scrum Guide?

It kinda feels like cheating

The situation you describe bears little if any resemblance to Scrum. It sounds more like a push-driven command-and-control waterfall process with agile go-faster stripes sprayed on.

If people are expecting Scrum outcomes from this then they are likely to end up being cheated. Can you find out who is committing this suspected fraud, and why?

Sadly, I do not believe Scrum means the same thing to many in my organization as it does to those of us who try desperately to adhere to it. :)

Dressing up the pig is rather accurate.

I would really like to offer a suggestion on this but like @Ian, I'm struggling to understand how Scrum even comes to play in this.  If you want someone to say it is not cheating according to Scrum.  Here ya go.

This is not cheating according to Scrum.

In reality, it sounds like you have some kind of process set up where developers work on things and push it to QA to test.  QA will push it back if there are any issues found.  If all the moons align with a designated date you have set for an "end of iteration", something will be merged into Master for a future date to be delivered. Even though you may use some Scrum terminology, you aren't using Scrum as it is described in the Scrum Guide.

Now, my non-Scrum response.  

Your company has a process that is driven by a date and not deliverables.  In those kind of environments, your current situation is pretty common.  The "crunch at the end" to get all of the stuff done that was not corrected understood at the beginning but an estimate was given or new discoveries were made while working to introduce other changes.  The estimates turned into deadlines, promises were made and now money is riding on the ability to deliver something. You honestly have no choice but to "do whatever it takes" to get the stuff finished.  This is a time to throw "rules" out the window and just work.  

But this is also an excellent opportunity to inspect history to see how you got into this situation, identify opportunities to help prevent it in the future, adapt to implement those opportunities, and then continue to monitor and adapt as needed.   (Hey, it's not a pure Scrum answer but I never said I'd avoid empiricism). 

Thanks and I totally agree, which is the frustrating part.

but i appreciate my feelings confirmed that this is more Scum than Scrum :)

Nah, it's not Scum.  It is Scrumbut.   "We do Scrum but we do this differently".