This is my second answer to this question, which attacks it from a different angle:
The PO tells us that understanding it [the spreadsheet? data modeling task? story?] is the goal of this sprint.
- this isn't a proper sprint goal.
- the PO can't unilaterally set the sprint goal, it's decided by the PO and the team.
- taking a single story for a whole sprint is ridiculous.
- taking a story that hasn't been properly groomed is ridiculous.
Your Scrum process is broken. This is a problem that can easily be solved by a trained and experienced Scrum Master, who has various options such as delaying the sprint planning and use bug fixing as filler, or to convince the PO to start a Spike.
Making sure what happened does not happen is one of the primary functions of a Scrum Master. It seems like a law of nature that POs will occasionally try to pull stuff like that - that's why the Scrum Master is present in the sprint planning and has the authority to easily stop the PO.
Unfortunately, you say your Scrum Master refuses to take action. No matter how nice they may be, this is their job, even if they don't like it, it's what Scrum Masters get paid to do. Make clear to your Scrum Master that this is an impediment and you expect them to help you in getting rid of the impediment. If they don't, they are the problem. This is from the perspective of someone who used to be a Scrum Master himself a couple years ago.
You can mention this to upper management by focussing on the fact that the stories are not properly prepared. Well prepared stories are understood by the team, estimated by the team, and small enough that the largest story should normally take less than half of the sprint's capacity. Don't assign blame to the PO, because competent upper management will realize that this is a Scrum Master issue. We have to assume you have competent upper management, because otherwise you're screwed, seeing how lower management isn't competent yet.