There's nothing wrong with this at all, though if you have a method that does nothing but call another method it might be worth seeing whether you can get rid of the intermediate method.
Is that the thing that you're implicitly trying to ask about?
If so - there are plenty of reasons you might want such an intermediate method.
For example, maybe
a is public but
b is private. Or maybe
b is a placeholder and will get more code added later.
[EDIT to address the more specific example]
No, this is totally fine and not an antipattern at all. Each method is just a named thing you want to do, and some of those things may require data from further up the chain of things you're trying to do.
Say you're trying to calculate the volume of a cylinder. The formula for that is
(pi * radius^2) * height. You could define a class
getCylinderVolume(radius, height) that just returns the result directly.
But say you decide that you want to extract the "multiply by the height" piece of that (say, because you want to warn the user that the thing whose volume they're calculating will exceed a legal height limit). You might then change
getCylinderVolume's implementation to instead return
getCircleArea(radius) * checkHeightAndBubbleErrorIfTooTall(height).
You might also realize that you need to account for interior and exterior volumes separately...
The point is that there are plenty of reasons you might want to keep passing a variable straight down a call stack. Doing so often means that you're doing a good job of keeping your functions small.