linux-kernel - [PATCH 0/3] i2c: mux: don't access GPIOLIB internal structures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20231011130204.52265-1-brgl@bgdev.pl>
Date:   Wed, 11 Oct 2023 15:02:01 +0200
From:   Bartosz Golaszewski <brgl@...ev.pl>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Andy Shevchenko <andy@...nel.org>,
        Peter Korsgaard <peter.korsgaard@...co.com>,
        Peter Rosin <peda@...ntia.se>
Cc:     linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-i2c@...r.kernel.org,
        Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
Subject: [PATCH 0/3] i2c: mux: don't access GPIOLIB internal structures

From: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>

The backstory for this short series is that we are identyfing and
removing all unauthorized uses of GPIOLIB structures across the kernel.

For example: there are many users that access struct gpio_chip when the
only user allowed to safely do this is the provider of that chip.

We are very close to removing gpiochip_find(). Another function that
poses a similar problem is gpiod_to_chip() which also returns the
address of the underlying gpio_chip without assuring that it will not go
away e.g. due to a hot-unplug event or a device unbind.

We'll need to replace it with gpiod_to_gpio_device() across the entire
tree. Let's start by actually providing it and adding the first user:
the i2c-mux-gpio driver which dereferences the otherwise opaque struct
gpio_desc.

Let's also add a helper that allows to retrieve the address of the
struct device backing the GPIO device as this is another valid use-case.

Finally, let's un-include the GPIO private header and fix the code to
access the device in a safe way.

As the change is pretty minor, it would be best if patch 3/3 could be
acked by the I2C mux maintainers and went through the GPIO tree.
Otherwise, I can apply patches 1 and 2 and provide an immutable branch.

Bartosz Golaszewski (3):
  gpiolib: provide gpio_device_to_device()
  gpiolib: provide gpiod_to_gpio_device()
  i2c: mux: gpio: don't fiddle with GPIOLIB internals

 drivers/gpio/gpiolib.c           | 38 ++++++++++++++++++++++++++++++++
 drivers/i2c/muxes/i2c-mux-gpio.c | 12 +++++-----
 include/linux/gpio/driver.h      |  3 +++
 3 files changed, 47 insertions(+), 6 deletions(-)

-- 
2.39.2