[PATCH net-next] net: stmmac: ptp: limit n_per_out
Simon Horman
horms at kernel.org
Tue Feb 24 03:29:48 PST 2026
On Tue, Feb 24, 2026 at 10:02:02AM +0000, Russell King (Oracle) wrote:
> On Tue, Feb 24, 2026 at 09:26:29AM +0000, Simon Horman wrote:
> > On Mon, Feb 23, 2026 at 12:20:47PM +0000, Russell King (Oracle) wrote:
...
> > > This could be a user exploitable bug (although one has to be root
> > > so the gun is already pointing at one's foot.) This is the commit
> > > which introduced the problem:
> >
> > Hi Russell,
> >
> > From the description I assumed that for this problem to manifest
> > out-of-range values would need to be turned by hardware.
> > But maybe I misunderstand things.
> >
> > Could you elaborate on the vector you have in mind?
...
> Either code should care about values > 4, or it shouldn't. The current
> code cares about it in one place but then ignores it in all other
> places where the index is under userspace control, allowing the
> potential for array overrun.
Hi Russell,
Thanks for the clarification.
Personally I think it would be best if the Kernel took a robust approach
and assumed that hw may provide out of range values. But in my experience
this is generally not the approach taken by drivers. And it's not a hill I
which to spend too much time occupying.
IOW, I don't think the current practice is to treat such cases as bugs.
On the other hand, I agree that the code should be consistent.
And I would lean towards verifying rather than not, although again,
I don't think that one can find plenty of cases where the Kernel
doesn't do that.
Which is to say that I agree with the approach taken by your patch.
But I lean towards it not being a fix.
Reviewed-by: Simon Horman <horms at kernel.org>
More information about the linux-arm-kernel
mailing list