summaryrefslogtreecommitdiffstats
path: root/usr/Makefile
diff options
context:
space:
mode:
authorJing Xia <jing.xia@unisoc.com>2023-12-20 10:46:03 +0800
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2024-01-04 17:13:04 +0100
commit93ec4a3b76404bce01bd5c9032bef5df6feb1d62 (patch)
treef60922c1cf2e540d4b4647f14e1c3e076b2beeb2 /usr/Makefile
parentdb2292b01b799e926abfdbd6fafa1f27f0d0e457 (diff)
downloadlinux-93ec4a3b76404bce01bd5c9032bef5df6feb1d62.tar.gz
linux-93ec4a3b76404bce01bd5c9032bef5df6feb1d62.tar.bz2
linux-93ec4a3b76404bce01bd5c9032bef5df6feb1d62.zip
class: fix use-after-free in class_register()
The lock_class_key is still registered and can be found in lock_keys_hash hlist after subsys_private is freed in error handler path.A task who iterate over the lock_keys_hash later may cause use-after-free.So fix that up and unregister the lock_class_key before kfree(cp). On our platform, a driver fails to kset_register because of creating duplicate filename '/class/xxx'.With Kasan enabled, it prints a invalid-access bug report. KASAN bug report: BUG: KASAN: invalid-access in lockdep_register_key+0x19c/0x1bc Write of size 8 at addr 15ffff808b8c0368 by task modprobe/252 Pointer tag: [15], memory tag: [fe] CPU: 7 PID: 252 Comm: modprobe Tainted: G W 6.6.0-mainline-maybe-dirty #1 Call trace: dump_backtrace+0x1b0/0x1e4 show_stack+0x2c/0x40 dump_stack_lvl+0xac/0xe0 print_report+0x18c/0x4d8 kasan_report+0xe8/0x148 __hwasan_store8_noabort+0x88/0x98 lockdep_register_key+0x19c/0x1bc class_register+0x94/0x1ec init_module+0xbc/0xf48 [rfkill] do_one_initcall+0x17c/0x72c do_init_module+0x19c/0x3f8 ... Memory state around the buggy address: ffffff808b8c0100: 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a ffffff808b8c0200: 8a 8a 8a 8a 8a 8a 8a 8a fe fe fe fe fe fe fe fe >ffffff808b8c0300: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe ^ ffffff808b8c0400: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 As CONFIG_KASAN_GENERIC is not set, Kasan reports invalid-access not use-after-free here.In this case, modprobe is manipulating the corrupted lock_keys_hash hlish where lock_class_key is already freed before. It's worth noting that this only can happen if lockdep is enabled, which is not true for normal system. Fixes: dcfbb67e48a2 ("driver core: class: use lock_class_key already present in struct subsys_private") Cc: stable <stable@kernel.org> Signed-off-by: Jing Xia <jing.xia@unisoc.com> Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com> Link: https://lore.kernel.org/r/20231220024603.186078-1-jing.xia@unisoc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'usr/Makefile')
0 files changed, 0 insertions, 0 deletions