I've seen this handled a few different ways. What you do is going to depend on the size of your team and your current business context. Like the rest of engineering, there are few hard and fast rules, you have to weigh the trade-offs.
One approach is to prioritize all bugs before all features. This is the Joel Spolsky approach. In a typical sprint-based environment, this basically means that available work effort is allocated to bugs, and only remaining work effort is allocated to new features. The Google SRE model (as I understand it) tries to moderate this by basically saying the team has some flexibility in work allocation between bugs/features unless certain SLOs are missed. When that happens, you go full Spolsky.
But that doesn't really address the "what if a critical bug comes up mid-sprint". To address that, you basically adopt an on-call support model. Each sprint, one (or more, or a half, etc.) are assigned to be the support person. They triage any issues or bugs and address them as best as possible. It really helps if there is a rotation, just like your operations on-call rotation. In fact, it's best if you view this as the "escalation level" from your operational on-call rotation. You can provide a similar resource for marketing or other kinds of events as necessary. The benefit is that you have an up-front acknowledgement of the level of investment needed for responsiveness, as well as being able to provide folks with periods of interruption vs. periods of deep work, and share that burden.
Lastly, I think it's really important to separate "release" from "sprint completion", especially in a SaaS environment. If you build your CI/CD and release processes around releasing at the end of the sprint, you end up building a very inflexible infrastructure. It's much better if you can release often, as work is completed. So, if you have a small feature ticket and you tackle it early in the sprint, ship it right away. If a bug comes up, release the fix as soon as it's available. I've been on too many teams where you have an inflexible release process tied to the sprint. When something comes up, it interrupts the whole flow to get something done. So, "end of sprint" != "big release".