All the answers so far, are good ones. But they are not put together as I would suggest.
@nvoigt is spot on,pretty much. Do not be an enabler. Do not prevent feedback arising. Do not take on every job that someone else abdicates, as your job. Do not paper over cracks, or act in a way that you cannot sustain, if it becomes "the normal". Even for best intentions.
But that isn't the whole of the answer, for me.
You have two priorities. First, to attempt to get this fixed, so the problem is resolved. Second as you rightly say, not to get blamed totally, if it isn't resolved.
That project manager is answerable to someone. That person needs to know what's going on. The project as a whole is answerable to someone (above or beyond you). That person needs to know what's going on.
Those are the people who have decision making power over the problem. Of they don't, they are still the people who decide whether to escalate it or not.
Your job is to do your job. If your job is perceived as making the project succeed, then you need the right tools and they need to work well. A productive effective PM is such a tool. If secretly, you don't have one, and that's impacting the project, it isn't your decision what should happen. Managers may decide to talk to them, fire them, support them, change peoples tasks or roles, formally give you more control, or indeed (as sadly often happens) ignore it until it goes boom, then wonder what happened. Which of those is right, is not your executive role to decide.
Your job therefore is to make those 1 or 2 individuals aware, that your PM is not effective, and its impacting the project. Present your documented evidence of the issue. Then ask them what they would like you to do. Then do it.
Its for that reason that nvoigt and David R, are both right. Document it. Both to cover yourself, and to present strongly about the issue. What you document are incidents that show the problem behaviour, and the impact on the project - which should not be just "so I did their job for them". Consider what motivates those people - deadlines, profit, team motivation, customer quality, whatever it is. Make sure your presentation isn't about poor you. Its about how there is a problem, and it's impacting the things they care about - or risks doing so. If you can, come with 2 solutions and their cost/impact/feasibility, to help solve it. Imagine they asked "So what do you want" or "What do you think we should do".
Additionally, allow the failure to happen. If they don't project manage, there will be an impact. Document it. Your role is tech lead. "Our teams PM isn't PMing, and this was today's fallout. Its not the first time, by a long way. We need this solved,or we.risk missing deadlines/profit/bug costs/reputation/whatever." If team members need tasks, or whatever the PMs job is, tell them to talk to the PM, sorry, that's his job, mine is tech lead. Tough, and people will push back, but do it anyway. Set boundaries! A key skill.
Do not take it to HR directly. Again, that's not your call. You have been given a job to do, by someone in tech, the PM has been given their job to do by someone in tech, the issue is tech management of its team. The person/s responsible, their call is whether or not to go outside tech. The only exception I can see is if the top person in tech isn't doing their job, in which case ask to meet someone even higher - and be very very sure of your ground. But HR is still the wrong place for your angle on the PM, which is about tech tasks not done, not their employment status.
Also, as Mike Robinson says, talk to the PM - and listen! If you escalate this, and never talked or listened to them, they will feel strongly that you were high handed. Give them a chance to explain the issue. You depend on them, what went on when X happened? And Y? Use that and think hard what to make of it. It may change nothing. It may influence what you present as "the problem" or "my recommended solution/s", or how you shade them.
Last look up the many excellent posts here about how to document a problem, raise it, and protect yourself. Put things in email, and after meetings email thanking them for their time, and noting the outcomes or what they said that's important.
If they said something that seems a problem, "I understand you feel this is not an issue, and do not plan to take action. I am concerned this is underestimating the impact on the team, its work and our deadlines, and our efficiency. I draw your attention to the following impacts I mentioned at our meeting, that have already arisen. Before dropping it, I'd like to check for my own professional certainty, are you sure that you wish me to do nothing, and that the situation is to be left as it is?" Or wording like that. Document that its a concern to you, but that having raised it, you defer to their decision. Document so that both parts are clear - that you definitely raised it, and explained the effect, and they definitely made a decision that you followed.
Last, if they imply or say that you need to do both your job and someone else's (or part of someone else's), then of course, you are only one person. If you take on another half role, then your designated work will take twice as long. Again, that's their choice, if you feel it will impact your work, then same as above. "I understand that you feel I can fit project management into my workload. I'm not comfortable that this can be done without considerable impact to my own work - which as we discussed is a full workload in itself. I can do either my own work 100%, or my work to a lesser extent and part of someone elses - which I may also be less well trained for. If its more important to cover for project management at a cost to my own workload, then I hope this will be speedily resolved so that my own work suffers for as short a time as possible. I would like to review the situation in a month if that's the case, to assess if it's working acceptably." Then document if it isn't, or the impacts. Do not be tempted to be pressured to compensate by extra unpaid hours.