Bug Only Sprint?

Are there are formal processes for a bug only sprint?

It's work which remains to be Done, and which therefore ought to be accounted for on the Product Backlog. There's nothing to stop a team from having a Sprint Goal in which work of that type is mitigated.

Obviously it would be good to have no bugs in the project, but I'm falling short of definitive arguments as to why we need to get to this state.

Defects don't happen through chance or misfortune -- they arise because the Definition of Done is ineffective.

The Developers are accountable for ensuring that work is of Done and usable quality. I'd suggest that there is no argument to be made: this is a matter of professional accountability.

What is the team doing to improve the DoD, so when the Developers meet it each Sprint "bugs" are not introduced?

Has anyone else had a bug only sprint? Has anyone had success making such an argument to the product owner? 

The Product Owner is not accountable for quality, the Developers are, and the PO ought to respect this without argument. The Developers for their part ought to plan enough time into each Sprint to assure that a Done standard of quality is met. Their remaining capacity for planning in new work will reflect this commitment.

The Product Owner is accountable for "maximizing the value of the product resulting from the work of the Scrum Team". Focusing exclusively on bug fixes may or may not be the best use of the Scrum Team's time and energy, with respect to maximizing the value delivered in each Sprint.

You don't need to resolve the 50 reported and open bug reports to get to a state where all identified bugs are resolved before the next release. You can do this by working with the team to enhance the Definition of Done. Since the Definition of Done is "a formal description of the state of the Increment when it meets the quality measures required for the product", you can make a statement that a quality measure is "no known newly introduced defects exist in the product Increment". Some teams call this a zero-bug policy. However, it goes back to maximizing value - there are some bugs that are so rare, so easy to work around, or have such minor impact that the cost of fixing them often doesn't outweigh the value of delivering some other piece of functionality.

It would be a good use of a Sprint Retrospective to spend some time talking about how to prevent the release of Increments that contain new defects and how the Product Owner considers the value of fixing a defect. Value is not just to external stakeholders, but to the Scrum Team as well, so there could be opportunities for the developers to express the value in fixing a defect for consideration.

Everything that @Ian and @Thomas said echos my opinions.  You are in this position because the Developers are focusing on finishing stories instead of delivering quality. 

I'm going to share a Product Backlog management technique that has served my teams well if they ever find themselves in this position.  The Scrum Guide defines Product Backlog Items.  It does not distinguish in types of items.  Just a list of items.  So I suggest that you stop viewing things as bugs, features, stories, tasks, etc.  Just see everything as a piece of work that has to be done in order to improve the product.  I even go as far as to quit using the different item types you have in the software you are using to track these things and just make everything the same type.  To justify this I explain that everything in the Product Backlog has 2 values.  Negative value as long as it is in the backlog, positive value when it is in an increment.  This holds true for features or bugs.  The idea is that the team should be adding as much value to the product as possible.  Take a group of items from the Product Backlog into a Sprint Backlog that will support the Developers in reaching the Sprint Goal.  And the Sprint Goal should be stated in the value that is being incorporated into the increment.  Not something like "Finish feature A" or "Fix these 12 bugs".  What value is added to the product when the selected items are turned into positive value? 

There is nothing like "Bug Only Sprint". As Daniel mentioned, bugs are just items to work on the particular Spring. Scrum team decides the items for the Sprint based on the Velocity (a measure of the amount of work a Team can tackle during a single Sprint). I had some Sprints in past where we handle only the bugs as we had to deliver the releases with resolving the bugs. So, this is not an un-usual scenario.

I really appreciate all of the feedback provided here. I've been getting some feedback from my fellow developers on the team that they wouldn't love a bug only sprint and I can respect that sentiment. I'm going to propose the following two ideas to my team during the next sprint retro:

1) Every sprint planning has at least 2 bugs brought in from the start. Like which two are the Product Owner's highest priority. I think this will provide valuable input from the Product Owner on which bugs they believe would provide the highest value to the project at the time. 

2) We have weekly backlog grooming time. Usually we simply talk about any new bugs adding simple comments on them. The typical time is very inefficient with a lot of casual conversations. Sometimes we actually go into the ticket further, debugging or team programming the solution. I am going to suggest that we always maximize that time by reviewing all the new bugs, and then collectively working on one or two. I suspect this will have additional benefits by creating an opportunity for team members to learning from others project knowledge and development styles. 

Thank you again for the feedback and additional perspectives on this idea!