mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Shuangpeng <shuangpeng.kernel@gmail.com>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: Niklas Cassel <cassel@kernel.org>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] ata: pata_parport: KASAN slab-use-after-free in driver_find
Date: Tue, 28 Jul 2026 00:34:23 -0400	[thread overview]
Message-ID: <69B390E9-F5AA-4B22-AF50-070612603F51@gmail.com> (raw)
In-Reply-To: <b6018f00-020a-46eb-b74f-2b0f42019fff@kernel.org>



> On Jul 27, 2026, at 23:01, Damien Le Moal <dlemoal@kernel.org> wrote:
> 
> On 7/28/26 11:40, Shuangpeng Bai wrote:
>> Hi Kernel Maintainers,
>> 
>> I hit the following report while testing current upstream kernel:
>> 
>> KASAN: slab-use-after-free in driver_find
>> 
>> on commit: 62efbc768363bc7bb00f0915ad265f34b40d414e (2026-07-27)
>> 
>> To help trigger the bug more reliably, we applied a minimal diagnostic patch
>> that only adds a delay.
> 
> Can you share that patch/diff? That would make it easier to figure out where the
> race is because you are not describing anything here. The stack trace helps, but
> without being able to reproduce (I do not have the hardware), this will be hard
> to fix.
> 
>> The reproducer and .config files are here.
>> https://gist.github.com/shuangpengbai/a8a1b5339bc41944c2f80d9f87e01a7e
> 
> This site has a broken certificate and Firefox does not want (rightly so) to get
> me there. So not touching this.
> 


Hi Damien,

Here are the reproducer details.

The diagnostic patch I used only widens the race window:

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index d17bd91490ee..eb9dfbdd2aec 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -16,6 +16,7 @@
 #include <linux/errno.h>
 #include <linux/slab.h>
 #include <linux/init.h>
+#include <linux/delay.h>
 #include <linux/string.h>
 #include <linux/mutex.h>
 #include <linux/sysfs.h>
@@ -1421,6 +1422,8 @@ struct device_driver *driver_find(const char *name, const struct bus_type *bus)
 		return NULL;

 	priv = to_driver(k);
+	if (!strcmp(name, "aten"))
+		msleep(200);

 	/* Drop reference added by kset_find_obj() */
 	kobject_put(k);

I reproduced this in QEMU, without parallel IDE hardware, using:

  CONFIG_PARPORT_PC=y
  CONFIG_PATA_PARPORT=y
  CONFIG_PATA_PARPORT_ATEN=m
  CONFIG_KASAN=y
  CONFIG_DEBUG_KOBJECT_RELEASE=n

Then boot the kernel, make the in-tree ATEN protocol module available in the
guest, and run:

  rmmod aten 2>/dev/null || true
  insmod ./aten.ko

  (
      echo "auto aten 0 0 0" > /sys/bus/pata_parport/new_device
  ) &

  sleep 0.03
  rmmod aten

With the delay above, this reliably triggers:

  KASAN: slab-use-after-free in driver_find

The relevant contract is the comment above driver_find(): it does not prevent
the returned driver from being unregistered or unloaded while the caller uses
it, and the caller is responsible for preventing that. In this case,
new_device_store() calls driver_find() before taking pi_mutex, while
pata_parport_unregister_driver() can remove the protocol and then unregister
the driver concurrently.

Thanks,
Shuangpeng

>> 
>> I'm happy to test debug patches or provide additional information.
>> 
>> Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
>> 
>> [  755.753286][ T8297] BUG: KASAN: slab-use-after-free in driver_find (drivers/base/bus.c:1430)
>> [  755.754175][ T8297] Read of size 8 at addr ffff88812200f490 by task repro.sh/8297
>> [  755.755320][ T8297] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
>> [  755.755331][ T8297] Call Trace:
>> [  755.755341][ T8297]  <TASK>
>> [  755.755344][ T8297]  dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
>> [  755.755393][ T8297]  print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
>> [  755.755478][ T8297]  kasan_report (mm/kasan/report.c:595)
>> [  755.755487][ T8297]  driver_find (drivers/base/bus.c:1430)
>> [  755.755502][ T8297]  new_device_store (drivers/ata/pata_parport/pata_parport.c:649)
>> [  755.755610][ T8297]  kernfs_fop_write_iter (fs/kernfs/file.c:345)
>> [  755.755615][ T8297]  vfs_write (fs/read_write.c:595 fs/read_write.c:687)
>> [  755.755678][ T8297]  ksys_write (fs/read_write.c:739)
>> [  755.755703][ T8297]  do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
>> [  755.755717][ T8297]  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
>> [  755.779923][ T8297] Freed by task 8297 on cpu 0 at 755.752571s:
>> [  755.780598][ T8297]  kasan_save_track (mm/kasan/common.c:57 mm/kasan/common.c:78)
>> [  755.781128][ T8297]  kasan_save_free_info (mm/kasan/generic.c:584)
>> [  755.781700][ T8297]  __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)
>> [  755.782222][ T8297]  kfree (./include/linux/kasan.h:235 mm/slub.c:2705 mm/slub.c:6405 mm/slub.c:6720)
>> [  755.782658][ T8297]  kobject_put (lib/kobject.c:689 lib/kobject.c:720 ./include/linux/kref.h:65 lib/kobject.c:737)
>> [  755.783163][ T8297]  driver_find (drivers/base/bus.c:1429)
>> [  755.783659][ T8297]  new_device_store (drivers/ata/pata_parport/pata_parport.c:649)
>> [  755.787092][ T8297] The buggy address belongs to the object at ffff88812200f400
>> [  755.787092][ T8297]  which belongs to the cache kmalloc-192 of size 192
>> [  755.788598][ T8297] The buggy address is located 144 bytes inside of
>> [  755.788598][ T8297]  freed 192-byte region [ffff88812200f400, ffff88812200f4c0)
>> 
>> Best,
>> Shuangpeng
> 
> 
> -- 
> Damien Le Moal
> Western Digital Research



  reply	other threads:[~2026-07-28  4:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28  2:40 Shuangpeng Bai
2026-07-28  3:01 ` Damien Le Moal
2026-07-28  4:34   ` Shuangpeng [this message]
2026-07-29 11:13     ` [PATCH] test: ata Pei Xiao

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=69B390E9-F5AA-4B22-AF50-070612603F51@gmail.com \
    --to=shuangpeng.kernel@gmail.com \
    --cc=cassel@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®