The pfuze_chip::regulator_descs is an array of size
PFUZE100_MAX_REGULATOR, the pfuze_chip::pfuze_regulators
is the pointer to the real regulators of a specific device.
The number of real regulator is supposed to be less than
the PFUZE100_MAX_REGULATOR, so we should use the size of
'regulator_num * sizeof(struct pfuze_regulator)' in memcpy().
This fixes the out of bounds access bug reported by KASAN.
BUG: KASAN: global-out-of-bounds in pfuze100_regulator_probe+0x380/0x8b8
Read of size 3968 at addr c3390640 by task swapper/0/1
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc1-yocto-standard+ #2
Hardware name: Freescale i.MX6 SoloX (Device Tree)
unwind_backtrace from show_stack+0x18/0x1c
show_stack from dump_stack_lvl+0x68/0x90
dump_stack_lvl from print_report+0x58/0x4c8
print_report from kasan_report+0x7c/0x98
kasan_report from kasan_check_range+0x20/0x170
kasan_check_range from memcpy+0x28/0x68
memcpy from pfuze100_regulator_probe+0x380/0x8b8
pfuze100_regulator_probe from i2c_device_probe+0x37c/0x39c
i2c_device_probe from really_probe+0x1cc/0x398
really_probe from __driver_probe_device+0x118/0x124
__driver_probe_device from driver_probe_device+0x5c/0xf0
driver_probe_device from __driver_attach+0x144/0x160
__driver_attach from bus_for_each_dev+0xf4/0x12c
bus_for_each_dev from bus_add_driver+0x124/0x264
bus_add_driver from driver_register+0x130/0x188
driver_register from i2c_register_driver+0x80/0xa8
i2c_register_driver from do_one_initcall+0x180/0x39c
do_one_initcall from kernel_init_freeable+0x374/0x3cc
kernel_init_freeable from kernel_init+0x1c/0x150
kernel_init from ret_from_fork+0x14/0x2c
Exception stack(0xf083bfb0 to 0xf083bff8)
bfa0: 00000000 00000000 00000000
bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bfe0: 00000000 00000000 00000000 00000000 00000013 00000000
The buggy address belongs to the variable:
pfuze200_regulators+0x0/0xdc0
The buggy address belongs to the physical page:
page:(ptrval) refcount:1 mapcount:0 mapping:00000000 index:0x0
pfn:0x93390
flags: 0x1000(reserved|zone=0)
raw: 00001000 ee9a5044 ee9a5044 00000000 00000000 00000000 ffffffff
raw: 00000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
c3391280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c3391300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>c3391380: 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
^
c3391400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c3391480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Signed-off-by: Xiaolei Wang <[email protected]>
---
drivers/regulator/pfuze100-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/pfuze100-regulator.c b/drivers/regulator/pfuze100-regulator.c
index 6b617024a67d..d899d6e98fb8 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -766,7 +766,7 @@ static int pfuze100_regulator_probe(struct i2c_client *client,
((pfuze_chip->chip_id == PFUZE3000) ? "3000" : "3001"))));
memcpy(pfuze_chip->regulator_descs, pfuze_chip->pfuze_regulators,
- sizeof(pfuze_chip->regulator_descs));
+ regulator_num * sizeof(struct pfuze_regulator));
ret = pfuze_parse_regulators_dt(pfuze_chip);
if (ret)
--
2.25.1
On Thu, Aug 25, 2022 at 03:15:41PM +0800, Xiaolei Wang wrote:
> This fixes the out of bounds access bug reported by KASAN.
> BUG: KASAN: global-out-of-bounds in pfuze100_regulator_probe+0x380/0x8b8
> Read of size 3968 at addr c3390640 by task swapper/0/1
>
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc1-yocto-standard+ #2
> Hardware name: Freescale i.MX6 SoloX (Device Tree)
> unwind_backtrace from show_stack+0x18/0x1c
> show_stack from dump_stack_lvl+0x68/0x90
> dump_stack_lvl from print_report+0x58/0x4c8
> print_report from kasan_report+0x7c/0x98
> kasan_report from kasan_check_range+0x20/0x170
> kasan_check_range from memcpy+0x28/0x68
Please think hard before including complete backtraces in upstream
reports, they are very large and contain almost no useful information
relative to their size so often obscure the relevant content in your
message. If part of the backtrace is usefully illustrative (it often is
for search engines if nothing else) then it's usually better to pull out
the relevant sections.