* [syzbot] [i2c?] WARNING: refcount bug in i2c_get_adapter (2)
@ 2026-04-22 20:31 syzbot
2026-04-25 21:45 ` Arjan van de Ven
0 siblings, 1 reply; 2+ messages in thread
From: syzbot @ 2026-04-22 20:31 UTC (permalink / raw)
To: linux-i2c, linux-kernel, syzkaller-bugs, wsa+renesas
Hello,
syzbot found the following issue on:
HEAD commit: e753c16cb3dd Merge tag 'spi-fix-v7.0-rc7' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=127f9106580000
kernel config: https://syzkaller.appspot.com/x/.config?x=45cb3c58fd963c27
dashboard link: https://syzkaller.appspot.com/bug?extid=c0291c8c9aaa473c7721
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/5ae80002fa8a/disk-e753c16c.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/6ef912fb95e2/vmlinux-e753c16c.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b5b121be2ebf/bzImage-e753c16c.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c0291c8c9aaa473c7721@syzkaller.appspotmail.com
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25, CPU#0: syz.1.506/7352
Modules linked in:
CPU: 0 UID: 0 PID: 7352 Comm: syz.1.506 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
RIP: 0010:refcount_warn_saturate+0x9f/0x110 lib/refcount.c:25
Code: eb 66 85 db 74 3e 83 fb 01 75 4c e8 bb d6 25 fd 48 8d 3d 84 01 d6 0a 67 48 0f b9 3a eb 4a e8 a8 d6 25 fd 48 8d 3d 81 01 d6 0a <67> 48 0f b9 3a eb 37 e8 95 d6 25 fd 48 8d 3d 7e 01 d6 0a 67 48 0f
RSP: 0018:ffffc9001ca9f6d8 EFLAGS: 00010283
RAX: ffffffff849eaa68 RBX: 0000000000000002 RCX: 0000000000080000
RDX: ffffc90006421000 RSI: 00000000000006c7 RDI: ffffffff8f74abf0
RBP: 0000000000000000 R08: ffff888020331e80 R09: 0000000000000005
R10: 0000000000000100 R11: 0000000000000004 R12: ffffffff8c04a688
R13: dffffc0000000000 R14: ffff88803b531188 R15: dffffc0000000000
FS: 00007f9769ca66c0(0000) GS:ffff888126332000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6df4ab1d80 CR3: 00000000348d0000 CR4: 00000000003526f0
Call Trace:
<TASK>
__refcount_add include/linux/refcount.h:-1 [inline]
__refcount_inc include/linux/refcount.h:366 [inline]
refcount_inc include/linux/refcount.h:383 [inline]
kref_get include/linux/kref.h:45 [inline]
kobject_get+0xfa/0x120 lib/kobject.c:643
i2c_get_adapter+0x6d/0xa0 drivers/i2c/i2c-core-base.c:2612
i2cdev_open+0x48/0x190 drivers/i2c/i2c-dev.c:603
chrdev_open+0x4d0/0x5f0 fs/char_dev.c:411
do_dentry_open+0x83d/0x13e0 fs/open.c:949
vfs_open+0x3b/0x350 fs/open.c:1081
do_open fs/namei.c:4677 [inline]
path_openat+0x2e43/0x38a0 fs/namei.c:4836
do_file_open+0x23e/0x4a0 fs/namei.c:4865
do_sys_openat2+0x113/0x200 fs/open.c:1366
do_sys_open fs/open.c:1372 [inline]
__do_sys_openat fs/open.c:1388 [inline]
__se_sys_openat fs/open.c:1383 [inline]
__x64_sys_openat+0x138/0x170 fs/open.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f976ba0d04e
Code: 08 0f 85 a5 a8 ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 80 00 00 00 00 48 83 ec 08
RSP: 002b:00007f9769ca5b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 00007f9769ca66c0 RCX: 00007f976ba0d04e
RDX: 0000000000000402 RSI: 00007f9769ca5c00 RDI: ffffffffffffff9c
RBP: 00007f9769ca5c00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: cccccccccccccccd
R13: 00007f976bcc6038 R14: 00007f976bcc5fa0 R15: 00007fffc400e638
</TASK>
----------------
Code disassembly (best guess):
0: eb 66 jmp 0x68
2: 85 db test %ebx,%ebx
4: 74 3e je 0x44
6: 83 fb 01 cmp $0x1,%ebx
9: 75 4c jne 0x57
b: e8 bb d6 25 fd call 0xfd25d6cb
10: 48 8d 3d 84 01 d6 0a lea 0xad60184(%rip),%rdi # 0xad6019b
17: 67 48 0f b9 3a ud1 (%edx),%rdi
1c: eb 4a jmp 0x68
1e: e8 a8 d6 25 fd call 0xfd25d6cb
23: 48 8d 3d 81 01 d6 0a lea 0xad60181(%rip),%rdi # 0xad601ab
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: eb 37 jmp 0x68
31: e8 95 d6 25 fd call 0xfd25d6cb
36: 48 8d 3d 7e 01 d6 0a lea 0xad6017e(%rip),%rdi # 0xad601bb
3d: 67 addr32
3e: 48 rex.W
3f: 0f .byte 0xf
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [syzbot] [i2c?] WARNING: refcount bug in i2c_get_adapter (2)
2026-04-22 20:31 [syzbot] [i2c?] WARNING: refcount bug in i2c_get_adapter (2) syzbot
@ 2026-04-25 21:45 ` Arjan van de Ven
0 siblings, 0 replies; 2+ messages in thread
From: Arjan van de Ven @ 2026-04-25 21:45 UTC (permalink / raw)
To: linux-i2c
Cc: linux-kernel, syzkaller-bugs, wsa+renesas,
syzbot+c0291c8c9aaa473c7721
This email is created by automation to help kernel developers
deal with a large volume of AI generated bug reports by decoding
oopses into more actionable information.
Decoded Backtrace
0. refcount_warn_saturate -- lib/refcount.c:25 (crash site)
11 #define REFCOUNT_WARN(str) WARN_ONCE(1, "refcount_t: " str ".\n")
12
13 void refcount_warn_saturate(refcount_t *r,
13 enum refcount_saturation_type t)
14 {
15 refcount_set(r, REFCOUNT_SATURATED);
16
17 switch (t) {
18 case REFCOUNT_ADD_NOT_ZERO_OVF:
19 case REFCOUNT_ADD_OVF:
20 REFCOUNT_WARN("saturated; leaking memory");
21 break;
22 case REFCOUNT_ADD_UAF:
23 case REFCOUNT_SUB_UAF:
-> 25 REFCOUNT_WARN("addition on 0; use-after-free");
25 break;
26 case REFCOUNT_DEC_LEAK:
27 REFCOUNT_WARN("decrement hit 0; leaking memory");
28 break;
29 default:
30 REFCOUNT_WARN("unknown saturation event!?");
31 }
32 }
RBX = 0x2 = REFCOUNT_ADD_UAF, confirming the switch branch taken.
5. kobject_get -- lib/kobject.c:643
636 struct kobject *kobject_get(struct kobject *kobj)
637 {
638 if (kobj) {
639 if (!kobj->state_initialized)
640 WARN(1, KERN_WARNING
641 "kobject: '%s' (%p): is not initialized, "
641 "yet kobject_get() is being called.\n",
642 kobject_name(kobj), kobj);
-> 643 kref_get(&kobj->kref); /* unconditional increment */
644 }
645 return kobj;
646 }
kobject_get_unless_zero() (line 649) checks for zero first via
kref_get_unless_zero, but is not used here.
6. i2c_get_adapter -- drivers/i2c/i2c-core-base.c:2612
2602 struct i2c_adapter *i2c_get_adapter(int nr)
2603 {
2604 struct i2c_adapter *adapter;
2605
2606 mutex_lock(&core_lock);
2607 adapter = idr_find(&i2c_adapter_idr, nr);
2608 if (!adapter)
2609 goto exit;
2610
2611 if (try_module_get(adapter->owner))
->2612 get_device(&adapter->dev); /* crash: dev refcount == 0 */
2613 else
2614 adapter = NULL;
2615
2616 exit:
2617 mutex_unlock(&core_lock);
2618 return adapter;
2619 }
7. i2cdev_open -- drivers/i2c/i2c-dev.c:603
597 static int i2cdev_open(struct inode *inode, struct file *file)
598 {
599 unsigned int minor = iminor(inode);
600 struct i2c_client *client;
601 struct i2c_adapter *adap;
602
-> 603 adap = i2c_get_adapter(minor);
604 if (!adap)
605 return -ENODEV;
...
618 }
Tentative Analysis
The crash is a "refcount_t: addition on 0; use-after-free" WARNING in
refcount_warn_saturate(), triggered when get_device() is called on an
I2C adapter whose struct device refcount has already reached zero.
The sequence of events:
1. A task opens /dev/i2c-N, which calls i2cdev_open(), which calls
i2c_get_adapter(minor).
2. i2c_get_adapter() takes core_lock, calls idr_find(), and finds the
adapter in the IDR (non-NULL). try_module_get() succeeds.
get_device(&adapter->dev) is then called.
3. Concurrently, i2c_del_adapter() has already called
device_unregister(&adap->dev), which drops the device refcount to
zero. At this point the adapter is still in the IDR: idr_remove()
is not called until after wait_for_completion() returns.
4. There is therefore a window where i2c_get_adapter() can find the
adapter in the IDR and attempt get_device() on an object whose
kobject refcount is already 0, triggering the WARNING.
The race exists because i2c_del_adapter() removes the adapter from
the IDR only *after* wait_for_completion(), which itself is called
after device_unregister() (which drops the device refcount to zero
when there is only one reference). i2c_get_adapter() holds core_lock
for its entire body including the get_device() call, but
i2c_del_adapter() releases core_lock before calling
device_unregister(), so the two can execute concurrently.
The bug was introduced by commit 611e12ea0f12 ("i2c: core: manage i2c
bus device refcount in i2c_[get|put]_adapter", 2015), which added
get_device() to i2c_get_adapter() without reordering the idr_remove()
call in i2c_del_adapter(). Before that commit only try_module_get()
was called, so the idr_remove() ordering was inconsequential.
Potential Solution
Move the idr_remove() call in i2c_del_adapter() to before the
device_unregister() call, still under core_lock. Once the adapter is
removed from the IDR, any concurrent i2c_get_adapter() call will
receive NULL from idr_find() and return -ENODEV. Callers that already
obtained a device reference before the idr_remove() hold a legitimate
reference; wait_for_completion() will correctly wait for them to
release it via i2c_put_adapter().
Rough patch (against e753c16cb3dd):
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ i2c_del_adapter
+ /* Remove from IDR before device_unregister() to prevent a
+ * concurrent i2c_get_adapter() from calling get_device() on a
+ * kobject whose refcount has already reached zero.
+ */
+ mutex_lock(&core_lock);
+ idr_remove(&i2c_adapter_idr, adap->nr);
+ mutex_unlock(&core_lock);
+
/* wait until all references to the device are gone ... */
init_completion(&adap->dev_released);
device_unregister(&adap->dev);
wait_for_completion(&adap->dev_released);
- /* free bus id */
- mutex_lock(&core_lock);
- idr_remove(&i2c_adapter_idr, adap->nr);
- mutex_unlock(&core_lock);
-
More information
Oops-Analysis: http://oops.fenrus.org/reports/lkml/69e93024.a00a0220.17a17.0031.GAE_google.com/
Assisted-by: GitHub Copilot linux-kernel-oops-x86.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-04-25 21:44 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-22 20:31 [syzbot] [i2c?] WARNING: refcount bug in i2c_get_adapter (2) syzbot
2026-04-25 21:45 ` Arjan van de Ven
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox