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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAMRc=Mf4P6g7fSU3YNFiZ1-TLTey4CeRJVsLjJ9JyJ8byDHTYg@mail.gmail.com>
Date: Mon, 19 Jan 2026 13:43:01 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Johan Hovold <johan@...nel.org>
Cc: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, 
	Srinivas Kandagatla <srini@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] nvmem: survive unbind with active consumers

On Mon, Jan 19, 2026 at 12:22 PM Johan Hovold <johan@...nel.org> wrote:
>
> 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.
>

That's a very weird argument. It roughly translates to: "There's an
issue that can crash the system but only root can trigger it so let's
never fix it". If that's how we work then why don't we allow root to
kill init with a signal?

Is this a corner-case? Sure. Should we not address corner cases? Then
why do we fix error paths we never hit or that result in an unusable
system anyway?

Also: sysfs attributes don't take a module reference. Unloading an
nvmem module during a long read from user-space is equivalent to a USB
unplug.

> > 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?
>

Did I explore what exactly? If you're saying this *can* be solved,
then please also say how. Nvmem has no idea what abstraction layer it
sits above. Nvmem core doesn't even know what abstraction layer the
nvmem providers use.

> For reference, this is related to the i2c discussion here:
>
>         https://lore.kernel.org/lkml/aW4OWnyYp6Vas53L@hovoldconsulting.com/
>

Your argument against the i2c changes is that they affect lots of
drivers and decrease readability. I can see it as a point worth
considering. In the end it's up to Wolfram to decide and I think he
was pretty clear he wants it to proceed.

This series addresses the unbinding issue entirely within nvmem core,
no driver changes are required. It uses SRCU which is very fast in
read sections. What exactly is your argument against it? What is the
reason for your comment? Unless you deal with nvmem internals, you
never have to concern yourself with it.

Bartosz