* [PATCH] HID: core: do not allow parsing 0-sized reports
From: Dmitry Torokhov @ 2026-04-01 6:04 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Peter Hutterer, Kees Cook, Alan Stern,
Charles Keepax, linux-input, linux-kernel
Commit d7db259bd6df ("HID: core: factor out hid_parse_collections()")
reworked collection parsing code and inadvertently allowed returning
"success" when parsing 0-sized reports where old code returned -EINVAL.
Restore the original behavior by doing an explicit check.
Note that the error message now differs from the generic "item fetching
failed at offset %u/%u" that is now used only for non-empty descriptors.
Fixes: d7db259bd6df ("HID: core: factor out hid_parse_collections()")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/hid/hid-core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index b40953e0f52e..be9d2b3356c3 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1272,6 +1272,11 @@ static int hid_parse_collections(struct hid_device *device)
device->collection[i].parent_idx = -1;
ret = -EINVAL;
+ if (start == end) {
+ hid_err(device, "rejecting 0-sized report descriptor\n");
+ goto out;
+ }
+
while ((next = fetch_item(start, end, &item)) != NULL) {
start = next;
--
2.53.0.1185.g05d4b7b318-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH 0/3] snvs_pwrkey - code improvements and add report event
From: Dmitry Torokhov @ 2026-04-01 4:50 UTC (permalink / raw)
To: Joy Zou
Cc: Frank Li, Peng Fan, Jacky Bai, Ye Li, imx, linux-input,
linux-kernel
In-Reply-To: <20260326-pwrkey-cleanup-v1-0-d85d7c0bf275@nxp.com>
On Thu, Mar 26, 2026 at 06:39:37PM +0800, Joy Zou wrote:
> This patch series improves the snvs_pwrkey driver with better code quality
> and add report press event.
>
> The main improvements include:
> 1. Clean up the code by using local device pointers and dev_err_probe() for
> better readability and easier debugging.
>
> 2. Fix potential event loss during system suspend by reporting key press events
> directly in the interrupt handler.
>
> Signed-off-by: Joy Zou <joy.zou@nxp.com>
Please address comments form here:
https://sashiko.dev/#/patchset/20260326-pwrkey-cleanup-v1-0-d85d7c0bf275%40nxp.com
Majority of them seem valid.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
From: kernel test robot @ 2026-04-01 1:21 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: llvm, oe-kbuild-all, Fabien Parent, Val Packett,
Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Julien Massot,
Louis-Alexis Eyraud, Gary Bisson, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-8-l.scorcia@gmail.com>
Hi Luca,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on broonie-regulator/for-next linusw-pinctrl/devel linusw-pinctrl/for-next lee-mfd/for-mfd-fixes linus/master v7.0-rc6 next-20260330]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Luca-Leonardo-Scorcia/dt-bindings-mfd-mt6397-Add-MT6392-PMIC/20260331-081127
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20260330083429.359819-8-l.scorcia%40gmail.com
patch subject: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20260401/202604010924.UuETwSKZ-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260401/202604010924.UuETwSKZ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604010924.UuETwSKZ-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/regulator/mt6392-regulator.c:181:18: warning: unused variable 'ldo_volt_table1b' [-Wunused-const-variable]
181 | static const u32 ldo_volt_table1b[] = {
| ^~~~~~~~~~~~~~~~
1 warning generated.
vim +/ldo_volt_table1b +181 drivers/regulator/mt6392-regulator.c
180
> 181 static const u32 ldo_volt_table1b[] = {
182 1500000, 1800000, 2500000, 2800000,
183 };
184
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 0/4] Input: refactor USB endpoint lookups
From: Dmitry Torokhov @ 2026-03-31 20:21 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-input, linux-kernel
In-Reply-To: <acsNayeGbU6cRw3P@google.com>
On Mon, Mar 30, 2026 at 04:55:35PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 30, 2026 at 11:59:44AM +0200, Johan Hovold wrote:
> > Use the common USB helpers for looking up bulk and interrupt endpoints
> > instead of open coding.
>
> Applied the lot, thank you.
Actually, dropped patch #4:
https://sashiko.dev/#/patchset/20260330095948.1663141-1-johan%40kernel.org
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
From: kernel test robot @ 2026-03-31 17:55 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: oe-kbuild-all, Fabien Parent, Val Packett, Luca Leonardo Scorcia,
AngeloGioacchino Del Regno, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Louis-Alexis Eyraud,
Gary Bisson, Chen Zhong, linux-input, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-8-l.scorcia@gmail.com>
Hi Luca,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on broonie-regulator/for-next linusw-pinctrl/devel linusw-pinctrl/for-next lee-mfd/for-mfd-fixes linus/master v7.0-rc6 next-20260330]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Luca-Leonardo-Scorcia/dt-bindings-mfd-mt6397-Add-MT6392-PMIC/20260331-081127
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20260330083429.359819-8-l.scorcia%40gmail.com
patch subject: [PATCH v4 7/9] regulator: Add MediaTek MT6392 regulator
config: sh-allmodconfig (https://download.01.org/0day-ci/archive/20260401/202604010103.FzAGRPye-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260401/202604010103.FzAGRPye-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604010103.FzAGRPye-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/regulator/mt6392-regulator.c:181:18: warning: 'ldo_volt_table1b' defined but not used [-Wunused-const-variable=]
181 | static const u32 ldo_volt_table1b[] = {
| ^~~~~~~~~~~~~~~~
vim +/ldo_volt_table1b +181 drivers/regulator/mt6392-regulator.c
180
> 181 static const u32 ldo_volt_table1b[] = {
182 1500000, 1800000, 2500000, 2800000,
183 };
184
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 5/9] mfd: mt6397: Add support for MT6392 PMIC
From: kernel test robot @ 2026-03-31 16:01 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: llvm, oe-kbuild-all, Fabien Parent, Val Packett,
Luca Leonardo Scorcia, AngeloGioacchino Del Regno,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Gary Bisson,
Julien Massot, Louis-Alexis Eyraud, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-6-l.scorcia@gmail.com>
Hi Luca,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lee-mfd/for-mfd-next]
[also build test WARNING on broonie-regulator/for-next linusw-pinctrl/devel linusw-pinctrl/for-next lee-mfd/for-mfd-fixes linus/master v7.0-rc6 next-20260330]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Luca-Leonardo-Scorcia/dt-bindings-mfd-mt6397-Add-MT6392-PMIC/20260331-081127
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
patch link: https://lore.kernel.org/r/20260330083429.359819-6-l.scorcia%40gmail.com
patch subject: [PATCH v4 5/9] mfd: mt6397: Add support for MT6392 PMIC
config: s390-randconfig-002-20260331 (https://download.01.org/0day-ci/archive/20260331/202603312339.CMJpqhEq-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260331/202603312339.CMJpqhEq-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603312339.CMJpqhEq-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/mfd/mt6397-core.c:421:16: warning: cast to smaller integer type 'enum mfd_match_data' from 'const void *' [-Wvoid-pointer-to-enum-cast]
421 | device_data = (enum mfd_match_data)of_device_get_match_data(&pdev->dev);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
vim +421 drivers/mfd/mt6397-core.c
398
399 static int mt6397_probe(struct platform_device *pdev)
400 {
401 int ret;
402 unsigned int id = 0;
403 struct mt6397_chip *pmic;
404 const struct chip_data *pmic_core;
405 enum mfd_match_data device_data;
406
407 pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
408 if (!pmic)
409 return -ENOMEM;
410
411 pmic->dev = &pdev->dev;
412
413 /*
414 * mt6397 MFD is child device of soc pmic wrapper.
415 * Regmap is set from its parent.
416 */
417 pmic->regmap = dev_get_regmap(pdev->dev.parent, NULL);
418 if (!pmic->regmap)
419 return -ENODEV;
420
> 421 device_data = (enum mfd_match_data)of_device_get_match_data(&pdev->dev);
422 switch (device_data) {
423 case MATCH_DATA_MT6323:
424 pmic_core = &mt6323_core;
425 break;
426 case MATCH_DATA_MT6328:
427 pmic_core = &mt6328_core;
428 break;
429 case MATCH_DATA_MT6331:
430 pmic_core = &mt6331_mt6332_core;
431 break;
432 case MATCH_DATA_MT6357:
433 pmic_core = &mt6357_core;
434 break;
435 case MATCH_DATA_MT6358:
436 pmic_core = &mt6358_core;
437 break;
438 case MATCH_DATA_MT6359:
439 pmic_core = &mt6359_core;
440 break;
441 case MATCH_DATA_MT6392:
442 pmic_core = &mt6392_core;
443 break;
444 case MATCH_DATA_MT6397:
445 pmic_core = &mt6397_core;
446 break;
447 default:
448 dev_err(&pdev->dev, "Unknown device match data %u\n", device_data);
449 return -ENODEV;
450 }
451
452 ret = regmap_read(pmic->regmap, pmic_core->cid_addr, &id);
453 if (ret) {
454 dev_err(&pdev->dev, "Failed to read chip id: %d\n", ret);
455 return ret;
456 }
457
458 pmic->chip_id = (id >> pmic_core->cid_shift) & 0xff;
459
460 platform_set_drvdata(pdev, pmic);
461
462 pmic->irq = platform_get_irq(pdev, 0);
463 if (pmic->irq <= 0)
464 return pmic->irq;
465
466 ret = pmic_core->irq_init(pmic);
467 if (ret)
468 return ret;
469
470 ret = devm_mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE,
471 pmic_core->cells, pmic_core->cell_size,
472 NULL, 0, pmic->irq_domain);
473 if (ret) {
474 irq_domain_remove(pmic->irq_domain);
475 dev_err(&pdev->dev, "failed to add child devices: %d\n", ret);
476 }
477
478 return ret;
479 }
480
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS 620ecc3c77ab1cad90760eec933ccf49a7bf6a8e
From: kernel test robot @ 2026-03-31 14:31 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: 620ecc3c77ab1cad90760eec933ccf49a7bf6a8e Input: usbtouchscreen - refactor endpoint lookup
elapsed time: 844m
configs tested: 179
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260331 clang-23
arc randconfig-002-20260331 clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260331 clang-23
arm randconfig-002-20260331 clang-23
arm randconfig-003-20260331 clang-23
arm randconfig-004-20260331 clang-23
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260331 clang-18
arm64 randconfig-002-20260331 clang-18
arm64 randconfig-003-20260331 clang-18
arm64 randconfig-004-20260331 clang-18
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260331 clang-18
csky randconfig-002-20260331 clang-18
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260331 gcc-11.5.0
hexagon randconfig-002-20260331 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260331 clang-20
i386 buildonly-randconfig-002-20260331 clang-20
i386 buildonly-randconfig-003-20260331 clang-20
i386 buildonly-randconfig-004-20260331 clang-20
i386 buildonly-randconfig-005-20260331 clang-20
i386 buildonly-randconfig-006-20260331 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260331 gcc-14
i386 randconfig-002-20260331 gcc-14
i386 randconfig-003-20260331 gcc-14
i386 randconfig-004-20260331 gcc-14
i386 randconfig-005-20260331 gcc-14
i386 randconfig-006-20260331 gcc-14
i386 randconfig-007-20260331 gcc-14
i386 randconfig-011-20260331 clang-20
i386 randconfig-012-20260331 clang-20
i386 randconfig-013-20260331 clang-20
i386 randconfig-014-20260331 clang-20
i386 randconfig-015-20260331 clang-20
i386 randconfig-016-20260331 clang-20
i386 randconfig-017-20260331 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260331 gcc-11.5.0
loongarch randconfig-002-20260331 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips ip32_defconfig clang-23
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260331 gcc-11.5.0
nios2 randconfig-002-20260331 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260331 clang-23
parisc randconfig-002-20260331 clang-23
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc pcm030_defconfig clang-23
powerpc randconfig-001-20260331 clang-23
powerpc randconfig-002-20260331 clang-23
powerpc64 alldefconfig clang-23
powerpc64 randconfig-001-20260331 clang-23
powerpc64 randconfig-002-20260331 clang-23
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260331 gcc-15.2.0
riscv randconfig-002-20260331 gcc-15.2.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260331 gcc-15.2.0
s390 randconfig-002-20260331 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260331 gcc-15.2.0
sh randconfig-002-20260331 gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260331 gcc-15.2.0
sparc randconfig-002-20260331 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260331 gcc-15.2.0
sparc64 randconfig-002-20260331 gcc-15.2.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260331 gcc-15.2.0
um randconfig-002-20260331 gcc-15.2.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260331 clang-20
x86_64 buildonly-randconfig-002-20260331 clang-20
x86_64 buildonly-randconfig-003-20260331 clang-20
x86_64 buildonly-randconfig-004-20260331 clang-20
x86_64 buildonly-randconfig-005-20260331 clang-20
x86_64 buildonly-randconfig-006-20260331 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260331 gcc-14
x86_64 randconfig-002-20260331 gcc-14
x86_64 randconfig-003-20260331 gcc-14
x86_64 randconfig-004-20260331 gcc-14
x86_64 randconfig-005-20260331 gcc-14
x86_64 randconfig-006-20260331 gcc-14
x86_64 randconfig-011-20260331 clang-20
x86_64 randconfig-012-20260331 clang-20
x86_64 randconfig-013-20260331 clang-20
x86_64 randconfig-014-20260331 clang-20
x86_64 randconfig-015-20260331 clang-20
x86_64 randconfig-016-20260331 clang-20
x86_64 randconfig-071-20260331 clang-20
x86_64 randconfig-072-20260331 clang-20
x86_64 randconfig-073-20260331 clang-20
x86_64 randconfig-074-20260331 clang-20
x86_64 randconfig-075-20260331 clang-20
x86_64 randconfig-076-20260331 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260331 gcc-15.2.0
xtensa randconfig-002-20260331 gcc-15.2.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 3/3] Input: snvs_pwrkey - report press event in interrupt handler
From: Frank Li @ 2026-03-31 14:11 UTC (permalink / raw)
To: Joy Zou
Cc: Dmitry Torokhov, Peng Fan, Jacky Bai, Ye Li, imx, linux-input,
linux-kernel
In-Reply-To: <20260331104655.GA1415371@shlinux88>
On Tue, Mar 31, 2026 at 06:46:55PM +0800, Joy Zou wrote:
> On Thu, Mar 26, 2026 at 03:57:27PM -0400, Frank Li wrote:
> > On Thu, Mar 26, 2026 at 06:39:40PM +0800, Joy Zou wrote:
> > > On some boards such as i.MX8MQ-EVK, the PCIe driver may take up to
> > > 200ms to restore the PCIe link during the no_irq resume phase. This
> > > causes key press events to be lost because the key may be released
> > > before the timer starts running, as interrupts are disabled during
> > > this 200ms window.
> >
> > if irq disable, how imx_snvs_pwrkey_interrupt get run?
> >
> Thank you for your comments. I might have missed some details in my commit
> message. Could you please review the description below and let me know if
> it's clear and comprehensive enough?
>
> The driver implements debounce protection using a timer-based mechanism:
> when a key interrupt occurs, a timer is scheduled to verify the key state
> after DEBOUNCE_TIME before reporting the event. This works well during
> normal operation.
>
> However, key press events can be lost during system resume on platforms
> like i.MX8MQ-EVK because:
> 1. During the no_irq resume phase, PCIe driver restoration can take up to
> 200ms with IRQs disabled.
> 2. The power key interrupt remains pending during the no_irq phase.
> 3. If the key is released before IRQs are re-enabled, the timer eventually
> runs but sees the key as released and skips reporting the event.
>
> Report key press events directly in interrupt handler to prevent event
> loss during system suspend. This is safe because:
>
> 1. Only one event is reported per suspend cycle.
> 2. Normal operation retains the existing timer-based debounce mechanism.
much better. Thanks
Frank
> BR
> Joy Zou
> > Frank
> > >
> > > Report key press events directly in interrupt handler to prevent event
> > > loss during system suspend.
> > >
> > > Signed-off-by: Joy Zou <joy.zou@nxp.com>
> > > ---
> > > drivers/input/keyboard/snvs_pwrkey.c | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/input/keyboard/snvs_pwrkey.c b/drivers/input/keyboard/snvs_pwrkey.c
> > > index bab3ab57fdac77256be75a080773ea99372ec9c7..b557c1618d7369e872c6ce708a7b3017264ee385 100644
> > > --- a/drivers/input/keyboard/snvs_pwrkey.c
> > > +++ b/drivers/input/keyboard/snvs_pwrkey.c
> > > @@ -78,6 +78,16 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void *dev_id)
> > >
> > > pm_wakeup_event(input->dev.parent, 0);
> > >
> > > + /*
> > > + * Report key press events directly in interrupt handler to prevent event
> > > + * loss during system suspend.
> > > + */
> > > + if (pdev->dev.power.is_suspended) {
> > > + pdata->keystate = 1;
> > > + input_report_key(input, pdata->keycode, 1);
> > > + input_sync(input);
> > > + }
> > > +
> > > regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
> > > if (lp_status & SNVS_LPSR_SPO) {
> > > if (pdata->minor_rev == 0) {
> > >
> > > --
> > > 2.37.1
> > >
^ permalink raw reply
* Re: [PATCH 3/3] Input: snvs_pwrkey - report press event in interrupt handler
From: Joy Zou @ 2026-03-31 10:46 UTC (permalink / raw)
To: Frank Li
Cc: Dmitry Torokhov, Peng Fan, Jacky Bai, Ye Li, imx, linux-input,
linux-kernel
In-Reply-To: <acWPp7KHxv9a5Az6@lizhi-Precision-Tower-5810>
On Thu, Mar 26, 2026 at 03:57:27PM -0400, Frank Li wrote:
> On Thu, Mar 26, 2026 at 06:39:40PM +0800, Joy Zou wrote:
> > On some boards such as i.MX8MQ-EVK, the PCIe driver may take up to
> > 200ms to restore the PCIe link during the no_irq resume phase. This
> > causes key press events to be lost because the key may be released
> > before the timer starts running, as interrupts are disabled during
> > this 200ms window.
>
> if irq disable, how imx_snvs_pwrkey_interrupt get run?
>
Thank you for your comments. I might have missed some details in my commit
message. Could you please review the description below and let me know if
it's clear and comprehensive enough?
The driver implements debounce protection using a timer-based mechanism:
when a key interrupt occurs, a timer is scheduled to verify the key state
after DEBOUNCE_TIME before reporting the event. This works well during
normal operation.
However, key press events can be lost during system resume on platforms
like i.MX8MQ-EVK because:
1. During the no_irq resume phase, PCIe driver restoration can take up to
200ms with IRQs disabled.
2. The power key interrupt remains pending during the no_irq phase.
3. If the key is released before IRQs are re-enabled, the timer eventually
runs but sees the key as released and skips reporting the event.
Report key press events directly in interrupt handler to prevent event
loss during system suspend. This is safe because:
1. Only one event is reported per suspend cycle.
2. Normal operation retains the existing timer-based debounce mechanism.
BR
Joy Zou
> Frank
> >
> > Report key press events directly in interrupt handler to prevent event
> > loss during system suspend.
> >
> > Signed-off-by: Joy Zou <joy.zou@nxp.com>
> > ---
> > drivers/input/keyboard/snvs_pwrkey.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/input/keyboard/snvs_pwrkey.c b/drivers/input/keyboard/snvs_pwrkey.c
> > index bab3ab57fdac77256be75a080773ea99372ec9c7..b557c1618d7369e872c6ce708a7b3017264ee385 100644
> > --- a/drivers/input/keyboard/snvs_pwrkey.c
> > +++ b/drivers/input/keyboard/snvs_pwrkey.c
> > @@ -78,6 +78,16 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int irq, void *dev_id)
> >
> > pm_wakeup_event(input->dev.parent, 0);
> >
> > + /*
> > + * Report key press events directly in interrupt handler to prevent event
> > + * loss during system suspend.
> > + */
> > + if (pdev->dev.power.is_suspended) {
> > + pdata->keystate = 1;
> > + input_report_key(input, pdata->keycode, 1);
> > + input_sync(input);
> > + }
> > +
> > regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
> > if (lp_status & SNVS_LPSR_SPO) {
> > if (pdata->minor_rev == 0) {
> >
> > --
> > 2.37.1
> >
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Chen-Yu Tsai @ 2026-03-31 10:15 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Krzysztof Kozlowski, linux-mediatek, Fabien Parent, Val Packett,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2+1bc9Z-opoNqyUU_WFzyXZKGQmR_Ur=4UonOC=AWtQ8w@mail.gmail.com>
On Tue, Mar 31, 2026 at 4:36 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> > > - required:
> > > - - compatible
> >
> > Not really, this affects existing ABI and might make the child schema
> > being applied. Basically regulators node can be anything now.
> >
> > This is definitely not a binding we want. The syntax for parent schema
> > when listing only compatibles is requiring this compatible. You cannot
> > have here whatever empty node.
>
> Hi, it felt quite strange to me too, but that's what I thought you
> meant with your previous suggestion [1].
> To keep the required attribute I would be happy to reintroduce the
> compatible here, in the regulator schema and the pmic dtsi.
>
> Before I do that and resubmit, could you please help me understand
> what you meant before?
I think the point is that compatibles for regulator sub-nodes on MFDs
is no longer accepted.
Instead if you want to have a separate binding for the regulator part,
you would need to reference the binding directly.
Say the binding is at bindings/regulator/mt6392.yaml, in this patch
you would have something after the "additionalProperties: false" like:
allOf:
- if:
properties:
"compatible":
contains:
const: mediatek,mt6392
then:
properties:
regulators:
$ref: /schemas/regulator/mt6392.yaml
else:
properties:
regulators:
required:
- compatible
And drop the "required: - compatible" part from the common regulator
node bits of the binding.
ChenYu
> Thank you!
>
> [1] https://lists.infradead.org/pipermail/linux-mediatek/2026-March/105060.html
> --
> Luca Leonardo Scorcia
> l.scorcia@gmail.com
>
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-03-31 8:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260331-flawless-bronze-lorikeet-59a6ff@quoll>
> > - required:
> > - - compatible
>
> Not really, this affects existing ABI and might make the child schema
> being applied. Basically regulators node can be anything now.
>
> This is definitely not a binding we want. The syntax for parent schema
> when listing only compatibles is requiring this compatible. You cannot
> have here whatever empty node.
Hi, it felt quite strange to me too, but that's what I thought you
meant with your previous suggestion [1].
To keep the required attribute I would be happy to reintroduce the
compatible here, in the regulator schema and the pmic dtsi.
Before I do that and resubmit, could you please help me understand
what you meant before?
Thank you!
[1] https://lists.infradead.org/pipermail/linux-mediatek/2026-March/105060.html
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Check bounds when deleting force-feedback effects
From: Lee Jones @ 2026-03-31 7:58 UTC (permalink / raw)
To: Günther Noack
Cc: Filipe Laíns, Bastien Nocera, Jiri Kosina,
Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260331074052.194064-1-gnoack@google.com>
On Tue, 31 Mar 2026, Günther Noack wrote:
> Without this bounds check, this might otherwise overwrite index -1.
>
> Triggering this condition requires action both from the USB device and from
> userspace, which reduces the scenarios in which it can be exploited.
>
> Cc: Lee Jones <lee@kernel.org>
> Signed-off-by: Günther Noack <gnoack@google.com>
> ---
> drivers/hid/hid-logitech-hidpp.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
> index d1dea7297712..5f63f1d2303a 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -2502,12 +2502,15 @@ static void hidpp_ff_work_handler(struct work_struct *w)
> }
> break;
> case HIDPP_FF_DESTROY_EFFECT:
> - if (wd->effect_id >= 0)
> - /* regular effect destroyed */
> - data->effect_ids[wd->params[0]-1] = -1;
> - else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
> - /* autocenter spring destroyed */
> - data->slot_autocenter = 0;
> + slot = wd->params[0];
> + if (slot > 0 && slot <= data->num_effects) {
> + if (wd->effect_id >= 0)
> + /* regular effect destroyed */
> + data->effect_ids[slot-1] = -1;
> + else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
> + /* autocenter spring destroyed */
> + data->slot_autocenter = 0;
> + }
LGTM.
Reviewed-by: Lee Jones <lee@kernel.org>
--
Lee Jones [李琼斯]
^ permalink raw reply
* [PATCH] HID: logitech-hidpp: Check bounds when deleting force-feedback effects
From: Günther Noack @ 2026-03-31 7:40 UTC (permalink / raw)
To: Filipe Laíns, Bastien Nocera, Jiri Kosina,
Benjamin Tissoires
Cc: Günther Noack, Lee Jones, linux-input, linux-kernel
Without this bounds check, this might otherwise overwrite index -1.
Triggering this condition requires action both from the USB device and from
userspace, which reduces the scenarios in which it can be exploited.
Cc: Lee Jones <lee@kernel.org>
Signed-off-by: Günther Noack <gnoack@google.com>
---
drivers/hid/hid-logitech-hidpp.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index d1dea7297712..5f63f1d2303a 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -2502,12 +2502,15 @@ static void hidpp_ff_work_handler(struct work_struct *w)
}
break;
case HIDPP_FF_DESTROY_EFFECT:
- if (wd->effect_id >= 0)
- /* regular effect destroyed */
- data->effect_ids[wd->params[0]-1] = -1;
- else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
- /* autocenter spring destroyed */
- data->slot_autocenter = 0;
+ slot = wd->params[0];
+ if (slot > 0 && slot <= data->num_effects) {
+ if (wd->effect_id >= 0)
+ /* regular effect destroyed */
+ data->effect_ids[slot-1] = -1;
+ else if (wd->effect_id >= HIDPP_FF_EFFECTID_AUTOCENTER)
+ /* autocenter spring destroyed */
+ data->slot_autocenter = 0;
+ }
break;
case HIDPP_FF_SET_GLOBAL_GAINS:
data->gain = (wd->params[0] << 8) + wd->params[1];
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* Re: [PATCH v4 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:04 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260330083429.359819-4-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:37AM +0100, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 74 +++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++++++
> 2 files changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..24fbaef0e717
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 regulator
> +
> +description:
> + Regulator node of the PMIC. This node should under the PMIC's device node.
> + MT6392 is a power management system chip containing three buck converters and
> + 23 LDOs. All voltage regulators provided by the PMIC are described as
> + sub-nodes of this node.
> +
So that's a dead code / schema.
Try yourself if it works.
Your parent schema must reference this one for the regulators node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:01 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-2-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:35AM +0100, Luca Leonardo Scorcia wrote:
> - items:
> - enum:
> - mediatek,mt6366-rtc
> @@ -99,9 +107,6 @@ properties:
> - mediatek,mt6366-regulator
> - const: mediatek,mt6358-regulator
>
> - required:
> - - compatible
Not really, this affects existing ABI and might make the child schema
being applied. Basically regulators node can be anything now.
This is definitely not a binding we want. The syntax for parent schema
when listing only compatibles is requiring this compatible. You cannot
have here whatever empty node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] HID: gpd: fix report descriptor on GPD Win handheld (2f24:0137)
From: Thorsten Leemhuis @ 2026-03-31 6:25 UTC (permalink / raw)
To: honjow, Jiri Kosina, Benjamin Tissoires
Cc: denis.benato, linux-kernel, linux-input,
Linux kernel regressions list
In-Reply-To: <20260324013847.68024-1-honjow311@gmail.com>
On 3/24/26 02:38, honjow wrote:
> The OEM USB HID interface found on GPD Win handhelds (VID 2f24, registered
> to ShenZhen HuiJiaZhi / GameSir, PID 0137) declares 63-byte Input and
> Feature reports for Report ID 1, but the firmware only transfers 11 data
> bytes per interrupt.
>
> Since commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> bogus memset()"), the HID core rejects undersized reports instead of zero-
> padding them. This breaks the device entirely on kernels >= v7.0-rc5.
>
> Fix it by patching the report descriptor in report_fixup(), reducing
> Report Count from 63 to 11 for both Input and Feature.
>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221271
> Signed-off-by: honjow <honjow311@gmail.com>
> ---
> drivers/hid/Kconfig | 10 +++++++++
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-gpd.c | 52 +++++++++++++++++++++++++++++++++++++++++++
> drivers/hid/hid-ids.h | 3 +++
> 4 files changed, 66 insertions(+)
> create mode 100644 drivers/hid/hid-gpd.c
>
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 10c12d8e65579..20c60f5aca4c5 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -419,6 +419,16 @@ config HID_GLORIOUS
> Support for Glorious PC Gaming Race mice such as
> the Glorious Model O, O- and D.
>
> +config HID_GPD
> + tristate "GPD Win handheld OEM HID support"
Hmmm, why does this need to be a config option? Can't this be enabled
unconditionally? I ask in general, as it's just another point where
things can go wrong. But I mainly ask because it's a regression fix –
and from my understanding wrt to what Linus wants we don't expect users
to turn some .config on to keep their hardware running (unless it can't
be avoided at all costs).
Ciao, Thorsten
> + depends on USB_HID
> + help
> + Report descriptor fix for the OEM USB HID interface (GameSir
> + 2f24:0137) found on GPD Win handhelds. The firmware declares 63-byte
> + reports but only sends 11 bytes, which the HID core rejects.
> +
> + Say Y or M here if you use a GPD Win handheld with this interface.
> +
> config HID_HOLTEK
> tristate "Holtek HID devices"
> depends on USB_HID
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index 07dfdb6a49c59..03ef72ec4499f 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -53,6 +53,7 @@ obj-$(CONFIG_HID_ELO) += hid-elo.o
> obj-$(CONFIG_HID_EVISION) += hid-evision.o
> obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
> obj-$(CONFIG_HID_FT260) += hid-ft260.o
> +obj-$(CONFIG_HID_GPD) += hid-gpd.o
> obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
> obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
> obj-$(CONFIG_HID_GLORIOUS) += hid-glorious.o
> diff --git a/drivers/hid/hid-gpd.c b/drivers/hid/hid-gpd.c
> new file mode 100644
> index 0000000000000..5b4d203e24995
> --- /dev/null
> +++ b/drivers/hid/hid-gpd.c
> @@ -0,0 +1,52 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * HID report descriptor fixup for GPD Win handhelds.
> + *
> + * The OEM HID interface (VID 2f24 / GameSir, PID 0137) declares Report ID 1
> + * with Report Count 63 (8-bit fields) for both Input and Feature, but the
> + * firmware only sends 11 bytes of payload after the report ID.
> + */
> +
> +#include <linux/hid.h>
> +#include <linux/module.h>
> +
> +#include "hid-ids.h"
> +
> +#define RDESC_LEN 38
> +#define RPT_COUNT_INPUT_OFF 21
> +#define RPT_COUNT_FEATURE_OFF 34
> +
> +static const __u8 *gpd_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> + unsigned int *rsize)
> +{
> + if (*rsize != RDESC_LEN)
> + return rdesc;
> +
> + if (rdesc[RPT_COUNT_INPUT_OFF - 1] == 0x95 &&
> + rdesc[RPT_COUNT_INPUT_OFF] == 0x3f &&
> + rdesc[RPT_COUNT_FEATURE_OFF - 1] == 0x95 &&
> + rdesc[RPT_COUNT_FEATURE_OFF] == 0x3f) {
> + hid_info(hdev, "fixing report counts (63 -> 11 bytes)\n");
> + rdesc[RPT_COUNT_INPUT_OFF] = 11;
> + rdesc[RPT_COUNT_FEATURE_OFF] = 11;
> + }
> +
> + return rdesc;
> +}
> +
> +static const struct hid_device_id gpd_devices[] = {
> + { HID_USB_DEVICE(USB_VENDOR_ID_GAMESIR, USB_DEVICE_ID_GAMESIR_0137) },
> + { }
> +};
> +MODULE_DEVICE_TABLE(hid, gpd_devices);
> +
> +static struct hid_driver gpd_driver = {
> + .name = "gpd",
> + .id_table = gpd_devices,
> + .report_fixup = gpd_report_fixup,
> +};
> +
> +module_hid_driver(gpd_driver);
> +
> +MODULE_DESCRIPTION("HID report descriptor fix for GPD Win handheld (GameSir 2f24:0137)");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 933b7943bdb50..d0a6c19baa660 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -533,6 +533,9 @@
> #define USB_VENDOR_ID_FRUCTEL 0x25B6
> #define USB_DEVICE_ID_GAMETEL_MT_MODE 0x0002
>
> +#define USB_VENDOR_ID_GAMESIR 0x2f24
> +#define USB_DEVICE_ID_GAMESIR_0137 0x0137
> +
> #define USB_VENDOR_ID_GAMEVICE 0x27F8
> #define USB_DEVICE_ID_GAMEVICE_GV186 0x0BBE
> #define USB_DEVICE_ID_GAMEVICE_KISHI 0x0BBF
^ permalink raw reply
* Re: [PATCH 0/4] Input: refactor USB endpoint lookups
From: Dmitry Torokhov @ 2026-03-30 23:55 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-input, linux-kernel
In-Reply-To: <20260330095948.1663141-1-johan@kernel.org>
On Mon, Mar 30, 2026 at 11:59:44AM +0200, Johan Hovold wrote:
> Use the common USB helpers for looking up bulk and interrupt endpoints
> instead of open coding.
Applied the lot, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH RESEND] Input: atkbd - skip cleanup when used as a wakeup source
From: Dmitry Torokhov @ 2026-03-30 21:56 UTC (permalink / raw)
To: hbarnor; +Cc: linux-input, linux-kernel
In-Reply-To: <20260330-wakeup-v1-1-d269624fa519@chromium.org>
Hi Henry,
On Mon, Mar 30, 2026 at 12:01:50PM -0700, Henry Barnor via B4 Relay wrote:
> From: Henry Barnor <hbarnor@chromium.org>
>
> In systems using suspend-to-idle, the serio core calls atkbd_cleanup()
> during the suspend transition. Currently, this function unconditionally
> calls atkbd_disable(), setting atkbd->enabled to false.
>
> This creates a race condition during wakeup: when a key is pressed to
> wake the system, atkbd_receive_byte() is triggered. It correctly signals
> a wakeup event to the PM core, but then checks atkbd->enabled. Because
> the driver was disabled during suspend, the scancode is discarded.
> The system wakes up, but the initial keystroke is lost.
>
> This is particularly problematic for platforms like Android that rely on
> the input event itself to complete the wakeup transition and turn on the
> screen. On these systems, the device wakes up but remains in a dim state
> because the initial interaction was lost.
This is really for the Android system layer to solve.
>
> This patch modifies atkbd_cleanup() to skip disabling and resetting
> the keyboard if the device is configured as a wakeup source. This
> preserves atkbd->enabled = true through the sleep duration, ensuring
> the wake-up scancode is reported to the input subsystem.
>
> Note that this also affects the shutdown path. However, if a device is
> configured for wakeup, skipping the reset to "default" state is
> consistent with the goal of allowing the hardware to trigger a
> system-state transition. Modern BIOS/UEFI implementations perform their
> own keyboard initialization, so skipping the legacy reset on reboot
> for these devices poses minimal risk.
We unfortunately need to support devices much older than that, so we can
not be sure that this change is safe. Historically there we a lot of
instances where systems were unhappy if we attempted to enter shutdown
or suspend paths with devices in state other than freshly reset.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH RESEND] Input: atkbd - skip cleanup when used as a wakeup source
From: Henry Barnor via B4 Relay @ 2026-03-30 19:01 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel, Henry Barnor
From: Henry Barnor <hbarnor@chromium.org>
In systems using suspend-to-idle, the serio core calls atkbd_cleanup()
during the suspend transition. Currently, this function unconditionally
calls atkbd_disable(), setting atkbd->enabled to false.
This creates a race condition during wakeup: when a key is pressed to
wake the system, atkbd_receive_byte() is triggered. It correctly signals
a wakeup event to the PM core, but then checks atkbd->enabled. Because
the driver was disabled during suspend, the scancode is discarded.
The system wakes up, but the initial keystroke is lost.
This is particularly problematic for platforms like Android that rely on
the input event itself to complete the wakeup transition and turn on the
screen. On these systems, the device wakes up but remains in a dim state
because the initial interaction was lost.
This patch modifies atkbd_cleanup() to skip disabling and resetting
the keyboard if the device is configured as a wakeup source. This
preserves atkbd->enabled = true through the sleep duration, ensuring
the wake-up scancode is reported to the input subsystem.
Note that this also affects the shutdown path. However, if a device is
configured for wakeup, skipping the reset to "default" state is
consistent with the goal of allowing the hardware to trigger a
system-state transition. Modern BIOS/UEFI implementations perform their
own keyboard initialization, so skipping the legacy reset on reboot
for these devices poses minimal risk.
Signed-off-by: Henry Barnor <hbarnor@chromium.org>
---
drivers/input/keyboard/atkbd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 4560d3964eee..1fba1932412e 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -958,6 +958,9 @@ static void atkbd_cleanup(struct serio *serio)
{
struct atkbd *atkbd = atkbd_from_serio(serio);
+ if (device_may_wakeup(&serio->dev))
+ return;
+
atkbd_disable(atkbd);
ps2_command(&atkbd->ps2dev, NULL, ATKBD_CMD_RESET_DEF);
}
---
base-commit: 6d4b67a2a76a4ff2393fe88119ae4332821b82b4
change-id: 20260310-wakeup-ec57a88a0162
Best regards,
--
Henry Barnor <hbarnor@chromium.org>
^ permalink raw reply related
* Re: [PATCH] HID: gpd: fix report descriptor on GPD Win handheld (2f24:0137)
From: Jiri Kosina @ 2026-03-30 14:21 UTC (permalink / raw)
To: honjow; +Cc: Benjamin Tissoires, denis.benato, linux-kernel, linux-input
In-Reply-To: <20260324013847.68024-1-honjow311@gmail.com>
On Tue, 24 Mar 2026, honjow wrote:
> The OEM USB HID interface found on GPD Win handhelds (VID 2f24, registered
> to ShenZhen HuiJiaZhi / GameSir, PID 0137) declares 63-byte Input and
> Feature reports for Report ID 1, but the firmware only transfers 11 data
> bytes per interrupt.
>
> Since commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> bogus memset()"), the HID core rejects undersized reports instead of zero-
> padding them. This breaks the device entirely on kernels >= v7.0-rc5.
>
> Fix it by patching the report descriptor in report_fixup(), reducing
> Report Count from 63 to 11 for both Input and Feature.
>
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221271
> Signed-off-by: honjow <honjow311@gmail.com>
I have added Fixes: tag and applied to hid.git#for-7.0/upstream-fixes,
thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH AUTOSEL 6.19-6.18] HID: core: Mitigate potential OOB by removing bogus memset()
From: Jiri Kosina @ 2026-03-30 13:32 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Sasha Levin, patches, stable, Lee Jones, Benjamin Tissoires,
linux-input, linux-kernel, honjow
In-Reply-To: <695caa61-20f9-4932-9ff9-431be7615c43@leemhuis.info>
On Mon, 30 Mar 2026, Thorsten Leemhuis wrote:
> > From: Lee Jones <lee@kernel.org>
> >
> > [ Upstream commit 0a3fe972a7cb1404f693d6f1711f32bc1d244b1c ]
>
> TWIMC, honjow (now CCed) reported a regression (GPD Win5 handhelds
> stopped working) caused by this change – and provided a patch (which
> misses a Fixes tag) to resolve it:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=221271
> https://lore.kernel.org/all/20260324013847.68024-1-honjow311@gmail.com/
Thanks for pointing out the missing Fixes: tag, I'll add it manually when
applying.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH v2] HID: mcp2221: validate report size in raw_event handler
From: Sebastian Josue Alba Vives @ 2026-03-30 13:29 UTC (permalink / raw)
To: jikos, bentiss
Cc: linux-input, linux-kernel, stable, Sebastian Josue Alba Vives
mcp2221_raw_event() accesses the data buffer at offsets up to 55
without validating the size parameter. Since __hid_input_report()
invokes the driver's raw_event callback before
hid_report_raw_event() performs its own report-size validation, a
device sending a truncated HID report can cause out-of-bounds heap
reads in the kernel.
The most critical access is the memcpy from data[50] into
mcp->adc_values (6 bytes) when CONFIG_IIO is reachable. Other
unchecked accesses include data[20] and a memcpy at data[22].
Additionally, a memcpy with device-controlled length (data[3],
up to 60 bytes) from data[4] does not verify that size is large
enough to cover the copy.
MCP2221 devices use 64-byte HID reports. Add a check at the top of
the handler to reject any report shorter than expected, and log a
warning to aid debugging.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Josue Alba Vives <sebasjosue84@gmail.com>
---
drivers/hid/hid-mcp2221.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index ef3b5c77c..770c305d8 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -850,6 +850,11 @@ static int mcp2221_raw_event(struct hid_device *hdev,
{
u8 *buf;
struct mcp2221 *mcp = hid_get_drvdata(hdev);
+ /* MCP2221 always sends 64-byte reports */
+ if (size < 64) {
+ hid_warn(hdev, "report too short: %d < 64\n", size);
+ return 0;
+ }
switch (data[0]) {
--
2.43.0
^ permalink raw reply related
* [PATCH v2] HID: ft260: validate report size and payload length in raw_event
From: Sebastian Josue Alba Vives @ 2026-03-30 13:28 UTC (permalink / raw)
To: jikos, bentiss
Cc: linux-input, linux-kernel, stable, Sebastian Josue Alba Vives
ft260_raw_event() casts the raw data buffer to a
ft260_i2c_input_report struct and accesses its fields without
validating the size parameter. Since __hid_input_report() invokes
the driver's raw_event callback before hid_report_raw_event()
performs its own report-size validation, a device sending a
truncated HID report can cause out-of-bounds heap reads.
Additionally, even with a full-sized report, a corrupted
xfer->length field can cause memcpy to read beyond the report
buffer. The existing check only validates against the destination
buffer size, not the source data available in the report.
Add two checks: reject reports shorter than FT260_REPORT_MAX_LENGTH,
and verify that xfer->length does not exceed the actual data
available in the report. Log warnings to aid debugging.
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Josue Alba Vives <sebasjosue84@gmail.com>
---
drivers/hid/hid-ft260.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
index 333341e80..68008a423 100644
--- a/drivers/hid/hid-ft260.c
+++ b/drivers/hid/hid-ft260.c
@@ -1068,6 +1068,17 @@ static int ft260_raw_event(struct hid_device *hdev, struct hid_report *report,
struct ft260_device *dev = hid_get_drvdata(hdev);
struct ft260_i2c_input_report *xfer = (void *)data;
+ if (size < FT260_REPORT_MAX_LENGTH) {
+ hid_warn(hdev, "short report: %d\n", size);
+ return 0;
+ }
+
+ if (xfer->length > size - offsetof(struct ft260_i2c_input_report, data)) {
+ hid_warn(hdev, "payload %d exceeds report size %d\n",
+ xfer->length, size);
+ return 0;
+ }
+
if (xfer->report >= FT260_I2C_REPORT_MIN &&
xfer->report <= FT260_I2C_REPORT_MAX) {
ft260_dbg("i2c resp: rep %#02x len %d\n", xfer->report,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH AUTOSEL 6.19-6.18] HID: core: Mitigate potential OOB by removing bogus memset()
From: Thorsten Leemhuis @ 2026-03-30 13:26 UTC (permalink / raw)
To: Sasha Levin, patches, stable
Cc: Lee Jones, Benjamin Tissoires, jikos, linux-input, linux-kernel,
honjow
In-Reply-To: <20260324111931.3257972-18-sashal@kernel.org>
On 3/24/26 12:19, Sasha Levin wrote:
> From: Lee Jones <lee@kernel.org>
>
> [ Upstream commit 0a3fe972a7cb1404f693d6f1711f32bc1d244b1c ]
TWIMC, honjow (now CCed) reported a regression (GPD Win5 handhelds
stopped working) caused by this change – and provided a patch (which
misses a Fixes tag) to resolve it:
https://bugzilla.kernel.org/show_bug.cgi?id=221271
https://lore.kernel.org/all/20260324013847.68024-1-honjow311@gmail.com/
Ciao, Thorsten
> The memset() in hid_report_raw_event() has the good intention of
> clearing out bogus data by zeroing the area from the end of the incoming
> data string to the assumed end of the buffer. However, as we have
> previously seen, doing so can easily result in OOB reads and writes in
> the subsequent thread of execution.
>
> The current suggestion from one of the HID maintainers is to remove the
> memset() and simply return if the incoming event buffer size is not
> large enough to fill the associated report.
>
> Suggested-by Benjamin Tissoires <bentiss@kernel.org>
>
> Signed-off-by: Lee Jones <lee@kernel.org>
> [bentiss: changed the return value]
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>
> LLM Generated explanations, may be completely bogus:
>
> Now I have all the information needed to complete the analysis. Let me
> compile the full assessment.
>
> ---
>
> ## PHASE 1: COMMIT MESSAGE FORENSICS
>
> **Step 1.1: Subject Line**
> - Subsystem: `HID: core:`
> - Action verb: "Mitigate" (fix-oriented)
> - Summary: Removes a memset() that causes OOB reads/writes when incoming
> HID event data is shorter than expected report size.
> - Record: [HID core] [Mitigate/fix] [Remove memset that causes OOB
> memory corruption]
>
> **Step 1.2: Tags**
> - `Suggested-by: Benjamin Tissoires <bentiss@kernel.org>` — HID co-
> maintainer suggested the approach
> - `Signed-off-by: Lee Jones <lee@kernel.org>` — author
> - `[bentiss: changed the return value]` — maintainer modified the return
> value
> - `Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>` — applied by
> HID maintainer
> - No Fixes: tag (expected for candidates)
> - No Cc: stable (expected)
> - No Reported-by tag
> - Record: Suggested and accepted by the HID co-maintainer. Strong
> endorsement.
>
> **Step 1.3: Commit Body**
> - Bug: The `memset()` in `hid_report_raw_event()` zeros from `cdata +
> csize` to `cdata + rsize` when `csize < rsize`. However, the actual
> buffer may not be `rsize` bytes — it could be smaller, causing OOB
> writes.
> - "as we have previously seen" — acknowledges a history of OOB issues
> from this code.
> - The fix: reject short reports entirely with -EINVAL instead of zero-
> padding.
> - Record: OOB writes from memset writing past actual buffer boundary.
> Longstanding known issue class.
>
> **Step 1.4: Hidden Bug Fix Detection**
> - Not hidden — explicitly describes an OOB vulnerability fix. The word
> "mitigate" and "OOB" make it clear.
>
> ## PHASE 2: DIFF ANALYSIS
>
> **Step 2.1: Inventory**
> - Files: `drivers/hid/hid-core.c` (+4/-3 lines)
> - Function: `hid_report_raw_event()`
> - Scope: Single-file, single-function surgical fix
> - Record: [1 file, net +1 line] [hid_report_raw_event()] [Single-file
> surgical fix]
>
> **Step 2.2: Code Flow Change**
> - BEFORE: When `csize < rsize`, the code logs a debug message and calls
> `memset(cdata + csize, 0, rsize - csize)` to zero-pad the buffer, then
> continues processing.
> - AFTER: When `csize < rsize`, the code logs a rate-limited warning and
> returns `-EINVAL` via `goto out`, rejecting the short report entirely.
> - Record: [Short report path: zero-pad and continue → reject and return
> -EINVAL]
>
> **Step 2.3: Bug Mechanism**
> - Category: **Buffer overflow / OOB write** (memory safety)
> - Mechanism: `memset(cdata + csize, 0, rsize - csize)` writes zeros from
> the end of the actual received data to position `rsize`. But the
> underlying buffer (allocated by the transport layer) may only be
> `csize` bytes, meaning the memset writes past the buffer boundary.
> - Additionally, subsequent code (like `hid_process_report`) reads up to
> `rsize` bytes from the buffer, causing OOB reads.
> - Record: [OOB write from memset] [Buffer may be smaller than rsize,
> memset writes past end]
>
> **Step 2.4: Fix Quality**
> - Obviously correct: rejecting a too-short report is safer than
> attempting to zero-pad a buffer of unknown size.
> - Minimal: 4 lines changed, net +1 line.
> - Regression risk: Some devices that send short reports and relied on
> zero-padding will now have those reports rejected. Tissoires
> acknowledged this ("let's go with it and say sorry if we break some
> devices later on"), meaning the maintainer accepted this tradeoff.
> - Record: [High quality, minimal fix] [Low regression risk, maintainer-
> accepted tradeoff]
>
> ## PHASE 3: GIT HISTORY INVESTIGATION
>
> **Step 3.1: Blame**
> - The buggy memset line traces to `85cdaf524b7dda` ("HID: make a bus
> from hid code") from 2008-05-16.
> - This code has been present since Linux 2.6.26 — it exists in ALL
> active stable trees.
> - Record: [Buggy code from 2008, present in all stable trees]
>
> **Step 3.2: Fixes Tag**
> - No Fixes: tag present. However, the memset dates to 85cdaf524b7dda
> (2008).
>
> **Step 3.3: File History — Related Changes**
> - 966922f26c7fb (2011): Fixed crash from rsize being too large
> (536870912) causing memset crash
> - 5ebdffd250988 (2020): Fixed off-by-one in rsize calculation causing
> OOB memset
> - b1a37ed00d790 (2023): Added `max_buffer_size` attribute to cap rsize
> - ec61b41918587 (2022): Fixed shift-out-of-bounds in the processing
> after the memset
> - Record: **Long history of OOB/crash bugs from this exact memset**.
> This is the definitive fix.
>
> **Step 3.4: Author**
> - Lee Jones is a prolific kernel contributor and has previously worked
> on HID buffer size hardening (b1a37ed00d790).
> - Fix was suggested by and applied by Benjamin Tissoires, HID co-
> maintainer.
> - Record: [Experienced author, maintainer-endorsed fix]
>
> **Step 3.5: Dependencies**
> - The fix uses `hid_warn_ratelimited`, introduced in commit
> 1d64624243af8, which only entered v6.18.
> - For stable trees < 6.18, this would need trivial adaptation (use
> `hid_warn` or `dev_warn_ratelimited` instead).
> - The companion patch `e716edafedad4` (hid-multitouch report ID check)
> is independent — it adds a defense at the caller level, not a
> prerequisite.
> - Record: [Minor dependency on hid_warn_ratelimited macro for older
> trees, trivially resolvable]
>
> ## PHASE 4: MAILING LIST RESEARCH
>
>>From the lore.kernel.org investigation:
> - **v1 (2026-02-27)**: Initial version simply removed the memset
> entirely.
> - **Tissoires review (2026-03-02)**: Pushed back — removing memset alone
> isn't enough because `hid_process_report()` would still read OOB.
> Suggested rejecting short reports entirely.
> - **v3 (2026-03-09)**: Revised per Tissoires's feedback — now returns
> early with warning.
> - **Tissoires final review (2026-03-16)**: Endorsed, changed return to
> -EINVAL, noted "works in 99% of cases" since transport layers allocate
> big enough buffers.
> - Applied 2026-03-16, merged to Linus 2026-03-17.
> - No explicit stable nomination, but no objections to backporting
> either.
> - Record: [Thorough review by HID maintainer, iterated to correct
> approach, accepted]
>
> ## PHASE 5: CODE SEMANTIC ANALYSIS
>
> **Step 5.1: Functions Modified**
> - `hid_report_raw_event()` — the core HID report processing function.
>
> **Step 5.2: Callers**
> - `__hid_input_report()` in hid-core.c (line 2144) — **THE main HID
> input path** for all HID devices
> - `wacom_sys.c` — 3 call sites (Wacom tablet driver)
> - `hid-gfrm.c` — Google Fiber Remote
> - `hid-logitech-hidpp.c` — Logitech HID++
> - `hid-primax.c` — Primax keyboards
> - `hid-multitouch.c` — multitouch devices
> - `hid-vivaldi-common.c` — Vivaldi keyboard
> - Record: [Called from core HID input path and multiple drivers — very
> high impact surface]
>
> **Step 5.3-5.4: Call Chain**
> - USB HID: `hid_irq_in()` → `hid_input_report()` →
> `__hid_input_report()` → `hid_report_raw_event()`
> - This is reachable from any USB HID device event — keyboards, mice,
> touchscreens, gamepads, etc.
> - Also reachable from I2C-HID, BT-HID, and other transports.
> - Record: [Reachable from any HID device input — universal impact]
>
> ## PHASE 6: STABLE TREE ANALYSIS
>
> **Step 6.1: Buggy Code in Stable?**
> - The memset dates to 2008. Present in every stable tree.
> - Record: [ALL active stable trees contain the buggy code]
>
> **Step 6.2: Backport Complications**
> - `hid_warn_ratelimited` only in v6.18+. For older stable trees, trivial
> substitution needed (e.g., `hid_warn`).
> - The rest of the code context (csize, rsize, max_buffer_size, goto out)
> is identical in recent stable trees (verified: max_buffer_size was
> added in b1a37ed00d790 from 2023, present in 6.6+).
> - Record: [Minor adaptation needed for < 6.18, clean apply otherwise]
>
> **Step 6.3: Related Fixes in Stable**
> - Previous mitigations (max_buffer_size capping, off-by-one fix) are in
> stable but didn't eliminate the fundamental OOB risk.
> - Record: [No equivalent fix already in stable — this is the definitive
> solution]
>
> ## PHASE 7: SUBSYSTEM CONTEXT
>
> **Step 7.1: Subsystem Criticality**
> - HID core — every keyboard, mouse, touchscreen, gamepad, etc. goes
> through this code.
> - Criticality: **IMPORTANT** (affects virtually all desktop/laptop
> systems and many embedded devices)
>
> **Step 7.2: Subsystem Activity**
> - Very active — multiple fixes per release cycle.
>
> ## PHASE 8: IMPACT AND RISK ASSESSMENT
>
> **Step 8.1: Affected Users**
> - Every system with HID devices (USB, Bluetooth, I2C) — essentially
> universal for desktops/laptops.
>
> **Step 8.2: Trigger Conditions**
> - A HID device sends a report shorter than the expected report size.
> - Can be triggered by: malicious USB devices, faulty/buggy HID devices,
> or specific device configurations.
> - Potentially exploitable via USB (e.g., BadUSB attacks).
> - Record: [Trigger: short HID report] [Moderate likelihood for
> accidental, high for deliberate]
>
> **Step 8.3: Failure Mode**
> - **OOB write**: memset writes past buffer boundary → memory corruption,
> potential code execution
> - **OOB read**: subsequent `hid_process_report()` reads past buffer →
> info leak or crash
> - Severity: **CRITICAL** (OOB writes = security vulnerability, potential
> crash/corruption)
>
> **Step 8.4: Risk-Benefit**
> - Benefit: **VERY HIGH** — prevents OOB writes in a core, universally-
> used kernel path. Addresses a class of bugs that has caused multiple
> CVEs/crashes historically.
> - Risk: **VERY LOW** — 4-line change, simple logic (reject vs. pad),
> maintainer acknowledged 99% of cases won't be affected, accepted the
> tradeoff.
> - Ratio: Strongly favors backporting.
>
> ## PHASE 9: FINAL SYNTHESIS
>
> **Step 9.1: Evidence Summary**
>
> FOR backporting:
> - Fixes OOB writes and reads (security-critical memory safety bug)
> - In HID core — affects all HID users (universal impact)
> - Very small change: 4 lines, single function, single file
> - Bug exists since 2008 — present in ALL stable trees
> - Long history of crashes/CVEs from this exact memset (966922f, 5ebdffd,
> ec61b41)
> - Reviewed and applied by HID co-maintainer (Tissoires)
> - Suggested by the maintainer himself
> - Fix is the definitive solution after years of band-aid fixes
>
> AGAINST backporting:
> - Uses `hid_warn_ratelimited` not available before v6.18 (trivially
> adaptable)
> - Tissoires noted potential for breaking devices relying on zero-padding
> (accepted risk)
> - No explicit stable nomination (expected for candidates)
>
> **Step 9.2: Stable Rules Checklist**
> 1. Obviously correct and tested? **YES** — reviewed by maintainer,
> iterated through 3 versions
> 2. Fixes a real bug? **YES** — OOB write/read in HID core
> 3. Important issue? **YES** — security vulnerability (OOB write),
> potential crash/corruption
> 4. Small and contained? **YES** — 4 lines, single function
> 5. No new features or APIs? **YES** — behavior change only (reject
> instead of pad)
> 6. Can apply to stable? **YES** — with trivial adaptation for
> hid_warn_ratelimited
>
> **Step 9.3: Exception Categories**
> - Not an exception category — this is a standard critical bug fix.
>
> **Step 9.4: Decision**
> This is a clear YES. A 4-line fix to a critical OOB write vulnerability
> in the core HID input path, present since 2008, with a long history of
> related crashes, endorsed by the HID co-maintainer.
>
> ## Verification
>
> - [Phase 1] Parsed tags: Suggested-by Tissoires, SOB by Lee Jones and
> Tissoires (maintainer applied)
> - [Phase 2] Diff analysis: +4/-3 lines in hid_report_raw_event(),
> replaces memset+dbg_hid with warn+return -EINVAL
> - [Phase 3] git blame: buggy memset from commit 85cdaf524b7dda (2008,
> v2.6.26), present in all stable trees
> - [Phase 3] git log: found 3 prior fixes to same memset area (966922f,
> 5ebdffd, b1a37ed) — confirms recurring issue
> - [Phase 3] Author: Lee Jones authored the max_buffer_size hardening
> (b1a37ed), experienced with this code
> - [Phase 4] lore.kernel.org: v1 reviewed by Tissoires who requested
> stronger approach; v3 accepted with -EINVAL return; maintainer noted
> "works in 99% of cases"
> - [Phase 5] Callers: hid_report_raw_event() called from
> __hid_input_report() (core path) and 6+ drivers
> - [Phase 6] hid_warn_ratelimited introduced in v6.18 (1d64624243af8) —
> verified not in v6.12/6.14/6.15/6.16/6.17; needs trivial adaptation
> for older trees
> - [Phase 6] Companion patch e716edafedad4 is independent (hid-
> multitouch.c report ID check), not a prerequisite
> - [Phase 8] Failure mode: OOB writes via memset → memory corruption,
> severity CRITICAL
> - UNVERIFIED: Exact behavior with specific HID devices that send
> intentionally short reports (Tissoires accepted the risk)
>
> **YES**
>
> drivers/hid/hid-core.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index a5b3a8ca2fcbc..f5587b786f875 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -2057,9 +2057,10 @@ int hid_report_raw_event(struct hid_device *hid, enum hid_report_type type, u8 *
> rsize = max_buffer_size;
>
> if (csize < rsize) {
> - dbg_hid("report %d is too short, (%d < %d)\n", report->id,
> - csize, rsize);
> - memset(cdata + csize, 0, rsize - csize);
> + hid_warn_ratelimited(hid, "Event data for report %d was too short (%d vs %d)\n",
> + report->id, rsize, csize);
> + ret = -EINVAL;
> + goto out;
> }
>
> if ((hid->claimed & HID_CLAIMED_HIDDEV) && hid->hiddev_report_event)
^ permalink raw reply
* Re: [PATCH] hid: usbhid: fix deadlock in hid_post_reset()
From: Oliver Neukum @ 2026-03-30 11:43 UTC (permalink / raw)
To: Jiri Kosina; +Cc: bentiss, linux-input, linux-usb
In-Reply-To: <8q66o2o4-7844-6p76-9964-7pr205p190pr@xreary.bet>
On 27.03.26 11:34, Jiri Kosina wrote:
> Did you find this just by code inspection, or was this reported with a
> real device?
Pure inspection. We are looking at USB error handling
in general right now.
Regards
Oliver
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox