mbox series

[v4,0/6] Fix potential out-of-bounds error in some drivers

Message ID 20250508130612.82270-1-markus.burri@mt.com (mailing list archive)
Headers show
Series Fix potential out-of-bounds error in some drivers | expand

Message

Markus Burri May 8, 2025, 1:06 p.m. UTC 
Several drivers are using debugfs and follow the same pattern.

A buffer is created on the stack with a limited size to copy the given data
from user space. The copy is performed using simple_write_to_buffer.
This function limits the input according to the specified buffer size, but
it does not write a string terminator if the buffer is truncated.
Therefore, the driver adds this zero terminator afterward.
Unfortunately, the original buffer size is used as an index, which can lead
to an out-of-bounds error.

This patch set fixes this issue in all the drivers I have detected so far.
The fix is to return an error in case of an unexpectedly long buffer being
received and to use the effective written size for the zero terminator for 
consistency.

Changes in V4:
* Revert the decrement of accepted size by one character
* Added patches for drivers with the same pattern

Changes in V3:
* Decrement accepted size by one character according to feedback

Changes in V2:
* Use effective written size as index instead of original size

---
[V3] https://lore.kernel.org/lkml/20250505203830.5117-1-markus.burri@mt.com/
[V2] https://lore.kernel.org/lkml/20250505045346.29647-1-markus.burri@mt.com/
[V1] https://lore.kernel.org/lkml/20250501063240.25295-1-markus.burri@mt.com/

Markus Burri (6):
  iio: backend: fix out-of-bound write
  accel/ivpu: Use effective buffer size for zero terminator
  iio: fix potential out-of-bound write
  gpio: fix potential out-of-bound write
  powerpc/eeh: fix potential OoB
  powerpc/eeh-powernv: fix potential OoB

 arch/powerpc/kernel/eeh.c                    |  7 ++++++-
 arch/powerpc/platforms/powernv/eeh-powernv.c |  7 ++++++-
 drivers/accel/ivpu/ivpu_debugfs.c            |  2 +-
 drivers/gpio/gpio-virtuser.c                 | 12 ++++++++++--
 drivers/iio/industrialio-backend.c           |  5 ++++-
 drivers/iio/industrialio-core.c              |  5 ++++-
 6 files changed, 31 insertions(+), 7 deletions(-)


base-commit: b4432656b36e5cc1d50a1f2dc15357543add530e

Comments

Bartosz Golaszewski May 9, 2025, 10:21 a.m. UTC | #1 
On Thu, May 8, 2025 at 3:06 PM Markus Burri <markus.burri@mt.com> wrote:
>
> Several drivers are using debugfs and follow the same pattern.
>
> A buffer is created on the stack with a limited size to copy the given data
> from user space. The copy is performed using simple_write_to_buffer.
> This function limits the input according to the specified buffer size, but
> it does not write a string terminator if the buffer is truncated.
> Therefore, the driver adds this zero terminator afterward.
> Unfortunately, the original buffer size is used as an index, which can lead
> to an out-of-bounds error.
>
> This patch set fixes this issue in all the drivers I have detected so far.
> The fix is to return an error in case of an unexpectedly long buffer being
> received and to use the effective written size for the zero terminator for
> consistency.
>
> Changes in V4:
> * Revert the decrement of accepted size by one character
> * Added patches for drivers with the same pattern
>
> Changes in V3:
> * Decrement accepted size by one character according to feedback
>
> Changes in V2:
> * Use effective written size as index instead of original size
>
> ---
> [V3] https://lore.kernel.org/lkml/20250505203830.5117-1-markus.burri@mt.com/
> [V2] https://lore.kernel.org/lkml/20250505045346.29647-1-markus.burri@mt.com/
> [V1] https://lore.kernel.org/lkml/20250501063240.25295-1-markus.burri@mt.com/
>
> Markus Burri (6):
>   iio: backend: fix out-of-bound write
>   accel/ivpu: Use effective buffer size for zero terminator
>   iio: fix potential out-of-bound write
>   gpio: fix potential out-of-bound write
>   powerpc/eeh: fix potential OoB
>   powerpc/eeh-powernv: fix potential OoB
>

Please, don't send this as a series, it makes absolutely no sense.
These patches - other than fixing similar issues - are completely
unrelated.

Bartosz