linux-kernel - [PATCH] mfd: syscon: Set max_register_is_0 when syscon points to a single register

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240828121008.3066002-1-nm@ti.com>
Date: Wed, 28 Aug 2024 07:10:08 -0500
From: Nishanth Menon <nm@...com>
To: Arnd Bergmann <arnd@...db.de>, Lee Jones <lee@...nel.org>
CC: <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <afd@...com>, <bb@...com>, <d-gole@...com>, Nishanth Menon <nm@...com>,
        Jan
 Dakinevich <jan.dakinevich@...utedevices.com>,
        Mark Brown
	<broonie@...nel.org>
Subject: [PATCH] mfd: syscon: Set max_register_is_0 when syscon points to a single register

Commit 0ec74ad3c157 ("regmap: rework ->max_register handling")
introduced explicit handling in regmap framework for register maps
that is exactly 1 register wide. As a result, a syscon pointing
to a single register would cause regmap checks to skip checks
(or in the case of regmap_get_max_register, return -EINVAL) as
max_register_is_set will not be true.

Fixes: 0ec74ad3c157 ("regmap: rework ->max_register handling")
Signed-off-by: Nishanth Menon <nm@...com>
---
Cc: Jan Dakinevich <jan.dakinevich@...utedevices.com>
Cc: Mark Brown <broonie@...nel.org>

WARNING:
This is probably going to expose some other hidden bugs in other code
bases, for example: https://lore.kernel.org/r/20240827131342.6wrielete3yeoinl@bryanbrattlof.com
exposed a very interesting behavior - regmap_read now correctly fails
with -EIO in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/cpufreq/ti-cpufreq.c#n343
when the dt is modified to provide exact syscon register, but cpufreq
driver attempts to read at 0x18 reg offset, but then, the code assumes
that invalid regmap ranges imply OMAP3 and goes and reads some random
register.. (fixes for cpufreq is pending).

in the above example: adding prints in cpufreq driver (in the same
location pointed above):
before this patch:
read returns 0 with value 0x00000243 and regmap_get_max_register would
return -EINVAL

After this patch:
read returns -EIO with value 0x00000000 and regmap_get_max_register would
return 0x0

This would be the correct behavior.

 drivers/mfd/syscon.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index 2ce15f60eb10..3e1d699ba934 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -108,6 +108,8 @@ static struct syscon *of_syscon_register(struct device_node *np, bool check_res)
 	syscon_config.reg_stride = reg_io_width;
 	syscon_config.val_bits = reg_io_width * 8;
 	syscon_config.max_register = resource_size(&res) - reg_io_width;
+	if (!syscon_config.max_register)
+		syscon_config.max_register_is_0 = true;

 	regmap = regmap_init_mmio(NULL, base, &syscon_config);
 	kfree(syscon_config.name);
@@ -357,6 +359,9 @@ static int syscon_probe(struct platform_device *pdev)
 		return -ENOMEM;

 	syscon_config.max_register = resource_size(res) - 4;
+	if (!syscon_config.max_register)
+		syscon_config.max_register_is_0 = true;
+
 	if (pdata)
 		syscon_config.name = pdata->label;
 	syscon->regmap = devm_regmap_init_mmio(dev, base, &syscon_config);

-- 
2.43.0