From: cy_huang <u0084500@gmail.com>
To: lee@kernel.org
Cc: matthias.bgg@gmail.com, gene_chen@richtek.com,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
ChiYuan Huang <cy_huang@richtek.com>,
stable@vger.kernel.org
Subject: [PATCH v3] mfd: mt6360: add boundary check in in mt6360 regmap read/write
Date: Thu, 27 Oct 2022 11:32:09 +0800 [thread overview]
Message-ID: <1666841529-12781-1-git-send-email-u0084500@gmail.com> (raw)
From: ChiYuan Huang <cy_huang@richtek.com>
Fix the potential risk if virtual bank index is over the maximum.
Refer to the discussion list on mt6370.
https://lore.kernel.org/all/20220914013345.GA5802@cyhuang-hp-elitebook-840-g3.rt/
If not to check the boundary, there is also the same issue on mt6360.
For mt6360 register virtual mapping, the normal range is 0 to 0x3FF.
Below's the backtrace in my experiment to access mt6360 0x400 register
with regmap_raw_read() and regmap_raw_write() function.
1) regmap_raw_read()
Unable to handle kernel execute from non-executable memory at virtual
address ffffffd4940c4c20
pc : platform_bus+0x8/0x2e8
lr : i2c_smbus_xfer+0x60/0x120
Call trace:
platform_bus+0x8/0x2e8
i2c_smbus_read_i2c_block_data+0x74/0xc0
mt6360_regmap_read+0x9c/0x180 [mt6360_core]
_regmap_raw_read+0xe4/0x278
regmap_raw_read+0xec/0x240
2) regmap_raw_write()
Unable to handle kernel execute from non-executable memory at virtual
address ffffffe4a0ac4c20
pc : platform_bus+0x8/0x2e8
lr : i2c_smbus_xfer+0x60/0x120
Call trace:
platform_bus+0x8/0x2e8
i2c_smbus_write_i2c_block_data+0x84/0xd0
mt6360_regmap_write+0xa8/0x150 [mt6360_core]
_regmap_raw_write_impl+0x6e8/0x828
_regmap_raw_write+0xb4/0x130
regmap_raw_write+0x74/0xb0
After adding the boundary check, the above two cases can be solved.
Fixes: 3b0850440a06c (mfd: mt6360: Merge different sub-devices I2C read/write)
Cc: stable@vger.kernel.org
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
---
Since v3:
- Add backtrace log to help understanding what the potential risk is.
Since v2:
- Assign i2c bank variable after bank index is already checked.
---
drivers/mfd/mt6360-core.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c
index 6eaa677..d3b32eb 100644
--- a/drivers/mfd/mt6360-core.c
+++ b/drivers/mfd/mt6360-core.c
@@ -402,7 +402,7 @@ static int mt6360_regmap_read(void *context, const void *reg, size_t reg_size,
struct mt6360_ddata *ddata = context;
u8 bank = *(u8 *)reg;
u8 reg_addr = *(u8 *)(reg + 1);
- struct i2c_client *i2c = ddata->i2c[bank];
+ struct i2c_client *i2c;
bool crc_needed = false;
u8 *buf;
int buf_len = MT6360_ALLOC_READ_SIZE(val_size);
@@ -410,6 +410,11 @@ static int mt6360_regmap_read(void *context, const void *reg, size_t reg_size,
u8 crc;
int ret;
+ if (bank >= MT6360_SLAVE_MAX)
+ return -EINVAL;
+
+ i2c = ddata->i2c[bank];
+
if (bank == MT6360_SLAVE_PMIC || bank == MT6360_SLAVE_LDO) {
crc_needed = true;
ret = mt6360_xlate_pmicldo_addr(®_addr, val_size);
@@ -453,13 +458,18 @@ static int mt6360_regmap_write(void *context, const void *val, size_t val_size)
struct mt6360_ddata *ddata = context;
u8 bank = *(u8 *)val;
u8 reg_addr = *(u8 *)(val + 1);
- struct i2c_client *i2c = ddata->i2c[bank];
+ struct i2c_client *i2c;
bool crc_needed = false;
u8 *buf;
int buf_len = MT6360_ALLOC_WRITE_SIZE(val_size);
int write_size = val_size - MT6360_REGMAP_REG_BYTE_SIZE;
int ret;
+ if (bank >= MT6360_SLAVE_MAX)
+ return -EINVAL;
+
+ i2c = ddata->i2c[bank];
+
if (bank == MT6360_SLAVE_PMIC || bank == MT6360_SLAVE_LDO) {
crc_needed = true;
ret = mt6360_xlate_pmicldo_addr(®_addr, val_size - MT6360_REGMAP_REG_BYTE_SIZE);
--
2.7.4
reply other threads:[~2022-10-27 3:33 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1666841529-12781-1-git-send-email-u0084500@gmail.com \
--to=u0084500@gmail.com \
--cc=cy_huang@richtek.com \
--cc=gene_chen@richtek.com \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®