[BUG] nvmem: use-after-free of nvmem->layout in nvmem_layout_module_put() on provider teardown

[Yu Zhang <yuz08559@gmail.com>]

Hi,

On nvmem provider teardown while a consumer still holds a cell handle,
nvmem_cell_put() dereferences a freed nvmem->layout - a use-after-free.
This looks like a regression from 87341c4dd5de ("nvmem: remove
duplicated reference counting").

Mechanism (drivers/nvmem/core.c + layouts.c, torvalds/master):

nvmem_unregister() frees the layout sub-device immediately:

    nvmem_unregister()                              core.c:1075
      ...
      nvmem_destroy_layout(nvmem);                  core.c:1088
        device_unregister(&nvmem->layout->dev);     layouts.c:205
      device_unregister(&nvmem->dev);               core.c:1091

nvmem_destroy_layout() does not clear nvmem->layout. The layout device's
only reference is its own and its parent is nvmem->dev (layouts.c:110),
so device_unregister() drops it to zero and nvmem_layout_release_device()
kfree()s the layout (layouts.c:84). nvmem->layout now dangles.

A consumer that still holds an nvmem_cell keeps nvmem->dev alive (the
cell took a device reference via nvmem_device_match()), so the nvmem
struct and its cell entries survive this. When the consumer later
releases the cell:

    nvmem_cell_put()                                core.c:1591
      nvmem_layout_module_put(nvmem);               core.c:1599
        if (nvmem->layout && nvmem->layout->dev.driver)   <-- UAF read
            module_put(nvmem->layout->dev.driver->owner);

nvmem->layout is non-NULL but freed, so nvmem->layout->dev.driver is read
from freed memory, followed by module_put() on a garbage owner.

Regression:
Before 87341c4dd5de, nvmem_destroy_layout() ran from the device-release
callback, i.e. only after the last reference (including consumers' cell
references) was dropped. That commit removed the kref and moved
nvmem_destroy_layout() into nvmem_unregister(), where it now runs
immediately regardless of outstanding cells. The companion SRCU change
gave nvmem->ops and the cell entries deferred/guarded teardown, but
nvmem->layout was left dereferenceable after free.

Reproduction (deterministic; needs a DT nvmem provider with a layout,
e.g. "fixed-layout", and a consumer holding a cell across provider
removal. From code inspection; no KASAN splat captured yet):
  1. provider binds and instantiates the layout device;
  2. consumer does devm_nvmem_cell_get() and keeps the cell;
  3. echo <provider> > .../unbind  -> nvmem_unregister() frees the
     layout; nvmem->layout dangles;
  4. echo <consumer> > .../unbind  -> devm release -> nvmem_cell_put()
     -> nvmem_layout_module_put() reads the freed nvmem->layout.

Note on fixing it:
The obvious "move nvmem_destroy_layout() into nvmem_release()" does not
work: the layout device's parent is nvmem->dev, so it holds a reference
on nvmem->dev, and nvmem_release() (the nvmem->dev release callback)
cannot run until the layout device is gone. A correct fix probably needs
the layout module reference decoupled from the layout device's lifetime
(e.g. caching the owner, or keeping the layout alive until all cells are
put). As this area was just reworked, I'm reporting rather than guessing
at the fix.

This is distinct from the recently discussed nvmem_cell_put() /
__nvmem_device_put() ordering (5b6b6fc49189 and the follow-up that was
rejected as a duplicate): those address the consumer's own put dropping
the last device reference, whereas here the layout is freed by the
provider's nvmem_unregister() while a consumer still holds a cell.

Thanks,
Yu Zhang