Bartosz Golaszewski

The devres resource management system in the linux kernel has been blamed for use-after-free bugs triggered from user-space via device files. We will show that this problem is not caused by devres but rather by common misconceptions about linux devices lifetimes and general errors in resource management.

We will also discuss linux kernel frameworks that already deal with this problem, how they do it and how vulnerable subsystems can be improved.

Devres is a simple resource management system commonly used in linux device drivers. It's based on creating a linked list of various resources associated with given device. Managed resources can be acquired during the life-time of a device (typically when the device is probed after being bound to a driver) and will get released when the driver is detached from the device - be it on .probe() error or after .remove() returns.

On multiple occasions, devres has been blamed for use-after-free bugs that can be triggered from user-space in several subsystems. A simple way to trigger those bugs in vulnerable subsystems is to: open a device file, unbind the driver from the device and call any of the system calls relevant for this device.

While those bugs do exist, I believe devres has nothing to do with them, rather they are caused by managing resources with devres that should survive the driver unbind and instead live for as long as the underlying struct device's reference count does not drop down to 0. This talk will present detailed explanation and examples.

Devres is actually an easy way to simplify error paths and REDUCE resource leaks and memory bugs. There is only a limited number of use-cases where devres must not be used and for most cases it can be hidden behind the subsystem's APIs. The aversion to devres that certain maintainers express is unjustified and this talk aims at changing people's minds.

Since linux 4.8 the GPIO sysfs interface is deprecated. Due to its many drawbacks and bad design decisions a new user space interface has been implemented in the form of the GPIO character device which is now the preferred method of interaction with GPIOs which can't otherwise be serviced by a kernel driver. The character device brings in many new interesting features such as: polling for line events, finding GPIO chips and lines by name, changing & reading the values of multiple lines with a single ioctl (one context switch) and many more. In this presentation Bartosz will showcase the new features of the GPIO UAPI, discuss the current state of libgpiod (user space tools for using the character device) and tell you why it's beneficial to switch to the new interface.