On Fri, 12 Sept 2025 at 11:09, Krzysztof Kozlowski <k...@kernel.org> 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/20250721044456.2736300-6-tzun...@kernel.org/ > > [2] https://lpc.events/event/17/contributions/1627/ > > > > Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com> > > Cc: Bartosz Golaszewski <bartosz.golaszew...@linaro.org> > > Cc: Wolfram Sang <wsa+rene...@sang-engineering.com> > > 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 b...@bgdev.pl 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
