Whereever I have worked in software development, there was always an equivalent of a backlog, always a list of bug reports, and always someone responsible for the priorities (an equivalent of a PO), so your question, though it uses Scrum terms, is IMHO far from beeing restricted to Scrum.
A quick google search for "scrum backlog bugs" revealed that some teams separate bugs / issues from "new feature" stories, other's don't. Sometimes issue trackers are used, sometimes a Wiki, sometimes everything goes directly into the backlog, etc., and there is no consensus "which is better". So the first thing you should clarify in your team how you want to handle this, what does your team want to see in the backlog and what not, and what does your team think will work best for your case.
If you made the experience that if everyone is allowed to add anything to the backlog messes its up, it will probably better to separate user stories from bugs. The requirements how a good bug report should look like are probably different from the requirements how a good user story for a new feature should look like, which might be another reason, too. Nevertheless both will end up in tasks for the developers, which might be a reason to keep them in one place.
However, for most products it makes sense when bug reports can be given by anyone (users, testers, developers, marketing people, whoever notices a potential problem). "New features" should probably be discussed with the PO as part of the process when adding them to the backlog. Your PO should decide if he wants to put the stories into there by himself to do some editorial work beforehand, or if anyone can put the stories to the backlog and he does the editorial work afterwards. But for bugs, especially the ones which look severe to the reporter, there should be no discussion needed to add them to the issue tracker, or backlog or buglist document, or whereever you keep them. "No discussion" does not mean to put the bug report anywhere silently, quite the opposite. When a bug report is added, and the reporter thinks it is probably not a minor one, the PO (or whoever is responsible) must get informed.
As a final note: to make the right decision for your team how to manage this, it makes quite a difference what size your product has, how many people are going to report bugs and new stories, and if you get one but report per week, a dozen or several hundred.