linux-kernel - Re: [PATCH 0/7] nvmem: survive unbind with active consumers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aW4T52TSgMf1bWJu@hovoldconsulting.com>
Date: Mon, 19 Jan 2026 12:22:15 +0100
From: Johan Hovold <johan@...nel.org>
To: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>
Cc: Srinivas Kandagatla <srini@...nel.org>,
	Bartosz Golaszewski <brgl@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] nvmem: survive unbind with active consumers

On Fri, Jan 16, 2026 at 12:01:07PM +0100, Bartosz Golaszewski wrote:
> Nvmem is one of the subsystems vulnerable to object life-time issues.
> The memory nvmem core dereferences is owned by nvmem providers which can
> be unbound at any time and even though nvmem devices themselves are
> reference-counted, there's no synchronization with the provider modules.
> 
> This typically is not a problem because thanks to fw_devlink, consumers
> get synchronously unbound before providers but it's enough to pass
> fw_devlink=off over the command line, unbind the nvmem controller with
> consumers still holding references to it and try to read/write in order
> to see fireworks in the kernel log.

Well, don't do that then. Only root can unbind drivers, and we have
things like module references to prevent drivers from being unloaded
while in use.

> User-space can trigger it too if a device (for instance: i2c eeprom on a
> cp2112 USB expander) is unplugged halfway through a long read.

Hotplugging may be a real issue, though. But this can solved at the user
interface level. Did you explore that?

For reference, this is related to the i2c discussion here:

	https://lore.kernel.org/lkml/aW4OWnyYp6Vas53L@hovoldconsulting.com/

Johan