From: Vasileios Almpanis <vasilisalmpanis@gmail.com>
To: Andi Shyti <andi.shyti@kernel.org>
Cc: wsa+renesas@sang-engineering.com, johan@kernel.org,
hdanton@sina.com, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org,
syzbot+23ad911c819b923238b7@syzkaller.appspotmail.com
Subject: Re: [PATCH] i2c: core: fix debugfs UAF on adapter removal
Date: Sat, 1 Aug 2026 18:21:09 +0200 [thread overview]
Message-ID: <7b71a776-2f8c-48e8-919b-f97a205ca1cb@gmail.com> (raw)
In-Reply-To: <am0Mk1KapCw0SD1s@zenone.zhora.eu>
On 7/31/26 11:35 PM, Andi Shyti wrote:
Hi Andi,
> Hi Vasileios,
>
> ...
>
>> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
>> index 3ec04787a737..b894563f5a75 100644
>> --- a/drivers/i2c/i2c-core-base.c
>> +++ b/drivers/i2c/i2c-core-base.c
>> @@ -1826,8 +1826,6 @@ void i2c_del_adapter(struct i2c_adapter *adap)
>>
>> i2c_host_notify_irq_teardown(adap);
>>
>> - debugfs_remove_recursive(adap->debugfs);
>> -
>> /* wait until all references to the device are gone
>> *
>> * FIXME: This is old code and should ideally be replaced by an
>> @@ -1839,6 +1837,9 @@ void i2c_del_adapter(struct i2c_adapter *adap)
>> device_unregister(&adap->dev);
>> wait_for_completion(&adap->dev_released);
>>
>> + /* clients use this directory as their debugfs parent */
>> + debugfs_remove_recursive(adap->debugfs);
>> +
> Speaking of sysfs, this can't work if a new device is created
> through the new_device interface. Perhaps you can remove the
> attribute first with device_remove_file(), but we need to check
> whether that could lead to a double removal when the device
> attributes are cleaned up during device removal.
>
> Thanks,
> Andi
Thanks you for reviewing my patch. You're right. A write to new_device
that happens during removing clients leaks a client. It holds a reference
on the adapter device, so wait_for_completion() never returns.
I reproduced this locally by adding mdelay(5000) right after
unregistering clients
and creating a client. The write succeeds and i2c_del_adapter() hangs.
I already wrote another patch that includes my hunk from v1 but also adds
device_remove_file(&adap->dev, &dev_attr_new_device) before deregistering
clients as you suggested. This no longer reproduces the same bug.
I also tested it with CONFIG_DEBUG_KOBJECT_RELEASE and KASAN as
i2c_del_adapter suggests and no warnings were emitted.
syzbot also tested the result against mainline and the reproducer
doesn't trigger anymore.
Is it okay with you if I keep the hunk of v1? Or you prefer its left as
originally,
since after removing the new_device attr, we can't have new clients so
leaving there is safe.
Thanks,
Vasilis
>
>> /* free bus id */
>> mutex_lock(&core_lock);
>> idr_remove(&i2c_adapter_idr, adap->nr);
>> --
>> 2.47.3
>>
prev parent reply other threads:[~2026-08-01 16:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 16:23 [PATCH] i2c: core: fix debugfs UAF on adapter removal Vasileios Almpanis
2026-07-31 21:35 ` Andi Shyti
2026-08-01 16:21 ` Vasileios Almpanis [this message]
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=7b71a776-2f8c-48e8-919b-f97a205ca1cb@gmail.com \
--to=vasilisalmpanis@gmail.com \
--cc=andi.shyti@kernel.org \
--cc=hdanton@sina.com \
--cc=johan@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+23ad911c819b923238b7@syzkaller.appspotmail.com \
--cc=wsa+renesas@sang-engineering.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox