| 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
| ||
|
Message-ID: <Y+j1dbZ0A1mndwXp@smile.fi.intel.com>
Date: Sun, 12 Feb 2023 16:19:33 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Mirsad Goran Todorovac <mirsad.todorovac@....unizg.hr>
Cc: linux-gpio@...r.kernel.org,
Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <brgl@...ev.pl>,
linux-kernel@...r.kernel.org,
Thorsten Leemhuis <regressions@...mhuis.info>
Subject: Re: INFO: REPRODUCED: memory leak in gpio device in 6.2-rc6
On Wed, Feb 08, 2023 at 08:55:24PM +0100, Mirsad Goran Todorovac wrote:
> On 31. 01. 2023. 10:36, Mirsad Goran Todorovac wrote:
> > I came across this memory leak apparently in the GPIO device driver.
> > It is still present in 6.2-rc6 release candidate kernel (just ran kselftest).
> >
> > This is a vanilla Torvalds tree kernel with MGLRU and KMEMLEAK (obviously)
> > enabled.
> >
> > If you think this bug is significant, I can attempt the bug bisect in the
> > environment that triggered it (Lenovo LENOVO_MT_10TX_BU_Lenovo_FM_V530S-07ICB)
> > with BIOS M22KT49A from 11/10/2022 and AlmaLinux 8.7.
> >
> > Here is the /sys/kernel/debug/kmemleak output:
> >
> > unreferenced object 0xffff9e67ad71f160 (size 32):
> > comm "gpio-sim.sh", pid 208926, jiffies 4372229685 (age 2101.564s)
> > hex dump (first 32 bytes):
> > 67 70 69 6f 2d 73 69 6d 2e 30 2d 6e 6f 64 65 30 gpio-sim.0-node0
> > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> > backtrace:
> > [<0000000098bf3d1b>] slab_post_alloc_hook+0x91/0x320
> > [<00000000da3205c5>] __kmem_cache_alloc_node+0x1bf/0x2b0
> > [<00000000aa51a58a>] __kmalloc_node_track_caller+0x55/0x140
> > [<00000000bd682ecc>] kvasprintf+0x6b/0xd0
> > [<00000000a3431d55>] kasprintf+0x4e/0x70
> > [<00000000f52d2629>] gpio_sim_device_config_live_store+0x401/0x59d [gpio_sim]
> > [<00000000673fc6df>] configfs_write_iter+0xcc/0x130
> > [<000000001d5d0829>] vfs_write+0x2b4/0x3d0
> > [<00000000d2336251>] ksys_write+0x61/0xe0
> > [<00000000f7015bb1>] __x64_sys_write+0x1a/0x20
> > [<000000008ac743d2>] do_syscall_64+0x58/0x80
> > [<000000004d7b7d50>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > [root@...mtodorov marvin]#
>
> The new development on the bug is that it probably requires some superuser privileges
> or some capability to be exploited, for it requires access to configfs,
> but it was reproduced on different hardware as well.
>
> The minimum reproducing script is attached, with its output log.
>
> From the testing "age" of the unreferenced object I assume that it is allocated earlier
> in a part of script I am unable to locate or specify, but orphaned at the end of the script.
>
> root@...me/user/kernel_bugs/gpio-sim# time ./gpio-reproduce-min.sh
> 2.14. Lines can be hogged
> Scanning stage 2.14.7 ... done.
> Sleeping 60 seconds ... done.
> Stage 2.14.7 clean.
> Rescanning stage 2.14.7 ... done.
> Sleeping 60 seconds ... done.
> unreferenced object 0xffff9593b9d16bc0 (size 32):
> comm "gpio-reproduce-", pid 7594, jiffies 4295865460 (age 136.184s)
> hex dump (first 32 bytes):
> 67 70 69 6f 2d 73 69 6d 2e 30 2d 6e 6f 64 65 30 gpio-sim.0-node0
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<00000000fe76444b>] __kmem_cache_alloc_node+0x380/0x4e0
> [<0000000099f63f55>] __kmalloc_node_track_caller+0x55/0x140
> [<00000000c4efe87f>] kvasprintf+0x6b/0xd0
> [<000000000c0f91cd>] kasprintf+0x4e/0x70
> [<000000003434d9b5>] gpio_sim_device_config_live_store+0x401/0x59d [gpio_sim]
> [<0000000052ce6759>] configfs_write_iter+0xcc/0x130
> [<0000000006087fd2>] vfs_write+0x2b4/0x3d0
> [<000000008a17e041>] ksys_write+0x61/0xe0
> [<000000007bded8ea>] __x64_sys_write+0x1a/0x20
> [<00000000e1220148>] do_syscall_64+0x58/0x80
> [<0000000006093069>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> real 2m16.398s
> user 0m0.023s
> sys 0m16.360s
> root@...me/user/kernel_bugs/gpio-sim#
>
> The effect is cummulative:
>
> root@...vin-IdeaPad-3-15ITL6:/home/user/kernel_bugs/gpio-sim# cat /sys/kernel/debug/kmemleak
> unreferenced object 0xffff9593b9d16bc0 (size 32):
> comm "gpio-reproduce-", pid 7594, jiffies 4295865460 (age 520.296s)
> hex dump (first 32 bytes):
> 67 70 69 6f 2d 73 69 6d 2e 30 2d 6e 6f 64 65 30 gpio-sim.0-node0
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<00000000fe76444b>] __kmem_cache_alloc_node+0x380/0x4e0
> [<0000000099f63f55>] __kmalloc_node_track_caller+0x55/0x140
> [<00000000c4efe87f>] kvasprintf+0x6b/0xd0
> [<000000000c0f91cd>] kasprintf+0x4e/0x70
> [<000000003434d9b5>] gpio_sim_device_config_live_store+0x401/0x59d [gpio_sim]
> [<0000000052ce6759>] configfs_write_iter+0xcc/0x130
> [<0000000006087fd2>] vfs_write+0x2b4/0x3d0
> [<000000008a17e041>] ksys_write+0x61/0xe0
> [<000000007bded8ea>] __x64_sys_write+0x1a/0x20
> [<00000000e1220148>] do_syscall_64+0x58/0x80
> [<0000000006093069>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> unreferenced object 0xffff95938918fb40 (size 32):
> comm "gpio-reproduce-", pid 7675, jiffies 4295954327 (age 164.832s)
> hex dump (first 32 bytes):
> 67 70 69 6f 2d 73 69 6d 2e 30 2d 6e 6f 64 65 30 gpio-sim.0-node0
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<00000000fe76444b>] __kmem_cache_alloc_node+0x380/0x4e0
> [<0000000099f63f55>] __kmalloc_node_track_caller+0x55/0x140
> [<00000000c4efe87f>] kvasprintf+0x6b/0xd0
> [<000000000c0f91cd>] kasprintf+0x4e/0x70
> [<000000003434d9b5>] gpio_sim_device_config_live_store+0x401/0x59d [gpio_sim]
> [<0000000052ce6759>] configfs_write_iter+0xcc/0x130
> [<0000000006087fd2>] vfs_write+0x2b4/0x3d0
> [<000000008a17e041>] ksys_write+0x61/0xe0
> [<000000007bded8ea>] __x64_sys_write+0x1a/0x20
> [<00000000e1220148>] do_syscall_64+0x58/0x80
> [<0000000006093069>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> unreferenced object 0xffff9594a3cf1820 (size 32):
> comm "gpio-reproduce-", pid 7721, jiffies 4295976853 (age 74.728s)
> hex dump (first 32 bytes):
> 67 70 69 6f 2d 73 69 6d 2e 30 2d 6e 6f 64 65 30 gpio-sim.0-node0
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<00000000fe76444b>] __kmem_cache_alloc_node+0x380/0x4e0
> [<0000000099f63f55>] __kmalloc_node_track_caller+0x55/0x140
> [<00000000c4efe87f>] kvasprintf+0x6b/0xd0
> [<000000000c0f91cd>] kasprintf+0x4e/0x70
> [<000000003434d9b5>] gpio_sim_device_config_live_store+0x401/0x59d [gpio_sim]
> [<0000000052ce6759>] configfs_write_iter+0xcc/0x130
> [<0000000006087fd2>] vfs_write+0x2b4/0x3d0
> [<000000008a17e041>] ksys_write+0x61/0xe0
> [<000000007bded8ea>] __x64_sys_write+0x1a/0x20
> [<00000000e1220148>] do_syscall_64+0x58/0x80
> [<0000000006093069>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
> root@...vin-IdeaPad-3-15ITL6:/home/user/kernel_bugs/gpio-sim#
>
> With sufficient privileges (or possibly even without them), an exploit can be devised
> to automate allocation of orphaned objects, at a rate of a couple per second (PoC attached).
Looking into the code I found one inconsistency. It might be that that brings
an issue, dunno. Can you try the patch below if it helps (but TBH I'm a bit
sceptical)?
>From 499cfb52aa7de67a8bbb56ce183d9528b2376db0 Mon Sep 17 00:00:00 2001
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Date: Sun, 12 Feb 2023 16:15:00 +0200
Subject: [PATCH 1/1] gpio: sim: Deactivate device in reversed order
Run the steps to deactivate device in the reserved order to what
it has been done in gpio_sim_device_activate_unlocked().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
---
drivers/gpio/gpio-sim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-sim.c b/drivers/gpio/gpio-sim.c
index a51b5ea38ad5..b0111d18808c 100644
--- a/drivers/gpio/gpio-sim.c
+++ b/drivers/gpio/gpio-sim.c
@@ -953,9 +953,9 @@ static void gpio_sim_device_deactivate_unlocked(struct gpio_sim_device *dev)
swnode = dev_fwnode(&dev->pdev->dev);
platform_device_unregister(dev->pdev);
+ gpio_sim_remove_hogs(dev);
gpio_sim_remove_swnode_recursive(swnode);
dev->pdev = NULL;
- gpio_sim_remove_hogs(dev);
}
static ssize_t
--
2.39.1
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists