Re: [RFC PATCH 0/4] devres: warn about managed memory still held by open files at unbind

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Wed, Nov 04, 2026 at 10:31:51PM +0000, Chad Aldreda wrote:
> > Are you really expecting anyone to read all that ?
> 
> Fair enough. The short version:

I think you forgot about the second part of my reply.

> A struct cdev, miscdevice or video_device embedded in devm_kzalloc()'d
> driver state outlives the unbind through any open file, and the next
> operation on that file, usually close(), is a use-after-free. It keeps
> getting fixed one driver at a time (44f3468a0aef, 7d6358ab0286), and
> cx231xx in 7.4-rc1 still has the shape.
> 
> CONFIG_DEBUG_DEVRES_REFS, off by default: in device_unbind_cleanup(),
> before devres_release_all(), walk every task's fd table once and WARN
> when a file's private_data, i_private or i_cdev, or an object a
> subsystem names (patch 3: V4L2's video_device), points into an
> allocation about to be freed. A debugfs file still live during the walk
> is judged after release, since drivers often remove those through a
> devres action. Cost: one walk per unbind or failed probe.
> 
> Patch 4 is a test driver: unbind with its nodes open gives two WARNs,
> and KASAN then reports the use-after-frees on close. vivid, as a
> control, is silent.
> 
> The open problem (question 5 in the cover): the walk holds a reference
> on each file it inspects, so a racing close can leave it the last
> holder. It runs on a kthread so that release goes to delayed_fput
> rather than task work queued behind the unbind, but the delayed-fput
> worker is serialized, so a release there that needs a lock unbind
> holds stalls the ones behind it.

-- 
Regards,

Laurent Pinchart