linux-kernel - Re: [PATCH 3/3] gpio: shared: allow sharing a reset-gpios pin between reset-gpio and gpiolib

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAMRc=Mcu07hjSFHdAf6rJphmFoc62D4D19=Xo8PkaFbDfp8EZA@mail.gmail.com>
Date: Tue, 6 Jan 2026 11:55:20 +0100
From: Bartosz Golaszewski <brgl@...nel.org>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, Linus Walleij <linusw@...nel.org>, 
	linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] gpio: shared: allow sharing a reset-gpios pin between
 reset-gpio and gpiolib

On Mon, Jan 5, 2026 at 7:16 PM Marek Szyprowski
<m.szyprowski@...sung.com> wrote:
>
> >>
> >>> 1. Samsung TM2e - arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
> >>>
> >>> exynos-dsi 13900000.dsi: [drm:samsung_dsim_host_attach] Attached
> >>> s6e3hf2
> >>> device (lanes:4 bpp:24 mode-flags:0x6e0)
> >>> Unable to handle kernel NULL pointer dereference at virtual address
> >> Could you use faddr2line to point me to the exact offending line? This
> >> would speed up the debugging.
> >
> > I need some time to get that output, but this issue is caused by a
> > devm_gpiod_get_optional() call for a gpio that is not defined for that
> > board.
> >
> I think that everything is in the call stack:
>
> Call trace:
>   gpiod_direction_input_nonotify+0x20/0x39c (P)
>   gpiod_configure_flags+0x23c/0x480
>   gpiod_find_and_request+0x1a0/0x574
>   gpiod_get_index+0x58/0x84
>   devm_gpiod_get_index+0x20/0xb4
>   devm_gpiod_get_optional+0x18/0x30
>   samsung_dsim_host_attach+0x1c8/0x284
>   mipi_dsi_attach+0x30/0x54
>   s6e3ha2_probe+0x148/0x200 [panel_samsung_s6e3ha2]
>
> ...
>
>
> The issue is in gpiod_direction_input_nonotify+0x20/0x39c:
>
> $ grep gpiod_direction_input_nonotify System.map
> ffff800080810360 T gpiod_direction_input_nonotify
>
> $ aarch64-linux-gnu-addr2line -f -e vmlinux ffff800080810380
> class_gpio_chip_guard_constructor
> /home/m.szyprowski/dev/kernel/linux-next/drivers/gpio/gpiolib.h:231
>
> IMHO it looks that gpiod_configure_flags() is called for NULL gpio_chip.
>

The whole point of this macro is to make sure the chip is not NULL. It
dereferences gdev->chip under SRCU for that reason.

Is it the descriptor (struct gpio_desc *desc) pointer passed to
gpiod_direction_input_nonotify() that is NULL by any chance? It
shouldn't be possible but I want to rule it out.

Also: it doesn't really look like it has anything to do with shared
GPIO management. I looked into the DTS and there are no shared GPIOs.
Can you enable CONFIG_DEBUG_GPIO and post the entire kernel log just
to make sure? Is the issue reproducible and goes away when that commit
is reverted?

Bartosz