On Fri, Sep 12, 2025 at 10:30:45AM +0200, Greg KH wrote: > On Fri, Sep 12, 2025 at 08:17:12AM +0000, Tzung-Bi Shih wrote: > > This is a follow-up series of [1]. It tries to fix a possible UAF in the > > fops of cros_ec_chardev after the underlying protocol device has gone by > > using revocable. > > > > The 1st patch introduces the revocable which is an implementation of ideas > > from the talk [2]. > > > > The 2nd and 3rd patches add test cases for revocable in Kunit and selftest. > > > > The 4th patch converts existing protocol devices to resource providers > > of cros_ec_device. > > > > The 5th patch converts cros_ec_chardev to a resource consumer of > > cros_ec_device to fix the UAF. > > > > [1] https://lore.kernel.org/chrome-platform/20250721044456.2736300-6-tzungbi@xxxxxxxxxx/ > > [2] https://lpc.events/event/17/contributions/1627/ > > > > Cc: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > Cc: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > Cc: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> > > This is, frankly, wonderful work. Thanks so much for doing this, it's > what many of us have been wanting to see for a very long time but none > of us got around to actually doing it. > > And it has tests! And documentation! Couldn't ask for more. > > We can bikeshed about the REVOCABLE() macro name, but frankly, you wrote > it, you get to pick it :) > > Laurent, Bartosz, Wolfram, any objection to this series? I think this > addresses the issues that all of you have been raising for years with > our access of pointers that have different lifecycles from other > structures (i.e. struct cdev from struct device). I'll check this either later today or over the weekend. > Also, Danilo, if you get the chance, can you give this a review as well? > At first glance it looks good to me, but as you wrote the Rust > implementation of this feature, a second pair of eyes would be great to > have if you have the time. -- Regards, Laurent Pinchart
