Re: [PATCH v2 1/3] i2c: dev: fix blocked adapter deregistration

[Johan Hovold <johan@kernel.org>]

On Mon, Nov 09, 2026 at 04:08:46PM +0100, Bartosz Golaszewski wrote:
> On Thu, Aug 27, 2026 at 12:20:41PM +0200, Johan Hovold wrote:
> > The I2C subsystem allows controllers to be used by non-child devices
> > that may remain registered after an adapter goes away.
> > 
> > To handle this, adapter deregistration blocks until the last reference
> > to the adapter is released. Albeit unorthodox, this is mostly fine for
> > the vast majority of controllers but can cause some trouble when
> > controllers reside on hotpluggable buses.
> > 
> > Specifically, userspace can prevent an adapter from being deregistered
> > indefinitely by holding an i2c-dev character device file open. And with
> > USB attached controllers this prevents further hub events from being
> > processed by the parent hub until the file is closed.
> > 
> > Fix the i2c-dev implementation by dropping the additional reference
> > taken at open() and using an rwsem to make sure the adapter is only
> > accessed while registered.
> > 
> > Note that before commit 611e12ea0f12 ("i2c: core: manage i2c bus device
> > refcount in i2c_[get|put]_adapter") an adapter going away would instead
> > have resulted in a use-after-free.
> > 
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---

> >  static ssize_t i2cdev_read(struct file *file, char __user *buf, size_t count,
> >  		loff_t *offset)
> >  {
> > +	struct i2c_dev_data *data = file->private_data;
> > +	struct i2c_client *client = &data->client;
> > +	struct i2c_dev *i2c_dev = data->i2c_dev;
> >  	char *tmp;
> >  	int ret;
> >  
> > -	struct i2c_client *client = file->private_data;
> > +	guard(rwsem_read)(&i2c_dev->rwsem);
> 
> I think sashiko is correct in its comment and you should limit the
> critical section to until right after i2c_master_recv(). Same elsewhere.

I don't think that's anything we need to care about. If a malicious
actor has physical access to the machine, we have bigger problems than
worrying about them going out of their way to cause a USB hub worker
thread to hang. :)

Johan

> [1] https://sashiko.dev/#/patchset/20260827102043.673273-1-johan%40kernel.org?part=1