From: Greg Kroah-Hartman
> Sent: 14 October 2024 15:20
>
> 6.11-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Oliver Neukum <oneukum@xxxxxxxx>
>
> commit 71c717cd8a2e180126932cc6851ff21c1d04d69a upstream.
>
> This reverts commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035.
>
> This patch leads to passing 0 to simple_read_from_buffer()
> as a fifth argument, turning the read method into a nop.
> The change is fundamentally flawed, as it breaks the driver.
This failed my mail filter rules (don't ask...) so I read it.
The patch clearly broke the code, but it is pretty horrid.
A quick scan shows a CMD_LED of length 1 send uninitialised stack.
dev->bbu is usually 40 bits max, except when it is initialised to -1
or when a very large integer is supplied (c2 isn't masked).
Never mind the strange locking across slow operations.
There is pretty much no point holding a mutex across a copy_from_user()
into an on-stack structure.
...
> - if (WARN_ON_ONCE(dev->bbu > S64_MAX || dev->bbu < S64_MIN)) {
> - mutex_unlock(&dev->io_mutex);
> - return -EIO;
dev->bbu is s64 - that can never happen.
Apart from the initialisation to -1 (never checked for) it
is also always +ve.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
