Sprint Planning takes too much time on reviewing detailed tasks

The first thing I would cut out is the estimation of each task. In my experience it is a lot of time allocated to something that doesn't provide real value.  You have already made the determination of how many stories you can do to achieve the Sprint Goal, so stop discussing it in infinite detail and start working. 

Next thing is the Sprint Goal.  Not once did you mention it.  It should be driving all of the decisions made by the team as to what items to have in the Sprint Backlog and how the team should divide the work. It should also be used by the team to monitor progress. 

Third, if the team plans to this detail during Sprint Planning, what do they do in the Daily Scrum?  The purpose of that event is for the team to discuss what they have learned and then plan the work until the next Daily Scrum.  Planning to the detail you describe doesn't lead any opportunity for discovery and adaption as the work progresses.  

I would suggest to the team that an experiment be run where for the next Sprint Planning only enough tasks to keep everyone busy until the next Daily Scrum be scoped.  Each day the team can discuss the work for the next day based upon what was done the previous and any information discovered.  It will be difficult at first but have them try it.  See if they find it easier and more effective.  If not, inspect why and adjust your activities accordingly.  When they ask "how will we know how close we are to being finished" or "how do we report the status to the Product Owner/Manager/Team Lead/etc?"  you will respond with "not sure but we can figure it out by talking to that(those) individual(s)".  

Get the team into a mindset of working incrementally even to the task level and stop them from trying to plan.  It sounds like you are building a Microsoft Project plan instead of managing a Sprint Backlog. 

Currently, Sprint Planning event of my team almost exceeds the timebox defined (12 hours or more instead of 8 hours). The reason is that the Team spends a lot of time reviewing detailed tasks.

How much of that planning effort is wasted? If their detailed plans are right, and there's little change or emergence, is this really a complex product they're working on with many unknowns?

I agree with Daniel that the first change I'd suggest is removing task estimation. If you are estimating, you should be estimating as part of Product Backlog Refinement activities, which should produce enough well-refined Product Backlog Items for at least a Sprint or two. You can also begin to do task breakdowns as part of refinement to help you estimate, or at least check the size of a Product Backlog Item to ensure it can be done within a Sprint.

Then, I'd suggest focusing on just enough task breakdown to give a reasonable forecast of work that is highly likely to be accomplished by the team over the next Sprint, recognizing that more work may emerge and some work may be found to be unnecessary. What it means to do "just enough" or give a "reasonable" forecast or the likelihood of meeting the goal or achieving the forecast depends a lot on the context, as some organizations are more tolerant or deviations than others.

I think if you make these two changes, you can well within the Scrum Guide's specified timeboxes. Personally, I've found that if the team is performing sufficient Product Backlog Refinement and the Product Owner and Developers are able to collaborate and define an appropriate Sprint Goal, Sprint Planning becomes a very easy activity. I'd just keep in mind that the intent is not to create a highly detailed plan for the Sprint. Since we're working in a complex and uncertain environment with ambiguities, you want to reduce those uncertainties and ambiguities just enough to meet your desired confidence threshold and let the details emerge throughout the Sprint, using the Daily Scrum to align the team.

There is a simple answer for this question.

If you will do proper PBR ( Product Backlog Refinement ) then 100% you will be able to reduce time in the Planning meeting.

So, Whatever stories you will take in a sprint must be discussed properly in the PBR and as you know we are doing story point estimation( planning poker) in PBR also. So, PO will explain stories in PBR and the team will give story point estimation based on complexity, amount of work, risk, dependency etc. Here, the team is doing clarification of the stories. 

Now, on the sprint planning day, PO/Team Leader doesn't have to explain all the stories again in detail ( because it already discussed in PBR) . Instead, PO will explain stories one by one and the team will split stories into tasks and the team will give hours to those tasks. 

Note: also Sprint Planning activity depends on the length of the sprint ( 1 week, 2 week, 3 week etc. )

Suggestion: Just try to improve your PBR session and make sure that the team is writing all the acceptance criteria for stories over there by proper discussion.