If you're asked to review code, you do it to the best of your knowledge. If you are not able to comment on certain aspects because you don't feel knowledgeable enough about the code base, say it.
It's actually a good opportunity to learn about the code base.
In any case, your team knows that you are new and won't be able to comment in depth and they probably also see this as a training exercise for you.
What is important exactly in a code review depends on the team. But generally, the same items are reviewed:
* Are team conventions applied?
* Can another understand the new code?
* Is code resolving the issue?
* Can I think about a better code? Something to refactor?
Even two juniors can ask this questions and try to answer them.
If the reviews are too large/complex for you to grasp, that may mean that: * either it's not focused on one specific topic, so it should be split up, * either it's actually a more complex issue you'll need to dive together in to grasp it (back to the drawing board).
Depending on the code base: * if you can plug a cross reference tool (such as https://lxr.sourceforge.io/ or anything that suits you), that will help to jump from one place to an other * if there are tests (hopefully), check if you have a test coverage report (or set it up). That's good info to have too.