linux-kernel - [PATCH 0/2] leds-st1202 patches for -rc release of 6.14

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:
 <CWLP123MB5473552E76AE71CDE3085DA9C5C32@CWLP123MB5473.GBRP123.PROD.OUTLOOK.COM>
Date: Tue, 25 Feb 2025 21:58:09 +0000
From: Manuel Fombuena <fombuena@...look.com>
To: pavel@....cz,
	lee@...nel.org,
	corbet@....net,
	vicentiu.galanopulo@...ote-tech.co.uk,
	linux-leds@...r.kernel.org,
	linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] leds-st1202 patches for -rc release of 6.14

Following the feedback received on the set of patches for leds-st1202 that
I sent previously, I am sending separately for your consideration those
that I would like to propose for an upcoming -rc release of 6.14.

Since leds-st1202 was added on 6.14-rc1, this would avoid having to send
[PATCH 1/2] to -stable after 6.14 is released.

[PATCH 1/2] leds: leds-st1202: fix NULL pointer access on race condition

leds-st1202 calls devm_led_classdev_register_ext early in its 
initialization, even before it has filled the led_classdev struct.
Afterwards, it initializes the hardware that, additional to its normal
operations, requires a delay for it to initialize itself. Finally,
the probe function activates the channels on the devicetree, and clears
any existing pattern. 

The issue is that, with such delay between the LEDs being available on
user space after calling devm_led_classdev_register_ext and the internal
data structures being set up, there is a time in which accessing them
causes a NULL pointer access.

This predominantly manifests on systems in which leds-st1202 is loaded as
a module during the boot up process, while other processes are also
starting and interact with the LEDs while doing so. For example, routers.

While the window in which the NULL pointer access can occur is small and
some other circumstances have to concur, it is preventable with not
compromises observed.

Looking at a number of other LED drivers in the linux kernel, it is
seemingly commonplace to call devm_led_classdev_register_ext at the end of
probing which makes sense as all drivers should try to avoid a situation
similar to the one described.

If the patch is not applied, downstream projects using leds-st1202 will
need to take this issue into account if they want to avoid the possibility
of it happening, or apply the patch themselves. However, the drive will
work just the same if left alone just enough time to complete its
initialization.

[PATCH 2/2] Documentation: leds: remove .rst extension for leds-st1202 on
index

The only driver listed with the .rst extension on 
Documentation/leds/index.rst is leds-st1202. Moreover, I haven't been able
to find other entries with the extension on other index.rst files.

While this is more of a cosmetic issue, once it has been spotted I believe
it would be better to fix it before the driver is included on a final
release for the first time.

In practical terms, not applying the patch now won't have any impact so it
could be deferred as well.

Manuel Fombuena (2):
  leds: leds-st1202: fix NULL pointer access on race condition
  Documentation: leds: remove .rst extension for leds-st1202 on index

 Documentation/leds/index.rst |  2 +-
 drivers/leds/leds-st1202.c   | 21 ++++++++++-----------
 2 files changed, 11 insertions(+), 12 deletions(-)

-- 
2.48.1