On Fri, 12 Sept 2025 at 11:09, Krzysztof Kozlowski <[email protected]> wrote: > > On 12/09/2025 10:17, 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/[email protected]/ > > [2] https://lpc.events/event/17/contributions/1627/ > > > > Cc: Laurent Pinchart <[email protected]> > > Cc: Bartosz Golaszewski <[email protected]> > > Cc: Wolfram Sang <[email protected]> > > Thanks for the work. Just a note, please start using b4, so above Cc > will be propagated to all patches. Folks above received only the cover > letter... >
Thanks to Krzysztof for making me aware of this. Could you please Cc my [email protected] address on the next iteration. I haven't looked into the details yet but the small size of the first patch strikes me as odd. The similar changes I did for GPIO were quite big and they were designed just for a single sub-system. During the talk you reference, after I suggested a library like this, Greg KH can be heard saying: do this for two big subsystems so that you're sure it's a generic solution. Here you're only using it in a single driver which makes me wonder if we can actually use it to improve bigger offenders, like for example I2C, or even replace the custom, SRCU-based solution in GPIO we have now. Have you considered at least doing a PoC in a wider kernel framework? Just my two cents. Bartosz
