On Thu, May 07, 2026 at 09:30:44AM -0700, Rob Clark wrote: > On Thu, May 7, 2026 at 9:29 AM John Harrison <[email protected]> wrote: > > > > Resending because apparently it got sent as HTML and was rejected by the > > mailing lists... > > > > On 5/5/26 14:49, Rob Clark wrote: > > > On Mon, May 4, 2026 at 5:25 PM Dmitry Baryshkov > > > <[email protected]> wrote: > > >> Mixing devm and drmm functions will result in a use-after-free on msm > > >> driver teardown if userspace keeps a reference on the drm device: > > >> The WB connector data will be destroyed because of the use of > > >> devm_kzalloc()), while the usersoace still can try interacting with the > > >> WB connector (which uses drmm_ functions). > > >> > > >> Change dpu_writeback_init() to use drmm_. > > > From [1] it doesn't sound like userspace holding the drm device open > > > is the issue (if that were possible, it seems like it would go badly), > > > but rather the order of managed cleanup? > > > > > > [1] > > > https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/xe/xe_hwmon.c?id=3a13c2de442d6bfaef9c102cd1092e6cae22b753 > > So is this not an actual issue that has been seen in the wild? It is > > just a theoretical issue based on code observation? > > > > If so, then maybe the comment should just be something like: > > > > dpu_writeback_init() was mixing devm and drmm functions - allocating > > using devm and then passing to drmm to manage. This creates the > > potential for a use-after-free bug as drmm and devm have different > > lifetimes. Fix that by consistently using drmm management. > > > > I've not seen this issue myself, but I guess Dmitry has. That comment > sounds more in-line with what I _think_ is happening..
No, I also haven't seen it. It's a teoretical issue from my PoV. -- With best wishes Dmitry
