Thread (5 messages) 5 messages, 4 authors, 2026-02-25

Re: [PATCH net-next] net: stmmac: ptp: limit n_per_out

From: Simon Horman <horms@kernel.org>
Date: 2026-02-24 11:30:01
Also in: netdev

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:
quoted
On Mon, Feb 23, 2026 at 12:20:47PM +0000, Russell King (Oracle) wrote:
...
quoted
quoted
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@kernel.org>

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help