Agile Methodology

What agile "methodology" is your question about ... many use the term srpints now.

Is your customer the Scrum Master for your project , why would you change sprint durations, why do you need a sprint just for bugs, ?

Forum / Scrum.org
Discuss issues relating to Scrum.org including assessments, programs, classes, and any other aspect of the organization

How long are your sprints typically?

One of the big things with Scrum is consistent sprint length, so I would recommend against executing a shorter sprint.

As far as bug fixes go, my team typically builds them into our sprints. For example, each sprint we'll have one or more stories that are bug fixes. We treat those just like any other story, we point them, and plan them during sprint planning. I'd try to advise your customer that you can keep the same sprint duration, and still work on the bug fixes. Of course, they wouldn't see the results until the end of the sprint (which may be what their concern is, they want the bug fixes asap).

Are you looking in to the root cause of the bugs? Each Sprint should deliver a slice (increment) of code that is potentially releasable - meaning it has been tested in isolation and tested integrated in with the app. Hopefully these bugs weren't "happy path" bugs which should have been caught using the Acceptance Criteria.

Please let me know if this approach is right or wrong ?

To be clear, it is wrong. Your increment is not potentially shippable, which means either your team does not fulfill the definition of done or the definition of done is not complete. What your customer thinks is, that you are doing a project and there is a stabilisation phase in the end. This almost never works. What you really can do:
1. find the root causes of the bugs and eliminate them by adjusting the definition of done and enforce it as the law. From remote, my first guess is do excessive testing within the sprint.
2. Maybe you can reduce sprint length generally, so your client does not have to wait that long. This is up to you.

Few of points to be noted here:
1. In Scrum, the Sprint duration should NOT change. If it changes, then it would become difficult to calculate/predict the velocity.
2. The customer needs to be educated about Agile and Scrum
3. The bug fixes also can add as increment. It is basically clearing the debt. The sprint end deliverable will be the functionalities with bugs fixed. Meaning, some functionality which was not working earlier is now fixed and delivered.
4. The bugs need to be prioritized before they can be taken for fixing.
5. If the number of bugs are too many to fix in a sprint, then pick only the top few prioritized defects.