Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.
This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner's discretion.

Getting feedback from Stakeholders is a crucial activity in Scrum. Working with stakeholders frequently ensures the team to focus on the right things to build. Although it is required to have Stakeholders at Sprint Review, they can also engage with the Scrum Team during Product Backlog Refinement, Sprint Planning or during the Sprint if the Scrum Team requires it.

Explanation/Reference:
Explanation:
One of the principles of agility includes working closely with business people. In order to manage stakeholder expectation, there must be open communication (through collaboration and transparency) throughout the project cycle. This maximizes alignment, helps with making business decisions, and reduces risk.
Although, the Scrum Guide does not directly state that the Scrum Master is responsible for ensuring transparency it is implicit. The Scrum Master is responsible for the process in which Scrum is adopted and enacted. Scrum is founded on empiricism and the Scrum Master helps those inside and outside the team work in an empirical environment which includes transparency (one of the three pillars of empiricism).

Product Backlog items should be clear enough and have enough information for the Product Owner and Development to understand the work that needs to be done and to create a forecast of Product Backlog items to implement the Sprint Goal. Nothing stops the flow of Sprints, for example, we do not delay the Sprint because the items are not ready. In such cases, the "unready" items would be selected for the Sprint anyway and refined during the Sprint.
In the case that the Product Backlog items are not clear enough, the Development Team forecasts the most likely Product Backlog items to meet the goal and create a Sprint Backlog based on a likely initial design and plan. Once the time-box for the Sprint Planning meeting is over, start the Sprint and continue to analyze, decompose, and create additional functionality during the Sprint. At the end of the Sprint, the Scrum Team can discuss in the upcoming Sprint Retrospective why this happened and what changes will make it less likely to recur.