From: Dingisoul <dingiso.kernel@gmail.com>
To: nvdimm@lists.linux.dev
Cc: dan.j.williams@intel.com, vishal.l.verma@intel.com,
dave.jiang@intel.com, ira.weiny@intel.com,
shuangpeng.kernel@gmail.com
Subject: [BUG]: KASAN: slab-use-after-free in nfit_handle_mce on commit 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb
Date: Thu, 19 Mar 2026 13:39:01 -0400 [thread overview]
Message-ID: <44ac97fc-94b0-4de9-9a4c-ced9df89eeb5@gmail.com> (raw)
Hi Kernel maintainers,
Our tool found a new kernel bug KASAN: slab-use-after-free in
nfit_handle_mce on commit 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb
(Mar 18 2026).
We observe such an error-triggering path.
1.__nvdimm_create fails (e.g., -ENOMEM on nvdimm allocation).
2.A dangling pointer remains in the acpi_descs list
after the error code is passed through the call chain:
(1) __nvdimm_create
(2) acpi_nfit_register_dimms
(3) acpi_nfit_init
Add acpi_desc into acpi_descs list
(4) acpi_nfit_probe
Callback function acpi_nfit_shutdown is not set
(5) call_driver_probe
(6) really_probe
Free acpi_desc but not remove it from list due to
the missing callback function acpi_nfit_shutdown
3.A UAF occurs on acpi_desc in nfit_handle_mce:
When iterate the acpi_descs list, the freed acpi_desc has
been accessed, causing use-after-free in our test. The
operation can be invoked by injecting a machine check error.
Reproduction Steps:
1.Environment:
(1) Build Kernel with:
CONFIG_X86_MCE_INJECT=y
CONFIG_MEMORY_FAILURE=y
CONFIG_ACPI_APEI_MEMORY_FAILURE=y
(2) Inject allocation failure:
Set nvdimm=NULL in __nvdimm_create to
simulate -ENOMEM.
(2) Boot Kernel with the following QEMU options:
-machine pc,nvdimm=on \
-smp 1 \
-object memory-backend-ram,id=mem1,size=1G \
-device nvdimm,id=nvdimm1,memdev=mem1 \
-monitor telnet:127.0.0.1:10710,server,nowait \
2.Trigger use-after-free:
(1) Get nvdimm memory range: dmesg | grep non-volatile
(Output: ACPI: SRAT: Node 0 PXM 0
[mem 0x2c0000000-0x2ffffffff] non-volatile)
(2) Inject machine check error via QEMU monitor to this range:
mce 0 8 0xbd00000000000090 0x5 0x2c0000000 0x80
After these steps, the bug can be stably triggered in QEMU,
generating the following KASAN report:
[T9] ==================================================================
[T9] BUG: KASAN: slab-use-after-free in nfit_handle_mce
(drivers/acpi/nfit/mce.c:36 (discriminator 512))
[T9] Read of size 8 at addr ffff88810aa99140 by task kworker/0:0/9
[T9]
[T9] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Tainted: G M
7.0.0-rc4-00091-g8a30aeb0d1b4-dirty #56 PREEMPT(full)
[T9] Tainted: [M]=MACHINE_CHECK
[T9] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.3-debian-1.16.3-2 04/01/2014
[T9] Workqueue: events mce_gen_pool_process
[T9] Call Trace:
[T9] <TASK>
[T9] dump_stack_lvl (lib/dump_stack.c:122)
[T9] print_report (mm/kasan/report.c:379 (discriminator 3)
mm/kasan/report.c:482 (discriminator 3))
[T9] kasan_report (mm/kasan/report.c:597)
[T9] nfit_handle_mce (drivers/acpi/nfit/mce.c:36 (discriminator 512))
[T9] notifier_call_chain (kernel/notifier.c:85 (discriminator 512))
[T9] blocking_notifier_call_chain (kernel/notifier.c:380)
[T9] mce_gen_pool_process (arch/x86/kernel/cpu/mce/genpool.c:88)
[T9] process_scheduled_works (kernel/workqueue.c:? kernel/workqueue.c:3359)
[T9] worker_thread (kernel/workqueue.c:?)
[T9] kthread (kernel/kthread.c:438)
[T9] ret_from_fork (arch/x86/kernel/process.c:164)
[T9] ret_from_fork_asm (arch/x86/entry/entry_64.S:255)
[T9] </TASK>
[T9]
[T9] Freed by task 8283:
[T9] kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78)
[T9] kasan_save_free_info (mm/kasan/generic.c:587)
[T9] __kasan_slab_free (mm/kasan/common.c:287)
[T9] kfree (mm/slub.c:6165 (discriminator 256) mm/slub.c:6483
(discriminator 256))
[T9] tomoyo_supervisor (security/tomoyo/common.c:?)
[T9] tomoyo_env_perm (security/tomoyo/environ.c:65 (discriminator 1))
[T9] tomoyo_find_next_domain (security/tomoyo/domain.c:673
security/tomoyo/domain.c:889)
[T9] tomoyo_bprm_check_security (security/tomoyo/tomoyo.c:102)
[T9] security_bprm_check (security/security.c:?)
[T9] bprm_execve (fs/exec.c:1654 fs/exec.c:1696 fs/exec.c:1748)
[T9] do_execveat_common (fs/exec.c:?)
[T9] __x64_sys_execve (fs/exec.c:1930 fs/exec.c:1924 fs/exec.c:1924)
[T9] do_syscall_64 (arch/x86/entry/syscall_64.c:?)
[T9] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
[T9]
[T9] The buggy address belongs to the object at ffff88810aa99000
[T9] which belongs to the cache kmalloc-1k of size 1024
[T9] The buggy address is located 320 bytes inside of
[T9] freed 1024-byte region [ffff88810aa99000, ffff88810aa99400)
We provide more detailed analysis in the following link.
Link: https://gist.github.com/dingiso/ff78e4b30d7abe09e2e15235672e06c6
next reply other threads:[~2026-03-19 17:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 17:39 Dingisoul [this message]
2026-03-27 3:24 ` [BUG]: KASAN: slab-use-after-free in nfit_handle_mce on commit 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb Dingisoul
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=44ac97fc-94b0-4de9-9a4c-ced9df89eeb5@gmail.com \
--to=dingiso.kernel@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=ira.weiny@intel.com \
--cc=nvdimm@lists.linux.dev \
--cc=shuangpeng.kernel@gmail.com \
--cc=vishal.l.verma@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.