You should not have stabilization sprints. Your software should be releasable every sprint. This means that if you need stabilization, that has to happen within each sprint and not just before a release. Once you achieve this, release planning becomes a product owner concern ("What features to I need in order to release?") and stabilisation a team concern (definition of done).
The same applies to bugs and technical debt: it's stuff that is always fixed, as needed and does not require stories -- in fact, it's normally part of each story: it can't be "done" unless it's stable and properly refactored.
I realize that this does not answer your question directly, but stabilization is not an agile concept at all, so it makes no sense to ask how to do it with Scrum.
Edited to address comment:
According to Scrum, bugs found pre-release are to be handled within the iteration. A story is not normally considered "done" if it has bugs. If you can't ship it, it does not have value. Also, according to basic Agile principles, teams should work at a sustainable pace. If you need to basically stop development in order to address debt or bugs, then you are not working at a sustainable pace. Decrease your velocity, ship less features, but without bugs.
Usually stabilization happens in teams that have a separate QA team checking features post hoc. This does not fit in the Agile or Scrum model. Teams should be cross-functional and able to ship a feature independently.
Overall the thing is, many companies say they do Scrum or Agile without understanding the deep changes it entails in the way software is built. If you are not prepared to build software according to these methodologies, don't use it as a "management add on" on different practices.