[PATCH 0/2] (no cover subject)

[PATCH 0/2] (no cover subject)

[Bryam Vargas via B4 Relay]

From be2c4843f6145374f28edd25cef43c9373542874 Mon Sep 17 00:00:00 2001
Message-ID: <cover.1781415009.git.hexlabsecurity@proton.me>
From: Bryam Vargas <hexlabsecurity@proton.me>
Date: Sun, 14 Jun 2026 00:30:09 -0500
Subject: [PATCH 0/2] Input: synaptics-rmi4 - fix out-of-bounds keymap access on large GPIO counts

The RMI4 F3A and F30 function handlers size their GPIO/LED key map to
min(device_gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but
then consume that map with the full, unclamped device-reported count in
two places: the attention-interrupt report loop, and input->keycodemax
(while input->keycode points at the small allocation).

A device that reports a GPIO/LED count greater than 6 therefore yields a
key map of at most 12 bytes that is indexed up to count-1:

  - rmi_f3a_attention() / rmi_f30_attention() read gpio[led]_key_map[i]
    out of bounds on every attention interrupt (device-triggered), and

  - the input core's default keymap ioctls bound the index only against
    keycodemax, so EVIOCGKEYCODE reads adjacent slab memory back to user
    space and EVIOCSKEYCODE writes a caller-controlled u16 past the
    allocation -- a controlled out-of-bounds heap write reachable by any
    process that can open the evdev node.

Both handlers have the same shape; F3A was copied from F30. Patch 1 fixes
F3A, patch 2 fixes F30. The one-line fix in each sizes the key map to the
full device count; the mapping loop is unchanged (it still populates only
the first min(count, 6) entries, the rest stay KEY_RESERVED and are
skipped on report), and keycodemax now matches the allocation, closing
the interrupt and both ioctl paths.

Reproduced with KASAN on a faithful in-kernel model of each handler
(kmalloc-16 bucket, 12-byte request, reported count = 127):

  # without the patch -- attention read path
  BUG: KASAN: slab-out-of-bounds in rmi_f3a_attention
  Read of size 2 ... 0 bytes to the right of allocated 12-byte region
    ... cache kmalloc-16

  # without the patch -- EVIOCSKEYCODE write path
  BUG: KASAN: slab-out-of-bounds ...
  Write of size 2 ... 0 bytes to the right of allocated 12-byte region

  # with the patch (key map sized to the full count): clean
  # benign device (reported count <= 6): clean

The full read and write splats and a 32/64-bit ASan model of the same
geometry are available on request.

Bryam Vargas (2):
  Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count
  Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count

 drivers/input/rmi4/rmi_f30.c | 2 +-
 drivers/input/rmi4/rmi_f3a.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

base-commit: 8e65320d91cdc3b241d4b94855c88459b91abf66
---
Bryam Vargas (2):
      Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count
      Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count

 drivers/input/rmi4/rmi_f30.c | 2 +-
 drivers/input/rmi4/rmi_f3a.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
---
base-commit: 8e65320d91cdc3b241d4b94855c88459b91abf66
change-id: 20260614-b4-disp-818d6bda-8df90972ace6

Best regards,
-- 
Bryam Vargas <hexlabsecurity@proton.me>

[PATCH 1/2] Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count

[Bryam Vargas via B4 Relay]

From: Bryam Vargas <hexlabsecurity@proton.me>

rmi_f3a_initialize() takes the GPIO count from the device query register
(f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127).
rmi_f3a_map_gpios() then allocates gpio_key_map with
min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but
rmi_f3a_attention() iterates the full gpio_count and dereferences
gpio_key_map[i], and input->keycodemax is set to the full gpio_count
while input->keycode points at the 6-entry allocation.

A device that reports gpio_count > 6 therefore causes an out-of-bounds
read of gpio_key_map[] on every attention interrupt, and out-of-bounds
accesses through the input core's default keymap ioctls: EVIOCGKEYCODE
reads past the buffer (leaking adjacent slab memory to user space) and
EVIOCSKEYCODE writes a caller-controlled value past it, for any process
able to open the evdev node, since input_default_getkeycode() and
input_default_setkeycode() only bound the index against keycodemax.

Size the keymap for the full gpio_count. The mapping loop is unchanged:
it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END)
entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills)
and are skipped when reporting.

Fixes: 9e4c596bfd00 ("Input: synaptics-rmi4 - add support for F3A")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
---
 drivers/input/rmi4/rmi_f3a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/rmi4/rmi_f3a.c b/drivers/input/rmi4/rmi_f3a.c
index 0e8baed84dbb..a0777644eef0 100644
--- a/drivers/input/rmi4/rmi_f3a.c
+++ b/drivers/input/rmi4/rmi_f3a.c
@@ -132,7 +132,7 @@ static int rmi_f3a_map_gpios(struct rmi_function *fn, struct f3a_data *f3a,
 	int button_count = min_t(u8, f3a->gpio_count, TRACKSTICK_RANGE_END);
 
 	f3a->gpio_key_map = devm_kcalloc(&fn->dev,
-						button_count,
+						f3a->gpio_count,
 						sizeof(f3a->gpio_key_map[0]),
 						GFP_KERNEL);
 	if (!f3a->gpio_key_map) {

-- 
2.43.0

[PATCH 2/2] Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count

[Bryam Vargas via B4 Relay]

From: Bryam Vargas <hexlabsecurity@proton.me>

rmi_f30_map_gpios() allocates gpioled_key_map with
min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but
rmi_f30_attention() iterates the full f30->gpioled_count (device query
register, range 0..31) and dereferences gpioled_key_map[i], and
input->keycodemax is set to the full gpioled_count while input->keycode
points at the 6-entry allocation.

A device that reports gpioled_count > 6 with GPIO support enabled
therefore causes an out-of-bounds read on the attention interrupt and
out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls,
which bound the index only against keycodemax. This is the same defect
as the F3A handler, which was copied from F30.

Size the keymap for the full gpioled_count; the mapping loop still
assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries.

Fixes: 3e64fcbdbd10 ("Input: synaptics-rmi4 - limit the range of what GPIOs are buttons")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
---
 drivers/input/rmi4/rmi_f30.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
index 35045f161dc2..b2155c8e20e7 100644
--- a/drivers/input/rmi4/rmi_f30.c
+++ b/drivers/input/rmi4/rmi_f30.c
@@ -233,7 +233,7 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
 	int button_count = min_t(u8, f30->gpioled_count, TRACKSTICK_RANGE_END);
 
 	f30->gpioled_key_map = devm_kcalloc(&fn->dev,
-					    button_count,
+					    f30->gpioled_count,
 					    sizeof(f30->gpioled_key_map[0]),
 					    GFP_KERNEL);
 	if (!f30->gpioled_key_map) {

-- 
2.43.0

Re: [PATCH 0/2] (no cover subject)

[Dmitry Torokhov]

On Sun, Jun 14, 2026 at 12:36:10AM -0500, Bryam Vargas via B4 Relay wrote:
> From be2c4843f6145374f28edd25cef43c9373542874 Mon Sep 17 00:00:00 2001
> Message-ID: <cover.1781415009.git.hexlabsecurity@proton.me>
> From: Bryam Vargas <hexlabsecurity@proton.me>
> Date: Sun, 14 Jun 2026 00:30:09 -0500
> Subject: [PATCH 0/2] Input: synaptics-rmi4 - fix out-of-bounds keymap access on large GPIO counts
> 
> The RMI4 F3A and F30 function handlers size their GPIO/LED key map to
> min(device_gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but
> then consume that map with the full, unclamped device-reported count in
> two places: the attention-interrupt report loop, and input->keycodemax
> (while input->keycode points at the small allocation).
> 
> A device that reports a GPIO/LED count greater than 6 therefore yields a
> key map of at most 12 bytes that is indexed up to count-1:
> 
>   - rmi_f3a_attention() / rmi_f30_attention() read gpio[led]_key_map[i]
>     out of bounds on every attention interrupt (device-triggered), and
> 
>   - the input core's default keymap ioctls bound the index only against
>     keycodemax, so EVIOCGKEYCODE reads adjacent slab memory back to user
>     space and EVIOCSKEYCODE writes a caller-controlled u16 past the
>     allocation -- a controlled out-of-bounds heap write reachable by any
>     process that can open the evdev node.
> 
> Both handlers have the same shape; F3A was copied from F30. Patch 1 fixes
> F3A, patch 2 fixes F30. The one-line fix in each sizes the key map to the
> full device count; the mapping loop is unchanged (it still populates only
> the first min(count, 6) entries, the rest stay KEY_RESERVED and are
> skipped on report), and keycodemax now matches the allocation, closing
> the interrupt and both ioctl paths.
> 
> Reproduced with KASAN on a faithful in-kernel model of each handler
> (kmalloc-16 bucket, 12-byte request, reported count = 127):
> 
>   # without the patch -- attention read path
>   BUG: KASAN: slab-out-of-bounds in rmi_f3a_attention
>   Read of size 2 ... 0 bytes to the right of allocated 12-byte region
>     ... cache kmalloc-16
> 
>   # without the patch -- EVIOCSKEYCODE write path
>   BUG: KASAN: slab-out-of-bounds ...
>   Write of size 2 ... 0 bytes to the right of allocated 12-byte region
> 
>   # with the patch (key map sized to the full count): clean
>   # benign device (reported count <= 6): clean
> 
> The full read and write splats and a 32/64-bit ASan model of the same
> geometry are available on request.

Applied the lot, thank you.

-- 
Dmitry

[PATCH 0/2] (no cover subject)

[James Clark]

---
James Clark (2):
      perf cs-etm: Fix decoding for sparse CPU maps
      perf cs-etm: Test sparse CPU maps

 tools/perf/tests/shell/test_arm_coresight.sh | 54 ++++++++++++++++++++++++++++
 tools/perf/util/cs-etm.c                     |  3 +-
 2 files changed, 56 insertions(+), 1 deletion(-)
---
base-commit: 571d29baa07e83e637075239f379f91353c24ec9
change-id: 20260115-james-perf-coresight-cpu-map-segfault-e250af5aa778

Best regards,
-- 
James Clark <james.clark@linaro.org>

[PATCH 0/2] (no cover subject)

[pratyush.brahma]

mm/numa_emulation: Code refactoring to improve modularity and
readability

This series intends to improve the code readability by using
existing macros instead of hardcoded values for size and improves
the modularity by moving the size calculation for emulated blocks
to a separate function.

Signed-off-by: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>
---
Pratyush Brahma (2):
      mm/numa_emulation: Refactor NUMA emulation size handling to use kernel macros
      mm/numa_emulation: Move the size calculation in split_nodes_interleave() to a separate function

 mm/numa_emulation.c | 47 ++++++++++++++++++++++++++++++-----------------
 1 file changed, 30 insertions(+), 17 deletions(-)
---
base-commit: 4ff71af020ae59ae2d83b174646fc2ad9fcd4dc4
change-id: 20250926-numa-emu-6e6c27bd8f6f

Best regards,
--  
Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>

Re: [PATCH 0/2] (no cover subject)

[Anshuman Khandual]

On 26/09/25 4:04 PM, pratyush.brahma@oss.qualcomm.com wrote:
> mm/numa_emulation: Code refactoring to improve modularity and
> readability

This should have been the cover letter subject line.
> 
> This series intends to improve the code readability by using
> existing macros instead of hardcoded values for size and improves
> the modularity by moving the size calculation for emulated blocks
> to a separate function.
> 
> Signed-off-by: Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>

In general, a signed of statement is not required for the cover letter.
> ---
> Pratyush Brahma (2):
>       mm/numa_emulation: Refactor NUMA emulation size handling to use kernel macros
>       mm/numa_emulation: Move the size calculation in split_nodes_interleave() to a separate function
> 
>  mm/numa_emulation.c | 47 ++++++++++++++++++++++++++++++-----------------
>  1 file changed, 30 insertions(+), 17 deletions(-)
> ---
> base-commit: 4ff71af020ae59ae2d83b174646fc2ad9fcd4dc4
> change-id: 20250926-numa-emu-6e6c27bd8f6f
> 
> Best regards,
> --  
> Pratyush Brahma <pratyush.brahma@oss.qualcomm.com>

Ditto.

Seems like portions of this cover letter has been all jumbled up.

[PATCH 0/2] (no cover subject)

[Aaron Kling via B4 Relay]

When Tegra234 support was added to existing Tegra drivers, many of them
did not have the matching Kconfig entries updated to allow building for
the arch. A few of those have already been fixed. This series fixes a
couple more.

Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
---
Aaron Kling (2):
      cpufreq: tegra194: Allow building for Tegra234
      PCI: tegra194: Allow building for Tegra234

 drivers/cpufreq/Kconfig.arm        | 2 +-
 drivers/pci/controller/dwc/Kconfig | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
---
base-commit: d082ecbc71e9e0bf49883ee4afd435a77a5101b6
change-id: 20250224-build-tegra234-c185bda9fd4a

Best regards,
-- 
Aaron Kling <webgeek1234@gmail.com>

Re: [PATCH 0/2] (no cover subject)

[Krzysztof Wilczyński]

Hello,

> When Tegra234 support was added to existing Tegra drivers, many of them
> did not have the matching Kconfig entries updated to allow building for
> the arch. A few of those have already been fixed. This series fixes a
> couple more.

A similar patch has been posted earlier.  Have a look at the conversation there:

  https://lore.kernel.org/linux-pci/20250128044244.2766334-1-vidyas@nvidia.com/

Thank you!

	Krzysztof

[PATCH 0/2] (no cover subject)

[Linus Walleij]

Some Versatile family DTS updates for the v6.7 kernel
cycle.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Linus Walleij (2):
      ARM: dts: versatile: Fix up VGA connector
      ARM: dts: integrator: Fix up VGA connector

 arch/arm/boot/dts/arm/integratorap-im-pd1.dts | 3 +--
 arch/arm/boot/dts/arm/versatile-ab.dts        | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)
---
base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d
change-id: 20230912-versatile-dts-v6-7-28497ea9b7e7

Best regards,
-- 
Linus Walleij <linus.walleij@linaro.org>