Mis-estimates happen. Small variations in the accuracy of your estimates should be expected, and can be absorbed by your process if you aren't over-committing. However, large variations in accuracy or wildly inaccurate estimates are a process problem that should be addressed by the whole Scrum Team, including the Product Owner.
In addition, you may not have a well-articulated Sprint Goal. Managing estimates and backlog items in the absence of a defined Sprint Goal for each Sprint is an exercise in futility. Don't do that.
Identifying Invalid Estimates
A single Sprint Backlog item should never be sized larger than about 2-3 business days. The rule of thumb is that each task on the backlog should be "done" or "not-done" in 1/2 day to 2 days, so you should have a good idea within a couple of days whether a story is on track or not.
During the daily stand-up, stories that are slipping should be identified. In addition, your Sprint Backlog or Kanban board should clearly identify stories in progress that are stuck so that the team can address any impediments.
Scrum, like other methodologies, expects a certain amount of slack in your process to keep flow smooth. A slightly mis-estimated story can usually be absorbed without fuss, but wild miscalculations require more disruptive techniques to manage them.
As an informal rule of thumb, if your Sprint burn-down is out of whack by more than 30%, or if you have a single critical-path story that's more than 50% over estimate, then it's probably worth escalating the matter. Even if the team recovers from the miscalculations during the current Sprint, it should be grist for the mill at your next Sprint Retrospective.
Handling Invalid Estimates
An improperly-estimated story should be identified within 2-6 business days. Allowing a task to slip 200% without triggering some action or awareness within the team would just be silly.
At that point, you should:
Determine whether the story is essential to the Sprint Goal.
If not, discuss pulling it from the current Sprint with the Product Owner. You can do this together so long as it doesn't compromise the Sprint Goal.
Re-estimate the task.
If the story is essential to the Sprint Goal, you should take 10-15 minutes with the team to re-estimate the story to determine if the story can fit within the current Sprint, with or without changes to the Sprint Backlog.
Add capacity by trimming other scope.
If your story is essential, but you have other stories that aren't, the Product Owner can eject the non-essential stories to trim scope. In addition, you may be able to trim scope from a variety of Sprint Backlog items without compromising the Sprint Goal.
Request an early termination of the current Sprint.
If the story is essential to the Sprint Goal, and sufficient scope can't be trimmed to finish the story within the current Sprint, then you should request that the Product Owner call an Early Termination to the Sprint, followed by a Sprint Retrospective and a return to Sprint Planning.
Formally Re-Estimating Unfinished Stories
Any story that is not done by the end of a Sprint is returned to the Product Backlog for disposition by the Product Owner. The Product Owner may de-prioritize or re-scope the story, remove it from the backlog, or may choose to put it back at the top of the Product Backlog for inclusion in the next Sprint.
If the story remains in scope for your next Sprint, then it should be re-estimated and decomposed again during the Spring Planning process, just like any other story. Hopefully, the Scrum Team will have a better handle on it the second time around, and the estimates and decomposed tasks should be more reliable.
If a story makes the rounds a third time, then you have a bigger process problem than a single mis-estimated story. Fix that.