2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-07 21:40:34 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-12-07 21:40:34 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-07-06 15:44:41 -04:00
|
|
|
|
2012-01-13 09:32:15 +10:30
|
|
|
|
2005-07-06 15:44:41 -04:00
|
|
|
|
2024-11-20 08:56:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
modpost: deduplicate MODULE_ALIAS() for all drivers
MODULE_DEVICE_TABLE(pnp_card, ...) may have duplicated IDs. For
instance, snd_ad1816a_pnpids[] in sound/isa/ad1816a/ad1816a.c includes
multiple occurrences of the "ADS7180" string within its .devs fields.
Currently, do_pnp_card_entries() handles deduplication on its own, but
this logic should be moved to a common helper function, as drivers in
other subsystems might also have similar duplication issues.
For example, drivers/media/i2c/s5c73m3/s5c73m3.mod.c contains duplicated
MODULE_ALIAS() entries because both s5c73m3-core.c and s5c73m3-spi.c
define the same compatible string.
This commit eliminates redundant MODULE_ALIAS() entries across all
drivers.
[Before]
$ grep MODULE_ALIAS drivers/media/i2c/s5c73m3/s5c73m3.mod.c
MODULE_ALIAS("i2c:S5C73M3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3C*");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3C*");
[After]
$ grep MODULE_ALIAS drivers/media/i2c/s5c73m3/s5c73m3.mod.c
MODULE_ALIAS("i2c:S5C73M3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3C*");
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-20 08:56:42 +09:00
|
|
|
|
2024-11-20 08:56:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
modpost: deduplicate MODULE_ALIAS() for all drivers
MODULE_DEVICE_TABLE(pnp_card, ...) may have duplicated IDs. For
instance, snd_ad1816a_pnpids[] in sound/isa/ad1816a/ad1816a.c includes
multiple occurrences of the "ADS7180" string within its .devs fields.
Currently, do_pnp_card_entries() handles deduplication on its own, but
this logic should be moved to a common helper function, as drivers in
other subsystems might also have similar duplication issues.
For example, drivers/media/i2c/s5c73m3/s5c73m3.mod.c contains duplicated
MODULE_ALIAS() entries because both s5c73m3-core.c and s5c73m3-spi.c
define the same compatible string.
This commit eliminates redundant MODULE_ALIAS() entries across all
drivers.
[Before]
$ grep MODULE_ALIAS drivers/media/i2c/s5c73m3/s5c73m3.mod.c
MODULE_ALIAS("i2c:S5C73M3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3C*");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3C*");
[After]
$ grep MODULE_ALIAS drivers/media/i2c/s5c73m3/s5c73m3.mod.c
MODULE_ALIAS("i2c:S5C73M3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3");
MODULE_ALIAS("of:N*T*Csamsung,s5c73m3C*");
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-20 08:56:42 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-27 21:28:06 -07:00
|
|
|
|
2024-11-20 08:56:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-25 12:12:49 +02:00
|
|
|
|
|
|
|
|
|
2019-08-27 14:14:37 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-29 11:19:35 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-25 12:12:49 +02:00
|
|
|
|
2019-02-19 20:59:49 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2022-11-25 12:12:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-03 16:46:04 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-13 09:32:16 +10:30
|
|
|
|
2024-11-20 08:56:52 +09:00
|
|
|
|
2012-01-13 09:32:16 +10:30
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2012-01-13 09:32:16 +10:30
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-26 00:33:37 +09:00
|
|
|
|
|
|
|
|
|
2018-10-24 01:03:52 -03:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:43 +09:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-27 17:17:27 -07:00
|
|
|
|
2015-05-07 15:54:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-10 10:17:59 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-05-07 15:54:02 +03:00
|
|
|
|
|
|
|
|
|
2021-10-29 17:28:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
2012-05-18 21:27:43 +02:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
|
|
|
|
|
2009-11-18 20:11:23 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-18 20:11:23 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-07 19:15:11 +01:00
|
|
|
|
|
|
|
|
|
2009-11-18 20:11:23 -05:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
2024-11-20 08:56:41 +09:00
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
|
|
|
|
|
2009-11-18 20:15:28 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:49 +09:00
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
|
|
|
|
|
2009-11-18 20:11:23 -05:00
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
2009-11-18 20:11:23 -05:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2009-11-18 20:11:23 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
|
|
|
|
|
2009-11-18 20:11:23 -05:00
|
|
|
|
|
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-18 20:11:23 -05:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2009-11-18 20:15:28 -05:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2009-11-18 20:15:28 -05:00
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
2009-11-18 20:11:23 -05:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2009-11-18 20:15:28 -05:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2009-11-18 20:15:28 -05:00
|
|
|
|
2005-04-22 15:07:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:48 +09:00
|
|
|
|
modpost: fix module autoloading for OF devices with generic compatible property
Since the wildcard at the end of OF module aliases is gone, autoloading
of modules that don't match a device's last (most generic) compatible
value fails.
For example the CODA960 VPU on i.MX6Q has the SoC specific compatible
"fsl,imx6q-vpu" and the generic compatible "cnm,coda960". Since the
driver currently only works with knowledge about the SoC specific
integration, it doesn't list "cnm,cod960" in the module device table.
This results in the device compatible
"of:NvpuT<NULL>Cfsl,imx6q-vpuCcnm,coda960" not matching the module alias
"of:N*T*Cfsl,imx6q-vpu" anymore, whereas before commit 2f632369ab79
("modpost: don't add a trailing wildcard for OF module aliases") it
matched the module alias "of:N*T*Cfsl,imx6q-vpu*".
This patch adds two module aliases for each compatible, one without the
wildcard and one with "C*" appended.
$ modinfo coda | grep imx6q
alias: of:N*T*Cfsl,imx6q-vpuC*
alias: of:N*T*Cfsl,imx6q-vpu
Fixes: 2f632369ab79 ("modpost: don't add a trailing wildcard for OF module aliases")
Link: http://lkml.kernel.org/r/1462203339-15340-1-git-send-email-p.zabel@pengutronix.de
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org> [4.5+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-05 16:22:29 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-06 18:48:38 +02:00
|
|
|
|
modpost: fix module autoloading for OF devices with generic compatible property
Since the wildcard at the end of OF module aliases is gone, autoloading
of modules that don't match a device's last (most generic) compatible
value fails.
For example the CODA960 VPU on i.MX6Q has the SoC specific compatible
"fsl,imx6q-vpu" and the generic compatible "cnm,coda960". Since the
driver currently only works with knowledge about the SoC specific
integration, it doesn't list "cnm,cod960" in the module device table.
This results in the device compatible
"of:NvpuT<NULL>Cfsl,imx6q-vpuCcnm,coda960" not matching the module alias
"of:N*T*Cfsl,imx6q-vpu" anymore, whereas before commit 2f632369ab79
("modpost: don't add a trailing wildcard for OF module aliases") it
matched the module alias "of:N*T*Cfsl,imx6q-vpu*".
This patch adds two module aliases for each compatible, one without the
wildcard and one with "C*" appended.
$ modinfo coda | grep imx6q
alias: of:N*T*Cfsl,imx6q-vpuC*
alias: of:N*T*Cfsl,imx6q-vpu
Fixes: 2f632369ab79 ("modpost: don't add a trailing wildcard for OF module aliases")
Link: http://lkml.kernel.org/r/1462203339-15340-1-git-send-email-p.zabel@pengutronix.de
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org> [4.5+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-05 16:22:29 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:41 +09:00
|
|
|
|
|
|
|
|
|
modpost: fix module autoloading for OF devices with generic compatible property
Since the wildcard at the end of OF module aliases is gone, autoloading
of modules that don't match a device's last (most generic) compatible
value fails.
For example the CODA960 VPU on i.MX6Q has the SoC specific compatible
"fsl,imx6q-vpu" and the generic compatible "cnm,coda960". Since the
driver currently only works with knowledge about the SoC specific
integration, it doesn't list "cnm,cod960" in the module device table.
This results in the device compatible
"of:NvpuT<NULL>Cfsl,imx6q-vpuCcnm,coda960" not matching the module alias
"of:N*T*Cfsl,imx6q-vpu" anymore, whereas before commit 2f632369ab79
("modpost: don't add a trailing wildcard for OF module aliases") it
matched the module alias "of:N*T*Cfsl,imx6q-vpu*".
This patch adds two module aliases for each compatible, one without the
wildcard and one with "C*" appended.
$ modinfo coda | grep imx6q
alias: of:N*T*Cfsl,imx6q-vpuC*
alias: of:N*T*Cfsl,imx6q-vpu
Fixes: 2f632369ab79 ("modpost: don't add a trailing wildcard for OF module aliases")
Link: http://lkml.kernel.org/r/1462203339-15340-1-git-send-email-p.zabel@pengutronix.de
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Brian Norris <computersforpeace@gmail.com>
Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org> [4.5+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-05-05 16:22:29 -07:00
|
|
|
|
|
|
|
|
|
2008-05-19 15:50:01 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2008-05-19 15:50:01 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-19 15:50:01 +02:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-19 15:50:01 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2008-05-19 15:50:01 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-08-26 13:39:09 +03:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-26 13:39:09 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-28 16:57:26 +01:00
|
|
|
|
2024-11-20 08:56:44 +09:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-03 16:46:04 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-09-20 15:58:25 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2006-09-20 15:58:25 +02:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2006-09-20 15:58:25 +02:00
|
|
|
|
|
|
|
|
|
2008-07-14 09:58:44 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2008-07-14 09:58:44 +02:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2008-07-14 09:58:44 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
ACPI / scan: Add support for ACPI _CLS device matching
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
acpi_match_table to match devices. However, for generic drivers, we do not
want to list _HID for all supported devices. Also, certain classes of devices
do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface). This patch adds support for matching ACPI devices using
the _CLS method.
To support loadable module, current design uses _HID or _CID to match device's
modalias. With the new way of matching with _CLS this would requires modification
to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
class-code to the existing ACPI modalias as following.
acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
E.g:
# cat /sys/devices/platform/AMDI0600:00/modalias
acpi:AMDI0600:010601:
where bb is th base-class code, ss is te sub-class code, and pp is the
programming interface code
Since there would not be _HID/_CID in the ACPI matching table of the driver,
this patch adds a field to acpi_device_id to specify the matching _CLS.
static const struct acpi_device_id ahci_acpi_match[] = {
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
{},
};
In this case, the corresponded entry in modules.alias file would be:
alias acpi*:010601:* ahci_platform
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-07 01:55:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2007-07-23 14:43:51 +02:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2024-11-03 21:46:50 +09:00
|
|
|
|
|
|
|
|
|
ACPI / scan: Add support for ACPI _CLS device matching
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
acpi_match_table to match devices. However, for generic drivers, we do not
want to list _HID for all supported devices. Also, certain classes of devices
do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface). This patch adds support for matching ACPI devices using
the _CLS method.
To support loadable module, current design uses _HID or _CID to match device's
modalias. With the new way of matching with _CLS this would requires modification
to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
class-code to the existing ACPI modalias as following.
acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
E.g:
# cat /sys/devices/platform/AMDI0600:00/modalias
acpi:AMDI0600:010601:
where bb is th base-class code, ss is te sub-class code, and pp is the
programming interface code
Since there would not be _HID/_CID in the ACPI matching table of the driver,
this patch adds a field to acpi_device_id to specify the matching _CLS.
static const struct acpi_device_id ahci_acpi_match[] = {
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
{},
};
In this case, the corresponded entry in modules.alias file would be:
alias acpi*:010601:* ahci_platform
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-07 01:55:20 +02:00
|
|
|
|
2024-11-20 08:56:40 +09:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2024-11-03 21:46:50 +09:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
ACPI / scan: Add support for ACPI _CLS device matching
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
acpi_match_table to match devices. However, for generic drivers, we do not
want to list _HID for all supported devices. Also, certain classes of devices
do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface). This patch adds support for matching ACPI devices using
the _CLS method.
To support loadable module, current design uses _HID or _CID to match device's
modalias. With the new way of matching with _CLS this would requires modification
to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
class-code to the existing ACPI modalias as following.
acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
E.g:
# cat /sys/devices/platform/AMDI0600:00/modalias
acpi:AMDI0600:010601:
where bb is th base-class code, ss is te sub-class code, and pp is the
programming interface code
Since there would not be _HID/_CID in the ACPI matching table of the driver,
this patch adds a field to acpi_device_id to specify the matching _CLS.
static const struct acpi_device_id ahci_acpi_match[] = {
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
{},
};
In this case, the corresponded entry in modules.alias file would be:
alias acpi*:010601:* ahci_platform
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-07 01:55:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-03 21:46:50 +09:00
|
|
|
|
ACPI / scan: Add support for ACPI _CLS device matching
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
acpi_match_table to match devices. However, for generic drivers, we do not
want to list _HID for all supported devices. Also, certain classes of devices
do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface). This patch adds support for matching ACPI devices using
the _CLS method.
To support loadable module, current design uses _HID or _CID to match device's
modalias. With the new way of matching with _CLS this would requires modification
to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
class-code to the existing ACPI modalias as following.
acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
E.g:
# cat /sys/devices/platform/AMDI0600:00/modalias
acpi:AMDI0600:010601:
where bb is th base-class code, ss is te sub-class code, and pp is the
programming interface code
Since there would not be _HID/_CID in the ACPI matching table of the driver,
this patch adds a field to acpi_device_id to specify the matching _CLS.
static const struct acpi_device_id ahci_acpi_match[] = {
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
{},
};
In this case, the corresponded entry in modules.alias file would be:
alias acpi*:010601:* ahci_platform
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-07 01:55:20 +02:00
|
|
|
|
|
|
|
|
|
2024-11-03 21:46:50 +09:00
|
|
|
|
ACPI / scan: Add support for ACPI _CLS device matching
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
acpi_match_table to match devices. However, for generic drivers, we do not
want to list _HID for all supported devices. Also, certain classes of devices
do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface). This patch adds support for matching ACPI devices using
the _CLS method.
To support loadable module, current design uses _HID or _CID to match device's
modalias. With the new way of matching with _CLS this would requires modification
to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
class-code to the existing ACPI modalias as following.
acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
E.g:
# cat /sys/devices/platform/AMDI0600:00/modalias
acpi:AMDI0600:010601:
where bb is th base-class code, ss is te sub-class code, and pp is the
programming interface code
Since there would not be _HID/_CID in the ACPI matching table of the driver,
this patch adds a field to acpi_device_id to specify the matching _CLS.
static const struct acpi_device_id ahci_acpi_match[] = {
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
{},
};
In this case, the corresponded entry in modules.alias file would be:
alias acpi*:010601:* ahci_platform
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-07 01:55:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
ACPI / scan: Add support for ACPI _CLS device matching
Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
acpi_match_table to match devices. However, for generic drivers, we do not
want to list _HID for all supported devices. Also, certain classes of devices
do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
which specifies PCI-defined class code (i.e. base-class, subclass and
programming interface). This patch adds support for matching ACPI devices using
the _CLS method.
To support loadable module, current design uses _HID or _CID to match device's
modalias. With the new way of matching with _CLS this would requires modification
to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
class-code to the existing ACPI modalias as following.
acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
E.g:
# cat /sys/devices/platform/AMDI0600:00/modalias
acpi:AMDI0600:010601:
where bb is th base-class code, ss is te sub-class code, and pp is the
programming interface code
Since there would not be _HID/_CID in the ACPI matching table of the driver,
this patch adds a field to acpi_device_id to specify the matching _CLS.
static const struct acpi_device_id ahci_acpi_match[] = {
{ ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
{},
};
In this case, the corresponded entry in modules.alias file would be:
alias acpi*:010601:* ahci_platform
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-07 01:55:20 +02:00
|
|
|
|
2007-07-23 14:43:51 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-20 08:56:47 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-20 08:56:47 +09:00
|
|
|
|
|
|
|
|
|
2009-01-08 03:06:42 +01:00
|
|
|
|
2024-11-20 08:56:47 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-02-21 00:35:54 +01:00
|
|
|
|
2024-11-20 08:56:46 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-20 08:56:46 +09:00
|
|
|
|
2008-02-21 00:35:54 +01:00
|
|
|
|
2024-11-20 08:56:46 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-21 00:35:54 +01:00
|
|
|
|
2024-11-20 08:56:46 +09:00
|
|
|
|
|
|
|
|
|
2008-02-21 00:35:54 +01:00
|
|
|
|
2024-11-20 08:56:46 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-08 03:06:42 +01:00
|
|
|
|
2024-11-20 08:56:46 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-27 16:28:12 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-06-27 16:28:12 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2024-12-26 00:33:37 +09:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-25 14:39:46 +02:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-26 00:33:37 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-06-27 16:28:12 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-06-27 16:28:12 -07:00
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-08-17 16:42:59 +10:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-08-17 16:42:59 +10:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
2005-08-17 16:42:59 +10:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
2005-08-17 16:42:59 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-08-17 16:42:59 +10:00
|
|
|
|
|
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-07 21:40:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-26 00:14:19 -04:00
|
|
|
|
2024-12-26 00:33:35 +09:00
|
|
|
|
2024-12-26 00:33:37 +09:00
|
|
|
|
|
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
2005-12-07 21:40:34 +01:00
|
|
|
|
|
|
|
|
|
2017-10-22 11:42:29 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-12-07 21:40:34 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-07 21:40:34 +01:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
2007-03-09 19:59:06 +01:00
|
|
|
|
|
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2005-12-07 21:40:34 +01:00
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2006-09-27 01:50:56 -07:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2006-09-27 01:50:56 -07:00
|
|
|
|
|
|
|
|
|
2007-01-13 14:58:21 -05:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2007-01-13 14:58:21 -05:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-13 14:58:21 -05:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-13 14:58:21 -05:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2007-01-13 14:58:21 -05:00
|
|
|
|
|
|
|
|
|
2007-06-17 11:34:23 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2007-06-17 11:34:23 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-17 11:34:23 +02:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2007-10-11 19:40:14 -07:00
|
|
|
|
|
|
|
|
|
2007-09-18 15:12:50 -04:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2007-09-18 15:12:50 -04:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-17 11:34:23 +02:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2007-06-17 11:34:23 +02:00
|
|
|
|
|
|
|
|
|
2011-05-09 18:56:46 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2011-05-09 18:56:46 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-09 18:56:46 +02:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2011-05-09 18:56:46 +02:00
|
|
|
|
|
|
|
|
|
2007-10-22 11:03:39 +10:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2007-10-22 11:03:39 +10:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
2007-10-22 11:03:39 +10:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
2007-10-22 11:03:39 +10:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2007-10-22 11:03:39 +10:00
|
|
|
|
|
|
|
|
|
2011-08-25 09:48:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2011-08-25 09:48:30 -07:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2024-12-26 00:33:36 +09:00
|
|
|
|
2011-08-25 09:48:30 -07:00
|
|
|
|
2024-12-26 00:33:36 +09:00
|
|
|
|
|
|
|
|
|
2011-08-25 09:48:30 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2011-08-25 09:48:30 -07:00
|
|
|
|
|
|
|
|
|
2018-04-21 18:55:29 -05:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2018-04-21 18:55:29 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2018-04-21 18:55:29 -05:00
|
|
|
|
|
|
|
|
|
2008-04-29 23:11:39 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2008-04-29 23:11:39 +02:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2008-04-29 23:11:39 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2008-04-29 23:11:39 +02:00
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2020-02-27 12:31:08 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2020-02-27 12:31:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2020-02-27 12:31:08 +01:00
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2024-09-02 15:10:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2024-09-02 15:10:04 +01:00
|
|
|
|
|
|
|
|
|
2009-09-22 16:46:08 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2009-09-22 16:46:04 -07:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2009-09-22 16:46:04 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2009-09-22 16:46:04 -07:00
|
|
|
|
|
|
|
|
|
2008-09-16 16:23:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-06 11:35:50 +02:00
|
|
|
|
|
|
|
|
|
2008-09-16 16:23:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
2008-09-16 16:23:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-16 16:23:28 -07:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
|
|
|
|
|
2008-09-16 16:23:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2008-09-16 16:23:28 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
|
|
|
|
|
2008-09-16 16:23:28 -07:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2008-09-16 16:23:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
modpost: prevent stack buffer overflow in do_input_entry() and do_dmi_entry()
Several functions in scripts/mod/file2alias.c build the module alias
string by repeatedly appending into a fixed-size on-stack buffer:
char alias[256] = {};
...
sprintf(alias + strlen(alias), "%X,*", i);
This pattern is unbounded and silently corrupts the stack when the
formatted output exceeds the destination size. Two functions in this
file are realistically reachable with input that overflows their
buffer:
1. do_input_entry() appends across nine bitmap classes
(evbit/keybit/relbit/absbit/mscbit/ledbit/sndbit/ffbit/swbit). The
keybit case alone scans bits from INPUT_DEVICE_ID_KEY_MIN_INTERESTING
(0x71) to INPUT_DEVICE_ID_KEY_MAX (0x2ff), 655 iterations; if a
MODULE_DEVICE_TABLE(input, ...) populates keybit[] densely, the
emission reaches ~3132 bytes — overflowing the 256-byte buffer by
about 12x. include/linux/mod_devicetable.h declares storage for the
full bit range ("keybit[INPUT_DEVICE_ID_KEY_MAX / BITS_PER_LONG + 1]"),
so the worst case is reachable per the ABI.
2. do_dmi_entry() emits one ":<prefix>*<filtered_substr>*" segment per
matched DMI field, up to 4 matches per dmi_system_id. Each substr
is sized as char[79] in struct dmi_strmatch (mod_devicetable.h:584),
and dmi_ascii_filter() copies it verbatim into the alias buffer
without bounds. Worst case: 4 × (1 + 3 + 1 + 79 + 1) = 336 bytes
into alias[256], an 80-byte overflow.
No driver in the current tree triggers either case — every in-tree
INPUT_DEVICE_ID_MATCH_KEYBIT user populates keybit[] very sparsely
(1-3 bits), and no in-tree dmi_system_id has four maximally-long
matches. The concern is defense-in-depth: both unbounded sprintf
chains are silent stack-corruption primitives in a host build tool,
and the buffer sizes have not been revisited since the corresponding
code was first introduced.
The other do_*_entry() handlers in this file (do_usb_entry,
do_cpu_entry, do_typec_entry, ...) were audited and are bounded by
their input field sizes (uint16 IDs, fixed-length keys); their alias
buffers do not need this treatment.
Reproduced under AddressSanitizer with a stand-alone harness mirroring
do_input on a fully-populated keybit:
==18319==ERROR: AddressSanitizer: stack-buffer-overflow
WRITE of size 2 at offset 288 in frame [32, 288) 'alias'
#6 do_input poc.c:44
Stack-canary build:
Abort trap: 6 (strlen(alias)=3134, cap was 256-1)
Add a small alias_append() helper around vsnprintf with a remaining-
space check and call fatal() on overflow, matching the modpost style
for unrecoverable build conditions. do_input() takes the buffer size
as a new parameter; do_input_entry() and do_dmi_entry() pass
sizeof(alias) at every call site. dmi_ascii_filter() takes the
remaining buffer size as well and aborts on truncation. This bounds
every write into the on-stack buffers and turns the latent overflow
into a clean build error if it is ever reached.
Fixes: 1d8f430c15b3 ("[PATCH] Input: add modalias support")
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Hasan Basbunar <basbunarhasan@gmail.com>
Link: https://patch.msgid.link/20260505161102.44087-1-basbunarhasan@gmail.com
Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-05-05 18:11:02 +02:00
|
|
|
|
2008-09-16 16:23:28 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2008-09-16 16:23:28 -07:00
|
|
|
|
2009-02-04 11:52:40 +08:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2009-02-04 11:52:40 +08:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2009-02-04 11:52:40 +08:00
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2010-04-02 01:05:27 +00:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2010-04-02 01:05:27 +00:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
2010-04-02 01:05:27 +00:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2010-04-02 01:05:27 +00:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2010-04-02 01:05:27 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2010-04-02 01:05:27 +00:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2010-04-02 01:05:27 +00:00
|
|
|
|
|
|
|
|
|
2008-11-18 21:13:53 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2008-11-18 21:13:53 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2008-11-18 21:13:53 +01:00
|
|
|
|
|
|
|
|
|
2009-12-18 20:52:39 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2009-12-18 20:52:39 +01:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-18 20:52:39 +01:00
|
|
|
|
|
|
|
|
|
2012-09-04 17:01:13 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2012-09-04 17:01:13 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2012-09-04 17:01:13 +02:00
|
|
|
|
|
|
|
|
|
2011-10-05 14:44:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2011-10-05 14:44:57 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2011-10-05 14:44:57 +01:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
2011-10-05 14:44:57 +01:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
2022-11-09 14:30:55 +01:00
|
|
|
|
2024-11-20 08:56:44 +09:00
|
|
|
|
2011-10-05 14:44:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
2011-10-05 14:44:57 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2011-10-05 14:44:57 +01:00
|
|
|
|
|
|
|
|
|
2015-03-25 15:39:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2015-03-25 15:39:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2015-03-25 15:39:50 +00:00
|
|
|
|
|
|
|
|
|
2014-02-08 13:34:10 +01:00
|
|
|
|
2012-01-26 00:09:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2012-01-26 00:09:05 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-26 00:09:05 +01:00
|
|
|
|
2014-02-08 13:34:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-11 22:57:19 +00:00
|
|
|
|
2013-01-20 17:58:47 +01:00
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2012-01-26 00:09:05 +01:00
|
|
|
|
|
|
|
|
|
2014-02-08 13:34:09 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2014-02-08 13:34:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2014-02-08 13:34:09 +01:00
|
|
|
|
|
|
|
|
|
2025-12-02 09:42:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-10 10:18:01 +03:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2013-03-27 17:29:53 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-03-27 17:29:53 +02:00
|
|
|
|
2015-05-07 15:54:02 +03:00
|
|
|
|
2015-09-10 10:18:01 +03:00
|
|
|
|
2015-05-07 15:54:02 +03:00
|
|
|
|
|
|
|
|
|
2015-09-10 10:18:01 +03:00
|
|
|
|
2013-03-27 17:29:53 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-03-27 17:29:53 +02:00
|
|
|
|
|
|
|
|
|
2013-07-03 15:08:58 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2013-07-03 15:08:58 -07:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2013-07-03 15:08:58 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2013-07-03 15:08:58 -07:00
|
|
|
|
|
|
|
|
|
2015-05-13 15:26:42 +03:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2015-05-13 15:26:42 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2015-05-13 15:26:42 +03:00
|
|
|
|
|
|
|
|
|
2015-09-29 13:56:10 +05:30
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2015-09-29 13:56:10 +05:30
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2015-09-29 13:56:10 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2015-09-29 13:56:10 +05:30
|
|
|
|
|
|
|
|
|
2020-06-09 04:54:35 +08:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2017-12-14 11:19:33 +05:30
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2017-12-14 11:19:33 +05:30
|
|
|
|
|
|
|
|
|
2020-06-09 04:54:35 +08:00
|
|
|
|
|
|
|
|
|
2017-12-14 11:19:33 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-09 04:54:35 +08:00
|
|
|
|
|
|
|
|
|
2017-12-14 11:19:33 +05:30
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2017-12-14 11:19:33 +05:30
|
|
|
|
|
|
|
|
|
2016-06-22 16:40:45 -05:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2016-06-22 16:40:45 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2016-06-22 16:40:45 -05:00
|
|
|
|
|
|
|
|
|
2017-10-02 13:38:34 +03:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2017-10-02 13:38:34 +03:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2017-10-02 13:38:34 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2017-10-02 13:38:34 +03:00
|
|
|
|
|
|
|
|
|
2024-12-13 15:35:42 -08:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2018-06-27 18:19:50 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-13 15:35:42 -08:00
|
|
|
|
2018-06-27 18:19:50 +03:00
|
|
|
|
|
|
|
|
|
2019-01-29 11:19:35 +05:30
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2019-01-29 11:19:35 +05:30
|
|
|
|
2023-10-08 02:04:44 +09:00
|
|
|
|
2019-01-29 11:19:35 +05:30
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2023-10-08 02:04:44 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-29 11:19:35 +05:30
|
|
|
|
|
|
|
|
|
2019-02-19 20:59:50 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2019-02-19 20:59:50 +01:00
|
|
|
|
|
|
|
|
|
2026-06-10 22:34:53 +02:00
|
|
|
|
|
|
|
|
|
2019-02-19 20:59:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:44 +09:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2019-02-19 20:59:50 +01:00
|
|
|
|
|
|
|
|
|
2026-06-10 22:34:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-19 20:59:50 +01:00
|
|
|
|
|
|
|
|
|
2020-02-20 15:28:50 +05:30
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2020-02-20 15:28:50 +05:30
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2020-12-02 16:54:24 -08:00
|
|
|
|
|
|
|
|
|
2022-04-05 19:27:54 +05:30
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2022-04-05 19:27:54 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2022-04-05 19:27:54 +05:30
|
|
|
|
|
|
|
|
|
2021-10-29 17:28:56 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2021-10-29 17:28:56 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2023-10-08 02:04:45 +09:00
|
|
|
|
2021-10-29 17:28:56 +02:00
|
|
|
|
2023-10-08 02:04:45 +09:00
|
|
|
|
2021-10-29 17:28:56 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2021-10-29 17:28:56 +02:00
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2020-12-02 16:54:24 -08:00
|
|
|
|
|
|
|
|
|
2020-02-20 15:28:50 +05:30
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2020-02-20 15:28:50 +05:30
|
|
|
|
|
|
|
|
|
2020-12-21 19:39:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2020-12-21 19:39:56 +01:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2020-12-21 19:39:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2020-12-21 19:39:56 +01:00
|
|
|
|
|
|
|
|
|
2021-01-06 20:37:11 -08:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2021-01-06 20:37:11 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2021-01-06 20:37:11 -08:00
|
|
|
|
|
|
|
|
|
2023-03-13 18:56:30 +05:30
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2023-03-13 18:56:30 +05:30
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2023-03-13 18:56:30 +05:30
|
|
|
|
|
|
|
|
|
2023-10-17 21:35:05 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-31 18:15:57 +05:30
|
|
|
|
2023-03-13 18:56:30 +05:30
|
|
|
|
2023-05-31 18:15:57 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2023-05-31 18:15:57 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-17 21:35:05 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2023-03-13 18:56:30 +05:30
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2023-10-19 14:31:26 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2023-10-19 14:31:26 +05:30
|
|
|
|
|
|
|
|
|
2024-02-12 09:50:06 -05:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2024-02-12 09:50:06 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2024-02-12 09:50:06 -05:00
|
|
|
|
|
|
|
|
|
2012-01-13 09:32:15 +10:30
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-01-13 09:32:15 +10:30
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-01-13 09:32:15 +10:30
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
modpost: improve error messages in device_id_check()
The first error message in device_id_check() is obscure and can be
misleading because the cause of the error is unlikely to be found in
the struct definition in mod_devicetable.h.
This type of error occurs when an array is passed to an incorrect type
of MODULE_DEVICE_TABLE().
[Example 1]
static const struct acpi_device_id foo_ids[] = {
{ "FOO" },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, foo_ids);
Currently, modpost outputs a meaningless suggestion:
ERROR: modpost: ...: sizeof(struct of_device_id)=200 is not a modulo of the size of section __mod_device_table__of__<identifier>=64.
Fix definition of struct of_device_id in mod_devicetable.h
The root cause here is that MODULE_DEVICE_TABLE(of, ...) is used instead
of the correct MODULE_DEVICE_TABLE(acpi, ...).
This commit provides a more intuitive error message:
ERROR: modpost: ...: type mismatch between foo_ids[] and MODULE_DEVICE_TABLE(of, ...)
The second error message, related to a missing terminator, is too
verbose.
[Example 2]
static const struct acpi_device_id foo_ids[] = {
{ "FOO" },
};
MODULE_DEVICE_TABLE(acpi, foo_ids);
The current error message is overly long, and does not pinpoint the
incorrect array:
...: struct acpi_device_id is 32 bytes. The last of 1 is:
0x46 0x4f 0x4f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
ERROR: modpost: ...: struct acpi_device_id is not terminated with a NULL entry!
This commit changes it to a more concise error message, sufficient to
identify the incorrect array:
ERROR: modpost: ...: foo_ids[] is not terminated with a NULL entry
Lastly, this commit squashes device_id_check() into do_table() and
changes fatal() into error(), allowing modpost to continue processing
other modules.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-20 08:56:53 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-07-09 16:26:07 +02:00
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
modpost: improve error messages in device_id_check()
The first error message in device_id_check() is obscure and can be
misleading because the cause of the error is unlikely to be found in
the struct definition in mod_devicetable.h.
This type of error occurs when an array is passed to an incorrect type
of MODULE_DEVICE_TABLE().
[Example 1]
static const struct acpi_device_id foo_ids[] = {
{ "FOO" },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, foo_ids);
Currently, modpost outputs a meaningless suggestion:
ERROR: modpost: ...: sizeof(struct of_device_id)=200 is not a modulo of the size of section __mod_device_table__of__<identifier>=64.
Fix definition of struct of_device_id in mod_devicetable.h
The root cause here is that MODULE_DEVICE_TABLE(of, ...) is used instead
of the correct MODULE_DEVICE_TABLE(acpi, ...).
This commit provides a more intuitive error message:
ERROR: modpost: ...: type mismatch between foo_ids[] and MODULE_DEVICE_TABLE(of, ...)
The second error message, related to a missing terminator, is too
verbose.
[Example 2]
static const struct acpi_device_id foo_ids[] = {
{ "FOO" },
};
MODULE_DEVICE_TABLE(acpi, foo_ids);
The current error message is overly long, and does not pinpoint the
incorrect array:
...: struct acpi_device_id is 32 bytes. The last of 1 is:
0x46 0x4f 0x4f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
ERROR: modpost: ...: struct acpi_device_id is not terminated with a NULL entry!
This commit changes it to a more concise error message, sufficient to
identify the incorrect array:
ERROR: modpost: ...: foo_ids[] is not terminated with a NULL entry
Lastly, this commit squashes device_id_check() into do_table() and
changes fatal() into error(), allowing modpost to continue processing
other modules.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-20 08:56:53 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:45 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2018-11-22 13:28:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-27 12:31:08 +01:00
|
|
|
|
2024-09-02 15:10:04 +01:00
|
|
|
|
2018-11-22 13:28:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-02 09:42:00 +01:00
|
|
|
|
2018-11-22 13:28:41 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-29 11:19:35 +05:30
|
|
|
|
2019-02-19 20:59:50 +01:00
|
|
|
|
2020-02-20 15:28:50 +05:30
|
|
|
|
2022-04-05 19:27:54 +05:30
|
|
|
|
2020-12-02 16:54:24 -08:00
|
|
|
|
2020-12-21 19:39:56 +01:00
|
|
|
|
2021-01-06 20:37:11 -08:00
|
|
|
|
2021-10-29 17:28:56 +02:00
|
|
|
|
2023-03-13 18:56:30 +05:30
|
|
|
|
2023-10-19 14:31:26 +05:30
|
|
|
|
2024-02-12 09:50:06 -05:00
|
|
|
|
2024-11-20 08:56:48 +09:00
|
|
|
|
2024-11-20 08:56:49 +09:00
|
|
|
|
2024-11-20 08:56:47 +09:00
|
|
|
|
2024-11-20 08:56:46 +09:00
|
|
|
|
2018-11-22 13:28:41 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-16 11:15:46 +02:00
|
|
|
|
2025-09-18 10:05:50 +02:00
|
|
|
|
2025-09-18 10:05:51 +02:00
|
|
|
|
2024-11-20 08:56:52 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-07-29 01:47:53 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-04-12 14:37:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-18 10:05:50 +02:00
|
|
|
|
2024-11-20 08:56:52 +09:00
|
|
|
|
2012-01-13 09:32:15 +10:30
|
|
|
|
2025-09-18 10:05:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-18 10:05:51 +02:00
|
|
|
|
2025-09-18 10:05:50 +02:00
|
|
|
|
2024-11-20 08:56:52 +09:00
|
|
|
|
2024-11-20 08:56:51 +09:00
|
|
|
|
|
|
|
|
|
2014-02-03 11:14:13 +10:30
|
|
|
|
2024-11-20 08:56:51 +09:00
|
|
|
|
modpost: improve error messages in device_id_check()
The first error message in device_id_check() is obscure and can be
misleading because the cause of the error is unlikely to be found in
the struct definition in mod_devicetable.h.
This type of error occurs when an array is passed to an incorrect type
of MODULE_DEVICE_TABLE().
[Example 1]
static const struct acpi_device_id foo_ids[] = {
{ "FOO" },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, foo_ids);
Currently, modpost outputs a meaningless suggestion:
ERROR: modpost: ...: sizeof(struct of_device_id)=200 is not a modulo of the size of section __mod_device_table__of__<identifier>=64.
Fix definition of struct of_device_id in mod_devicetable.h
The root cause here is that MODULE_DEVICE_TABLE(of, ...) is used instead
of the correct MODULE_DEVICE_TABLE(acpi, ...).
This commit provides a more intuitive error message:
ERROR: modpost: ...: type mismatch between foo_ids[] and MODULE_DEVICE_TABLE(of, ...)
The second error message, related to a missing terminator, is too
verbose.
[Example 2]
static const struct acpi_device_id foo_ids[] = {
{ "FOO" },
};
MODULE_DEVICE_TABLE(acpi, foo_ids);
The current error message is overly long, and does not pinpoint the
incorrect array:
...: struct acpi_device_id is 32 bytes. The last of 1 is:
0x46 0x4f 0x4f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
ERROR: modpost: ...: struct acpi_device_id is not terminated with a NULL entry!
This commit changes it to a more concise error message, sufficient to
identify the incorrect array:
ERROR: modpost: ...: foo_ids[] is not terminated with a NULL entry
Lastly, this commit squashes device_id_check() into do_table() and
changes fatal() into error(), allowing modpost to continue processing
other modules.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-20 08:56:53 +09:00
|
|
|
|
2012-01-13 09:32:15 +10:30
|
|
|
|
2007-09-16 11:15:46 +02:00
|
|
|
|
2010-07-29 01:47:53 +02:00
|
|
|
|
2007-09-16 11:15:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-20 01:53:00 +09:00
|
|
|
|
2007-09-16 11:15:46 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-20 08:56:49 +09:00
|
|
|
|
|
|
|
|
|
2012-01-13 09:32:15 +10:30
|
|
|
|
2024-11-20 08:56:51 +09:00
|
|
|
|
modpost: improve error messages in device_id_check()
The first error message in device_id_check() is obscure and can be
misleading because the cause of the error is unlikely to be found in
the struct definition in mod_devicetable.h.
This type of error occurs when an array is passed to an incorrect type
of MODULE_DEVICE_TABLE().
[Example 1]
static const struct acpi_device_id foo_ids[] = {
{ "FOO" },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, foo_ids);
Currently, modpost outputs a meaningless suggestion:
ERROR: modpost: ...: sizeof(struct of_device_id)=200 is not a modulo of the size of section __mod_device_table__of__<identifier>=64.
Fix definition of struct of_device_id in mod_devicetable.h
The root cause here is that MODULE_DEVICE_TABLE(of, ...) is used instead
of the correct MODULE_DEVICE_TABLE(acpi, ...).
This commit provides a more intuitive error message:
ERROR: modpost: ...: type mismatch between foo_ids[] and MODULE_DEVICE_TABLE(of, ...)
The second error message, related to a missing terminator, is too
verbose.
[Example 2]
static const struct acpi_device_id foo_ids[] = {
{ "FOO" },
};
MODULE_DEVICE_TABLE(acpi, foo_ids);
The current error message is overly long, and does not pinpoint the
incorrect array:
...: struct acpi_device_id is 32 bytes. The last of 1 is:
0x46 0x4f 0x4f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
ERROR: modpost: ...: struct acpi_device_id is not terminated with a NULL entry!
This commit changes it to a more concise error message, sufficient to
identify the incorrect array:
ERROR: modpost: ...: foo_ids[] is not terminated with a NULL entry
Lastly, this commit squashes device_id_check() into do_table() and
changes fatal() into error(), allowing modpost to continue processing
other modules.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-20 08:56:53 +09:00
|
|
|
|
2024-11-20 08:56:49 +09:00
|
|
|
|
|
|
|
|
|
2012-01-13 09:32:15 +10:30
|
|
|
|
|
|
|
|
|
2024-11-20 08:56:49 +09:00
|
|
|
|
2025-09-18 10:05:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-16 11:15:46 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
