Re: [BUG]: KASAN: slab-use-after-free in nfit_handle_mce on commit 8a30aeb0d1b4e4aaf7f7bae72f20f2ae75385ccb

[Dingisoul <dingiso.kernel@gmail.com>]

Hi Kernel maintainers,

We realized that our previous report was in bad format,
so we provide a good version.

We provide more detailed analysis in the following link.
Link: https://gist.github.com/dingiso/ff78e4b30d7abe09e2e15235672e06c6

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.
   (3) 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)