Yeah, don't use this anti pattern (generic repository wrapping DbContext while exposing EF entities). If you really want to use the Repository make the repository interface return ONLY business (or view models if it's a query repo) objects, never IQueryable or other details exposing EF or whatever are you using.
Simply put create a repository for your NEEDS, forget about generic stuff it's an anti pattern. So your CatalogRepository will use a DbContext to issue all the queries needed, then assemble a view model/business object from the results and returns that.
The app will know only about the Repo, never about EF. The queries will remain at the DAL level (not in your app/service/controller) and your app is decoupled, Separation of Concerns is respected.
A class wrapping DbContext is at best useless (what value does it bring?) and at worst a leaky abstraction. Make your life easier, if you want to work directly with EF entities and EF, work directly with EF. If you want to decouple the rest of the app from persistence details (note I've said persistence, not rdbms) use Repository properly. But don't kid yourself you're using the Repository pattern just because you have a class named repository. You should know exactly why are you using a pattern and what benefits it brings to your situation. It's not best practice if you don't understand why.