[PATCH 0/3] hwmon: Add ASUS ROG Ryujin III support

[PATCH 0/3] hwmon: Add ASUS ROG Ryujin III support

[Arie Miller]

Add hardware monitoring support for ASUS ROG Ryujin III coolers.

Compared with the Ryujin II, the Ryujin III uses different offsets in
its status reports and a different cooler-duty channel. It also does not
expose the Ryujin II's external fan-controller channels. The first patch
moves those details into per-device configuration, and the second adds
the Extreme and EVA Edition variants.

The final patch, authored by Will Smith, adds the White Edition USB ID.
Will confirmed his authorship sign-off and tested that variant on his
hardware.

The Ryujin III implementation and White Edition were tested through the
linked project pull requests. The EVA Edition hardware was tested by me.

Codex using gpt-5.6-sol assisted with porting the changes to the current
hwmon tree, organizing the patch series, updating documentation and
commit messages, and running build, checkpatch, Sparse, and Sphinx
validation. I reviewed and tested the resulting changes on ROG Ryujin
III EVA Edition hardware.

The series passes checkpatch --strict, builds in-tree with W=1 for both
built-in and module configurations, and produces no Sparse findings. The
hwmon HTML documentation also builds successfully.


Arie Miller (2):
  hwmon: (asus_rog_ryujin) Add per-device configuration
  hwmon: (asus_rog_ryujin) Add ROG Ryujin III support

Will Smith (1):
  hwmon: (asus_rog_ryujin) Add ROG Ryujin III White Edition

 Documentation/hwmon/asus_rog_ryujin.rst | 25 ++++---
 drivers/hwmon/Kconfig                   |  4 +-
 drivers/hwmon/asus_rog_ryujin.c         | 93 ++++++++++++++++++-------
 3 files changed, 84 insertions(+), 38 deletions(-)


base-commit: f39a03a64a96902e67fccf0ac796e8529def8e2d
-- 
2.55.0

[PATCH 1/3] hwmon: (asus_rog_ryujin) Add per-device configuration

[Arie Miller]

Move model-specific report offsets and capabilities into a device
information structure. This prepares the driver for coolers which use
a different report layout or do not include the external fan
controller, while preserving the existing Ryujin II 360 behavior.

Assisted-by: Codex:gpt-5.6-sol sparse
Signed-off-by: Arie Miller <renari@arimil.com>
---
 drivers/hwmon/asus_rog_ryujin.c | 72 ++++++++++++++++++++++-----------
 1 file changed, 49 insertions(+), 23 deletions(-)

diff --git a/drivers/hwmon/asus_rog_ryujin.c b/drivers/hwmon/asus_rog_ryujin.c
index 10a1f5aca988..b86b87e33615 100644
--- a/drivers/hwmon/asus_rog_ryujin.c
+++ b/drivers/hwmon/asus_rog_ryujin.c
@@ -18,15 +18,25 @@
 #define USB_VENDOR_ID_ASUS_ROG		0x0b05
 #define USB_PRODUCT_ID_RYUJIN_AIO	0x1988	/* ASUS ROG RYUJIN II 360 */
 
+struct rog_ryujin_device_info {
+	u8 temp_offset;
+	u8 pump_speed_offset;
+	u8 fan_speed_offset;
+	u8 duty_channel;
+	bool has_controller;
+};
+
+static const struct rog_ryujin_device_info rog_ryujin_ii_360_info = {
+	.temp_offset = 3,
+	.pump_speed_offset = 5,
+	.fan_speed_offset = 7,
+	.duty_channel = 0,
+	.has_controller = true,
+};
+
 #define STATUS_VALIDITY		1500	/* ms */
 #define MAX_REPORT_LENGTH	65
 
-/* Cooler status report offsets */
-#define RYUJIN_TEMP_SENSOR_1		3
-#define RYUJIN_TEMP_SENSOR_2		4
-#define RYUJIN_PUMP_SPEED		5
-#define RYUJIN_INTERNAL_FAN_SPEED	7
-
 /* Cooler duty report offsets */
 #define RYUJIN_PUMP_DUTY		4
 #define RYUJIN_INTERNAL_FAN_DUTY	5
@@ -81,6 +91,7 @@ static const char *const rog_ryujin_speed_label[] = {
 struct rog_ryujin_data {
 	struct hid_device *hdev;
 	struct device *hwmon_dev;
+	const struct rog_ryujin_device_info *info;
 	/* For reinitializing the completions below */
 	spinlock_t status_report_request_lock;
 	struct completion cooler_status_received;
@@ -112,6 +123,8 @@ static int rog_ryujin_pwm_to_percent(long val)
 static umode_t rog_ryujin_is_visible(const void *data,
 				     enum hwmon_sensor_types type, u32 attr, int channel)
 {
+	const struct rog_ryujin_data *priv = data;
+
 	switch (type) {
 	case hwmon_temp:
 		switch (attr) {
@@ -123,6 +136,8 @@ static umode_t rog_ryujin_is_visible(const void *data,
 		}
 		break;
 	case hwmon_fan:
+		if (channel >= 2 && !priv->info->has_controller)
+			return 0;
 		switch (attr) {
 		case hwmon_fan_label:
 		case hwmon_fan_input:
@@ -132,6 +147,8 @@ static umode_t rog_ryujin_is_visible(const void *data,
 		}
 		break;
 	case hwmon_pwm:
+		if (channel >= 2 && !priv->info->has_controller)
+			return 0;
 		switch (attr) {
 		case hwmon_pwm_input:
 			return 0644;
@@ -198,12 +215,14 @@ static int rog_ryujin_get_status(struct rog_ryujin_data *priv)
 	if (ret < 0)
 		return ret;
 
-	/* Retrieve controller status (speeds) */
-	ret =
-	    rog_ryujin_execute_cmd(priv, get_controller_speed_cmd, GET_CMD_LENGTH,
-				   &priv->controller_status_received);
-	if (ret < 0)
-		return ret;
+	if (priv->info->has_controller) {
+		/* Retrieve controller status (speeds) */
+		ret = rog_ryujin_execute_cmd(priv, get_controller_speed_cmd,
+					     GET_CMD_LENGTH,
+					     &priv->controller_status_received);
+		if (ret < 0)
+			return ret;
+	}
 
 	/* Retrieve cooler duty */
 	ret =
@@ -212,12 +231,14 @@ static int rog_ryujin_get_status(struct rog_ryujin_data *priv)
 	if (ret < 0)
 		return ret;
 
-	/* Retrieve controller duty */
-	ret =
-	    rog_ryujin_execute_cmd(priv, get_controller_duty_cmd, GET_CMD_LENGTH,
-				   &priv->controller_duty_received);
-	if (ret < 0)
-		return ret;
+	if (priv->info->has_controller) {
+		/* Retrieve controller duty */
+		ret = rog_ryujin_execute_cmd(priv, get_controller_duty_cmd,
+					     GET_CMD_LENGTH,
+					     &priv->controller_duty_received);
+		if (ret < 0)
+			return ret;
+	}
 
 	priv->updated = jiffies;
 	return 0;
@@ -289,6 +310,7 @@ static int rog_ryujin_write_fixed_duty(struct rog_ryujin_data *priv, int channel
 			return ret;
 
 		memcpy(set_cmd, set_cooler_duty_cmd, SET_CMD_LENGTH);
+		set_cmd[2] = priv->info->duty_channel;
 
 		/* Cooler duties are set as 0-100% */
 		val = rog_ryujin_pwm_to_percent(val);
@@ -394,10 +416,12 @@ static int rog_ryujin_raw_event(struct hid_device *hdev, struct hid_report *repo
 
 	if (data[1] == RYUJIN_GET_COOLER_STATUS_CMD_RESPONSE) {
 		/* Received coolant temp and speeds of pump and internal fan */
-		priv->temp_input[0] =
-		    data[RYUJIN_TEMP_SENSOR_1] * 1000 + data[RYUJIN_TEMP_SENSOR_2] * 100;
-		priv->speed_input[0] = get_unaligned_le16(data + RYUJIN_PUMP_SPEED);
-		priv->speed_input[1] = get_unaligned_le16(data + RYUJIN_INTERNAL_FAN_SPEED);
+		priv->temp_input[0] = data[priv->info->temp_offset] * 1000 +
+			data[priv->info->temp_offset + 1] * 100;
+		priv->speed_input[0] =
+			get_unaligned_le16(data + priv->info->pump_speed_offset);
+		priv->speed_input[1] =
+			get_unaligned_le16(data + priv->info->fan_speed_offset);
 
 		if (!completion_done(&priv->cooler_status_received))
 			complete_all(&priv->cooler_status_received);
@@ -476,6 +500,7 @@ static int rog_ryujin_probe(struct hid_device *hdev, const struct hid_device_id
 		return -ENOMEM;
 
 	priv->hdev = hdev;
+	priv->info = (const struct rog_ryujin_device_info *)id->driver_data;
 	hid_set_drvdata(hdev, priv);
 
 	/*
@@ -546,7 +571,8 @@ static void rog_ryujin_remove(struct hid_device *hdev)
 }
 
 static const struct hid_device_id rog_ryujin_table[] = {
-	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_AIO) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_AIO),
+	  .driver_data = (kernel_ulong_t)&rog_ryujin_ii_360_info },
 	{ }
 };
 
-- 
2.55.0

[PATCH 2/3] hwmon: (asus_rog_ryujin) Add ROG Ryujin III support

[Arie Miller]

The ROG Ryujin III uses different report offsets and a different
cooler-duty channel from the Ryujin II. It also lacks the separate
external fan controller supplied with the older model.

Add model data and USB IDs for the Extreme and EVA Edition variants.
Skip controller commands and hide the unavailable controller hwmon
channels for these devices. Update the driver documentation, Kconfig
text, and module description accordingly.

Link: https://github.com/aleksamagicka/asus_rog_ryujin-hwmon/pull/9
Assisted-by: Codex:gpt-5.6-sol sparse
Signed-off-by: Arie Miller <renari@arimil.com>
---
 Documentation/hwmon/asus_rog_ryujin.rst | 24 +++++++++++++-----------
 drivers/hwmon/Kconfig                   |  4 ++--
 drivers/hwmon/asus_rog_ryujin.c         | 18 ++++++++++++++++--
 3 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/Documentation/hwmon/asus_rog_ryujin.rst b/Documentation/hwmon/asus_rog_ryujin.rst
index 9f77da070022..cfdfe3712f19 100644
--- a/Documentation/hwmon/asus_rog_ryujin.rst
+++ b/Documentation/hwmon/asus_rog_ryujin.rst
@@ -6,6 +6,8 @@ Kernel driver asus_rog_ryujin
 Supported devices:
 
 * ASUS ROG RYUJIN II 360
+* ASUS ROG RYUJIN III EXTREME
+* ASUS ROG RYUJIN III EVA EDITION
 
 Author: Aleksa Savic
 
@@ -16,10 +18,10 @@ This driver enables hardware monitoring support for the listed ASUS ROG RYUJIN
 all-in-one CPU liquid coolers. Available sensors are pump, internal and external
 (controller) fan speed in RPM, their duties in PWM, as well as coolant temperature.
 
-Attaching external fans to the controller is optional and allows them to be
-controlled from the device. If not connected, the fan-related sensors will
-report zeroes. The controller is a separate hardware unit that comes bundled
-with the AIO and connects to it to allow fan control.
+The RYUJIN II includes a separate external fan controller. Attaching fans to
+the controller is optional and allows them to be controlled from the device.
+If not connected, the controller-related sensors will report zeroes. The
+RYUJIN III does not expose these controller channels.
 
 The addressable LCD screen is not supported in this driver and should
 be controlled through userspace tools.
@@ -33,15 +35,15 @@ supports hot swapping.
 Sysfs entries
 -------------
 
-=========== =============================================
+=========== ==========================================================
 fan1_input  Pump speed (in rpm)
 fan2_input  Internal fan speed (in rpm)
-fan3_input  External (controller) fan 1 speed (in rpm)
-fan4_input  External (controller) fan 2 speed (in rpm)
-fan5_input  External (controller) fan 3 speed (in rpm)
-fan6_input  External (controller) fan 4 speed (in rpm)
+fan3_input  External (controller) fan 1 speed (in rpm, RYUJIN II only)
+fan4_input  External (controller) fan 2 speed (in rpm, RYUJIN II only)
+fan5_input  External (controller) fan 3 speed (in rpm, RYUJIN II only)
+fan6_input  External (controller) fan 4 speed (in rpm, RYUJIN II only)
 temp1_input Coolant temperature (in millidegrees Celsius)
 pwm1        Pump duty
 pwm2        Internal fan duty
-pwm3        External (controller) fan duty
-=========== =============================================
+pwm3        External (controller) fan duty (RYUJIN II only)
+=========== ==========================================================
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index e60bfc31bbad..c7640fcb32e4 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -293,11 +293,11 @@ config SENSORS_ASC7621
 	  will be called asc7621.
 
 config SENSORS_ASUS_ROG_RYUJIN
-	tristate "ASUS ROG RYUJIN II 360 hardware monitoring driver"
+	tristate "ASUS ROG RYUJIN hardware monitoring driver"
 	depends on HID
 	help
 	  If you say yes here you get support for the fans and sensors of
-	  the ASUS ROG RYUJIN II 360 AIO CPU liquid cooler.
+	  supported ASUS ROG RYUJIN II and III AIO CPU liquid coolers.
 
 	  This driver can also be built as a module. If so, the module
 	  will be called asus_rog_ryujin.
diff --git a/drivers/hwmon/asus_rog_ryujin.c b/drivers/hwmon/asus_rog_ryujin.c
index b86b87e33615..5bc60c6036de 100644
--- a/drivers/hwmon/asus_rog_ryujin.c
+++ b/drivers/hwmon/asus_rog_ryujin.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * hwmon driver for Asus ROG Ryujin II 360 AIO cooler.
+ * hwmon driver for Asus ROG Ryujin AIO coolers.
  *
  * Copyright 2024 Aleksa Savic <savicaleksa83@gmail.com>
  */
@@ -17,6 +17,8 @@
 
 #define USB_VENDOR_ID_ASUS_ROG		0x0b05
 #define USB_PRODUCT_ID_RYUJIN_AIO	0x1988	/* ASUS ROG RYUJIN II 360 */
+#define USB_PRODUCT_ID_RYUJIN_III_EXTREME	0x1bcb
+#define USB_PRODUCT_ID_RYUJIN_III_EVA		0x1ade
 
 struct rog_ryujin_device_info {
 	u8 temp_offset;
@@ -34,6 +36,14 @@ static const struct rog_ryujin_device_info rog_ryujin_ii_360_info = {
 	.has_controller = true,
 };
 
+static const struct rog_ryujin_device_info rog_ryujin_iii_info = {
+	.temp_offset = 5,
+	.pump_speed_offset = 7,
+	.fan_speed_offset = 10,
+	.duty_channel = 1,
+	.has_controller = false,
+};
+
 #define STATUS_VALIDITY		1500	/* ms */
 #define MAX_REPORT_LENGTH	65
 
@@ -573,6 +583,10 @@ static void rog_ryujin_remove(struct hid_device *hdev)
 static const struct hid_device_id rog_ryujin_table[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_AIO),
 	  .driver_data = (kernel_ulong_t)&rog_ryujin_ii_360_info },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_III_EXTREME),
+	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_III_EVA),
+	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },
 	{ }
 };
 
@@ -602,4 +616,4 @@ module_exit(rog_ryujin_exit);
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Aleksa Savic <savicaleksa83@gmail.com>");
-MODULE_DESCRIPTION("Hwmon driver for Asus ROG Ryujin II 360 AIO cooler");
+MODULE_DESCRIPTION("Hwmon driver for Asus ROG Ryujin AIO coolers");
-- 
2.55.0

[PATCH 3/3] hwmon: (asus_rog_ryujin) Add ROG Ryujin III White Edition

[Arie Miller]

From: Will Smith <github@notthatwillsmith.com>

The ROG Ryujin III White Edition uses the same report layout as the
other supported Ryujin III variants. Add its USB device ID and list it
in the driver documentation.

The device was tested with the driver on the author's hardware.

Link: https://github.com/aleksamagicka/asus_rog_ryujin-hwmon/pull/10
Signed-off-by: Will Smith <github@notthatwillsmith.com>
Assisted-by: Codex:gpt-5.6-sol sparse
Signed-off-by: Arie Miller <renari@arimil.com>
---
 Documentation/hwmon/asus_rog_ryujin.rst | 1 +
 drivers/hwmon/asus_rog_ryujin.c         | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/Documentation/hwmon/asus_rog_ryujin.rst b/Documentation/hwmon/asus_rog_ryujin.rst
index cfdfe3712f19..b0d7ce8dd921 100644
--- a/Documentation/hwmon/asus_rog_ryujin.rst
+++ b/Documentation/hwmon/asus_rog_ryujin.rst
@@ -8,6 +8,7 @@ Supported devices:
 * ASUS ROG RYUJIN II 360
 * ASUS ROG RYUJIN III EXTREME
 * ASUS ROG RYUJIN III EVA EDITION
+* ASUS ROG RYUJIN III WHITE EDITION
 
 Author: Aleksa Savic
 
diff --git a/drivers/hwmon/asus_rog_ryujin.c b/drivers/hwmon/asus_rog_ryujin.c
index 5bc60c6036de..9b34c6e06bf7 100644
--- a/drivers/hwmon/asus_rog_ryujin.c
+++ b/drivers/hwmon/asus_rog_ryujin.c
@@ -19,6 +19,7 @@
 #define USB_PRODUCT_ID_RYUJIN_AIO	0x1988	/* ASUS ROG RYUJIN II 360 */
 #define USB_PRODUCT_ID_RYUJIN_III_EXTREME	0x1bcb
 #define USB_PRODUCT_ID_RYUJIN_III_EVA		0x1ade
+#define USB_PRODUCT_ID_RYUJIN_III_WHITE		0x1ada
 
 struct rog_ryujin_device_info {
 	u8 temp_offset;
@@ -587,6 +588,8 @@ static const struct hid_device_id rog_ryujin_table[] = {
 	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_III_EVA),
 	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_III_WHITE),
+	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },
 	{ }
 };
 
-- 
2.55.0

Re: [PATCH 3/3] hwmon: (asus_rog_ryujin) Add ROG Ryujin III White Edition

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] Hardware and input processing are started before wait queue completions are initialized, leading to potential NULL pointer dereferences.
- [High] The spinlock `status_report_request_lock` provides no mutual exclusion against the raw event handler, leading to race conditions with completions.
- [High] The raw event handler fails to validate the size of incoming HID reports.
- [High] The driver updates and reads shared sensor data fields concurrently between `rog_ryujin_raw_event` and sysfs operations without using the mandated `hwmon_lock()`.
--

--- Patch [3]: [PATCH 3/3] hwmon: (asus_rog_ryujin) Add ROG Ryujin III White Edition ---
commit 7de73211f5a55165f52d68bf9aae14fa4ccb23f0
Author: Will Smith <github@notthatwillsmith.com>

hwmon: (asus_rog_ryujin) Add ROG Ryujin III White Edition

This commit adds support for the ROG Ryujin III White Edition liquid cooler.
It adds the USB device ID to the hardware monitoring driver and updates the
documentation.

Link: https://github.com/aleksamagicka/asus_rog_ryujin-hwmon/pull/10

> diff --git a/drivers/hwmon/asus_rog_ryujin.c b/drivers/hwmon/asus_rog_ryujin.c
> --- a/drivers/hwmon/asus_rog_ryujin.c
> +++ b/drivers/hwmon/asus_rog_ryujin.c

[ ... ]

> @@ -587,6 +588,8 @@ static const struct hid_device_id rog_ryujin_table[] = {
>  	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_III_EVA),
>  	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },
> +	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_III_WHITE),
> +	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },
>  	{ }
>  };

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing this driver I 
noticed a pre-existing issue with hardware initialization.

In rog_ryujin_probe(), event polling is started before the wait queue
completions are initialized:

    ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
    ...
    init_completion(&priv->cooler_status_received);

Could this lead to a NULL pointer dereference or list corruption if the
device sends an early report and rog_ryujin_raw_event() calls complete_all()
on the uninitialized completion?

[Severity: High]
This is a pre-existing issue, but does the status_report_request_lock provide
adequate mutual exclusion?

In rog_ryujin_execute_cmd(), the lock is taken when reinitializing completions:

    spin_lock_bh(&priv->status_report_request_lock);
    reinit_completion(status_completion);
    spin_unlock_bh(&priv->status_report_request_lock);

However, in rog_ryujin_raw_event(), complete_all() is called without
acquiring this lock. Can this lead to race conditions with the completion
state being clobbered, potentially causing sysfs reads to hang and return
-ETIMEDOUT?

[Severity: High]
This isn't a bug introduced by this patch, but is it possible for an
out-of-bounds read to occur when parsing the HID report?

In rog_ryujin_raw_event(), the incoming report is parsed directly:

    if (data[1] == RYUJIN_GET_COOLER_STATUS_CMD_RESPONSE) {
        priv->temp_input[0] = data[priv->info->temp_offset] * 1000 +

Should the size parameter be validated before accessing data offsets to
prevent exposing stale or uninitialized memory if a truncated packet is
received?

[Severity: High]
This is a pre-existing issue, but does this driver violate the hwmon
subsystem locking guidelines?

The driver updates and reads shared sensor data fields concurrently between
rog_ryujin_raw_event() and sysfs operations:

    priv->temp_input[0] = data[priv->info->temp_offset] * 1000 +
        data[priv->info->temp_offset + 1] * 100;

And in rog_ryujin_read():

    *val = priv->temp_input[channel];

Are hwmon_lock() and hwmon_unlock() required here to synchronize the
attribute access, as mandated for hardware monitoring drivers?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807000107.1786892-1-renari@arimil.com?part=3

Re: [PATCH 2/3] hwmon: (asus_rog_ryujin) Add ROG Ryujin III support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing bounds check on the incoming HID report size allows out-of-bounds memory reads.
- [High] Completions and spinlocks are initialized after enabling HID hardware interrupts, creating a race condition that leads to a NULL pointer dereference.
- [Medium] Ineffective locking when reinitializing completions causes a data race on SMP systems.
- [Medium] Incorrect `time_after` calculation allows uninitialized sensor data to be returned to userspace if read in the same jiffy as probe.
- [Medium] The driver violates the hwmon subsystem requirement to use hwmon_lock() for serializing interrupt updates.
--

--- Patch [2]: [PATCH 2/3] hwmon: (asus_rog_ryujin) Add ROG Ryujin III support ---
commit 3d0c1a58d5a805ca4eebf7afcc2b51a8194835be
Author: Arie Miller <renari@arimil.com>

hwmon: (asus_rog_ryujin) Add ROG Ryujin III support
    
The ROG Ryujin III uses different report offsets and a different
cooler-duty channel from the Ryujin II. It also lacks the separate
external fan controller supplied with the older model.

Link: https://github.com/aleksamagicka/asus_rog_ryujin-hwmon/pull/9

> diff --git a/drivers/hwmon/asus_rog_ryujin.c b/drivers/hwmon/asus_rog_ryujin.c
> index b86b87e33615d..5bc60c6036de3 100644
> --- a/drivers/hwmon/asus_rog_ryujin.c
> +++ b/drivers/hwmon/asus_rog_ryujin.c

[ ... ]

> @@ -34,6 +36,14 @@ static const struct rog_ryujin_device_info rog_ryujin_ii_360_info = {
>  	.has_controller = true,
>  };
>  
> +static const struct rog_ryujin_device_info rog_ryujin_iii_info = {
> +	.temp_offset = 5,
> +	.pump_speed_offset = 7,
> +	.fan_speed_offset = 10,

[Severity: High]
This is a pre-existing issue, but does rog_ryujin_raw_event() verify if the
incoming HID report size is sufficiently large before accessing dynamic
payload offsets?

For example, it unconditionally reads:

priv->speed_input[1] =
    get_unaligned_le16(data + priv->info->fan_speed_offset);

Since this patch adds new devices with larger offsets, could a truncated HID
report cause an out-of-bounds memory read here?

> +	.duty_channel = 1,
> +	.has_controller = false,
> +};
> +
>  #define STATUS_VALIDITY		1500	/* ms */

[Severity: Medium]
This isn't a bug introduced by this patch, but does rog_ryujin_get_status()
correctly handle being called in the exact same jiffy as the probe?

If a thermal governor or monitoring tool polls the device immediately upon
registration, and it evaluates the time check:

if (!time_after(jiffies, priv->updated + msecs_to_jiffies(STATUS_VALIDITY))) {
    /* Data is up to date */
    return 0;
}

Since time_after(jiffies, jiffies) is false, the negation makes this
condition true. Would this incorrectly skip hardware polling and return
uninitialized sensor data to userspace?

[ ... ]

> @@ -573,6 +583,10 @@ static void rog_ryujin_remove(struct hid_device *hdev)
>  static const struct hid_device_id rog_ryujin_table[] = {
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_AIO),
>  	  .driver_data = (kernel_ulong_t)&rog_ryujin_ii_360_info },
> +	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_III_EXTREME),
> +	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },
> +	{ HID_USB_DEVICE(USB_VENDOR_ID_ASUS_ROG, USB_PRODUCT_ID_RYUJIN_III_EVA),
> +	  .driver_data = (kernel_ulong_t)&rog_ryujin_iii_info },
>  	{ }
>  };

[Severity: High]
This isn't a bug introduced by this patch, but does rog_ryujin_probe() enable
hardware interrupts before initializing the synchronization primitives?

If hid_hw_open() is called before init_completion() and spin_lock_init(),
and the device sends a report immediately:

rog_ryujin_raw_event()
    if (!completion_done(&priv->cooler_status_received))
        complete_all(&priv->cooler_status_received);

Could this attempt to complete an uninitialized structure and cause a NULL
pointer dereference?


[Severity: Medium]
This is a pre-existing issue, but is the locking around completions effective
against concurrent raw events?

rog_ryujin_execute_cmd() takes a lock to protect the completion:

spin_lock_bh(&priv->status_report_request_lock);
reinit_completion(status_completion);
spin_unlock_bh(&priv->status_report_request_lock);

However, rog_ryujin_raw_event() signals this completion without acquiring the
corresponding lock:

if (!completion_done(&priv->cooler_status_received))
    complete_all(&priv->cooler_status_received);

Could this result in a data race on SMP systems, leading to corrupted
completion state or premature timeouts?


[Severity: Medium]
This isn't a bug introduced by this patch, but does this driver adhere to the
hardware monitoring subsystem guidelines for locking?

The hwmon guidelines state that drivers must use hwmon_lock() and
hwmon_unlock() for serializing attributes registered outside the info
parameter, and for interrupt handling.

In rog_ryujin_raw_event(), the driver asynchronously modifies shared state in
interrupt context without the hwmon lock:

priv->temp_input[0] = data[priv->info->temp_offset] * 1000 +
    data[priv->info->temp_offset + 1] * 100;

Could this lead to inconsistent or torn reads when rog_ryujin_read() accesses
these arrays concurrently from process context?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807000107.1786892-1-renari@arimil.com?part=2

Re: [PATCH 1/3] hwmon: (asus_rog_ryujin) Add per-device configuration

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

New issues:
- [High] Dynamic sysfs IDs (new_id) binding will cause a NULL pointer dereference because `id->driver_data` is unchecked.

Pre-existing issues:
- [High] Missing bounds check on HID report size before accessing payload offsets in `rog_ryujin_raw_event`, leading to an out-of-bounds read and information leak.
- [High] The `status_report_request_lock` fails to protect `reinit_completion()` from concurrent `complete_all()` calls in `rog_ryujin_raw_event`.
- [High] The device is exposed to HID raw events before its completions and locks are initialized, risking a NULL pointer dereference and kernel crash.
- [High] The driver allocates a DMA buffer using `devm_kzalloc()`, which breaks cacheline alignment and causes memory corruption on non-coherent DMA architectures.
--

--- Patch [1]: [PATCH 1/3] hwmon: (asus_rog_ryujin) Add per-device configuration ---
commit 532faa30887394da7e60da86be21849f6a4f86c4
Author: Arie Miller <renari@arimil.com>

hwmon: (asus_rog_ryujin) Add per-device configuration

Move model-specific report offsets and capabilities into a device
information structure. This prepares the driver for coolers which use
a different report layout or do not include the external fan
controller, while preserving the existing Ryujin II 360 behavior.

> diff --git a/drivers/hwmon/asus_rog_ryujin.c b/drivers/hwmon/asus_rog_ryujin.c
> index 10a1f5aca988d..b86b87e33615d 100644
> --- a/drivers/hwmon/asus_rog_ryujin.c
> +++ b/drivers/hwmon/asus_rog_ryujin.c
[ ... ]
> @@ -394,10 +416,12 @@ static int rog_ryujin_raw_event(struct hid_device *hdev, struct hid_report *repo
>  
>  	if (data[1] == RYUJIN_GET_COOLER_STATUS_CMD_RESPONSE) {
>  		/* Received coolant temp and speeds of pump and internal fan */
> -		priv->temp_input[0] =
> -		    data[RYUJIN_TEMP_SENSOR_1] * 1000 + data[RYUJIN_TEMP_SENSOR_2] * 100;
> -		priv->speed_input[0] = get_unaligned_le16(data + RYUJIN_PUMP_SPEED);
> -		priv->speed_input[1] = get_unaligned_le16(data + RYUJIN_INTERNAL_FAN_SPEED);
> +		priv->temp_input[0] = data[priv->info->temp_offset] * 1000 +
> +			data[priv->info->temp_offset + 1] * 100;

[Severity: High]
This is a pre-existing issue, but does this code lack a bounds check on the
incoming HID report size?

If a malicious device sends a truncated report that is smaller than the
expected payload, the size parameter is ignored. Accessing offsets like
data[priv->info->temp_offset] could result in an out-of-bounds read.

Can we add a check against the size parameter before accessing the payload?

> +		priv->speed_input[0] =
> +			get_unaligned_le16(data + priv->info->pump_speed_offset);
> +		priv->speed_input[1] =
> +			get_unaligned_le16(data + priv->info->fan_speed_offset);
>  
>  		if (!completion_done(&priv->cooler_status_received))
>  			complete_all(&priv->cooler_status_received);

[Severity: High]
This is a pre-existing issue, but is there a data race between this
complete_all() call and reinit_completion()?

In rog_ryujin_execute_cmd(), the status_report_request_lock is used:

spin_lock_bh(&priv->status_report_request_lock);
reinit_completion(status_completion);
spin_unlock_bh(&priv->status_report_request_lock);

However, complete_all() is called here in the raw event handler without
acquiring status_report_request_lock. If the device sends an unsolicited
report or commands are interleaved, could this lead to corrupted completion
state or missed wakeups?

[ ... ]
> @@ -476,6 +500,7 @@ static int rog_ryujin_probe(struct hid_device *hdev, const struct hid_device_id
>  		return -ENOMEM;
>  
>  	priv->hdev = hdev;
> +	priv->info = (const struct rog_ryujin_device_info *)id->driver_data;

[Severity: High]
When binding the driver dynamically via the new_id sysfs interface,
id->driver_data can be NULL if the data field is omitted. 

If priv->info is assigned NULL here, won't this cause a panic when the hwmon
core subsequently queries attribute visibility during device registration?

hwmon_device_register_with_info()
   rog_ryujin_is_visible()
      if (channel >= 2 && !priv->info->has_controller)
                                 ^^^^

Could we add a check to validate id->driver_data before assignment?

>  	hid_set_drvdata(hdev, priv);
>  
[ ... ]
> 	ret = hid_parse(hdev);
> 	if (ret) {
> 		hid_err(hdev, "hid parse failed with %d\n", ret);
> 		return ret;
> 	}
> 
> 	/* Enable hidraw so existing user-space tools can continue to work */
> 	ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
> 	if (ret) {
> 		hid_err(hdev, "hid hw start failed with %d\n", ret);
> 		return ret;
> 	}
> 
> 	ret = hid_hw_open(hdev);

[Severity: High]
This is a pre-existing issue, but is the device exposed to HID raw events
before its completion structures are initialized?

If hid_hw_start() and hid_hw_open() are called before init_completion()
initializes queues like cooler_status_received, and the device sends an
immediate interrupt report:

rog_ryujin_raw_event()
   complete_all(&priv->cooler_status_received)

Could this dereference a NULL pointer since the completions were only just
allocated with devm_kzalloc() and have not yet been initialized?

> 	if (ret) {
> 		hid_err(hdev, "hid hw open failed with %d\n", ret);
> 		goto fail_and_stop;
> 	}
> 
> 	priv->buffer = devm_kzalloc(&hdev->dev, MAX_REPORT_LENGTH, GFP_KERNEL);

[Severity: High]
This is a pre-existing issue, but is it safe to use devm_kzalloc() for a DMA
buffer?

When this buffer is later passed to hid_hw_output_report() in
rog_ryujin_write_expanded(), it is inherently mapped for DMA.

Because devm_kzalloc() embeds a devres header, the returned pointer is not
cacheline aligned. On non-coherent architectures, cache invalidation during
DMA operations could corrupt the adjacent devres header or preceding memory.

Should this buffer be allocated with a non-devm allocator like kzalloc()
to guarantee proper alignment?

> 	if (!priv->buffer) {
> 		ret = -ENOMEM;
> 		goto fail_and_close;
> 	}
> 
> 	spin_lock_init(&priv->status_report_request_lock);
> 	init_completion(&priv->cooler_status_received);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807000107.1786892-1-renari@arimil.com?part=1

Re: [PATCH 1/3] hwmon: (asus_rog_ryujin) Add per-device configuration

[Guenter Roeck]

On 8/6/26 17:14, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> 
> New issues:
> - [High] Dynamic sysfs IDs (new_id) binding will cause a NULL pointer dereference because `id->driver_data` is unchecked.
> 

Looking at other drivers, this seems to be real. See wacom_probe().
Please add that check.

> Pre-existing issues:
> - [High] Missing bounds check on HID report size before accessing payload offsets in `rog_ryujin_raw_event`, leading to an out-of-bounds read and information leak.
> - [High] The `status_report_request_lock` fails to protect `reinit_completion()` from concurrent `complete_all()` calls in `rog_ryujin_raw_event`.
> - [High] The device is exposed to HID raw events before its completions and locks are initialized, risking a NULL pointer dereference and kernel crash.
> - [High] The driver allocates a DMA buffer using `devm_kzalloc()`, which breaks cacheline alignment and causes memory corruption on non-coherent DMA architectures.
> --
> 

No need to fix as part of this series, though of course patches would be appreciated.

Thanks,
Guenter

Re: [PATCH 1/3] hwmon: (asus_rog_ryujin) Add per-device configuration

[Arimil]

Sounds good, I'm very inexperienced with the kernel workflow (I didn't
even know you could e-mail patches directly from git). All of the ids
passed into this should have that data, but a sanity check for an
invalid id definitely can't hurt. I'll make a new series and open a PR
to the drivers github repo with this change sometime this week.


On Sun, Aug 9, 2026 at 4:23 PM Arimil <renari@arimil.com> wrote:
>
> Sounds good, I'm very inexperienced with the kernel workflow (I didn't even know you could e-mail patches directly from git). All of the ids passed into this should have that data, but a sanity check for an invalid id definitely can't hurt. I'll make a new series and open a PR to the drivers github repo with this change sometime this week.
>
> On Sun, Aug 9, 2026 at 12:37 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 8/6/26 17:14, sashiko-bot@kernel.org wrote:
>> > Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
>> >
>> > New issues:
>> > - [High] Dynamic sysfs IDs (new_id) binding will cause a NULL pointer dereference because `id->driver_data` is unchecked.
>> >
>>
>> Looking at other drivers, this seems to be real. See wacom_probe().
>> Please add that check.
>>
>> > Pre-existing issues:
>> > - [High] Missing bounds check on HID report size before accessing payload offsets in `rog_ryujin_raw_event`, leading to an out-of-bounds read and information leak.
>> > - [High] The `status_report_request_lock` fails to protect `reinit_completion()` from concurrent `complete_all()` calls in `rog_ryujin_raw_event`.
>> > - [High] The device is exposed to HID raw events before its completions and locks are initialized, risking a NULL pointer dereference and kernel crash.
>> > - [High] The driver allocates a DMA buffer using `devm_kzalloc()`, which breaks cacheline alignment and causes memory corruption on non-coherent DMA architectures.
>> > --
>> >
>>
>> No need to fix as part of this series, though of course patches would be appreciated.
>>
>> Thanks,
>> Guenter
>>

Re: [PATCH 1/3] hwmon: (asus_rog_ryujin) Add per-device configuration

[Guenter Roeck]

On 8/9/26 13:23, Arimil wrote:
> Sounds good, I'm very inexperienced with the kernel workflow (I didn't even know you could e-mail patches directly from git). All of the ids passed into this should have that data, but a sanity check for an invalid id definitely can't hurt. I'll make a new series and open a PR to the drivers github repo with this change sometime this week.
> 

What github repo ? The Linux kernel is not hosted at github.
It is hosted at git.kernel.org.

The workflow is described in Documentation/process/submitting-patches.rst
I would suggest to look it up.

Thanks,
Guenter

> On Sun, Aug 9, 2026 at 12:37 PM Guenter Roeck <linux@roeck-us.net <mailto:linux@roeck-us.net>> wrote:
> 
>     On 8/6/26 17:14, sashiko-bot@kernel.org <mailto:sashiko-bot@kernel.org> wrote:
>      > Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
>      >
>      > New issues:
>      > - [High] Dynamic sysfs IDs (new_id) binding will cause a NULL pointer dereference because `id->driver_data` is unchecked.
>      >
> 
>     Looking at other drivers, this seems to be real. See wacom_probe().
>     Please add that check.
> 
>      > Pre-existing issues:
>      > - [High] Missing bounds check on HID report size before accessing payload offsets in `rog_ryujin_raw_event`, leading to an out-of-bounds read and information leak.
>      > - [High] The `status_report_request_lock` fails to protect `reinit_completion()` from concurrent `complete_all()` calls in `rog_ryujin_raw_event`.
>      > - [High] The device is exposed to HID raw events before its completions and locks are initialized, risking a NULL pointer dereference and kernel crash.
>      > - [High] The driver allocates a DMA buffer using `devm_kzalloc()`, which breaks cacheline alignment and causes memory corruption on non-coherent DMA architectures.
>      > --
>      >
> 
>     No need to fix as part of this series, though of course patches would be appreciated.
> 
>     Thanks,
>     Guenter
> 

Re: [PATCH 1/3] hwmon: (asus_rog_ryujin) Add per-device configuration

[Arimil]

The github mirror that hosts the same code here:
https://github.com/aleksamagicka/asus_rog_ryujin-hwmon

On Sun, Aug 9, 2026 at 5:23 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 8/9/26 13:23, Arimil wrote:
> > Sounds good, I'm very inexperienced with the kernel workflow (I didn't even know you could e-mail patches directly from git). All of the ids passed into this should have that data, but a sanity check for an invalid id definitely can't hurt. I'll make a new series and open a PR to the drivers github repo with this change sometime this week.
> >
>
> What github repo ? The Linux kernel is not hosted at github.
> It is hosted at git.kernel.org.
>
> The workflow is described in Documentation/process/submitting-patches.rst
> I would suggest to look it up.
>
> Thanks,
> Guenter
>
> > On Sun, Aug 9, 2026 at 12:37 PM Guenter Roeck <linux@roeck-us.net <mailto:linux@roeck-us.net>> wrote:
> >
> >     On 8/6/26 17:14, sashiko-bot@kernel.org <mailto:sashiko-bot@kernel.org> wrote:
> >      > Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> >      >
> >      > New issues:
> >      > - [High] Dynamic sysfs IDs (new_id) binding will cause a NULL pointer dereference because `id->driver_data` is unchecked.
> >      >
> >
> >     Looking at other drivers, this seems to be real. See wacom_probe().
> >     Please add that check.
> >
> >      > Pre-existing issues:
> >      > - [High] Missing bounds check on HID report size before accessing payload offsets in `rog_ryujin_raw_event`, leading to an out-of-bounds read and information leak.
> >      > - [High] The `status_report_request_lock` fails to protect `reinit_completion()` from concurrent `complete_all()` calls in `rog_ryujin_raw_event`.
> >      > - [High] The device is exposed to HID raw events before its completions and locks are initialized, risking a NULL pointer dereference and kernel crash.
> >      > - [High] The driver allocates a DMA buffer using `devm_kzalloc()`, which breaks cacheline alignment and causes memory corruption on non-coherent DMA architectures.
> >      > --
> >      >
> >
> >     No need to fix as part of this series, though of course patches would be appreciated.
> >
> >     Thanks,
> >     Guenter
> >
>

Re: [PATCH 1/3] hwmon: (asus_rog_ryujin) Add per-device configuration

[Guenter Roeck]

On 8/9/26 15:03, Arimil wrote:
> The github mirror that hosts the same code here:
> https://github.com/aleksamagicka/asus_rog_ryujin-hwmon
> 

Sorry, you lost me. Why did you submit a patch series for inclusion
into the upstream Linux kernel if you want it to be applied to some
downstream driver on github ?

Either case, sure, go ahead, and feel free to discuss with the maintainer
of that driver if and when to submit the patches for inclusion into the
upstream Linux kernel. Going forward, please do not submit patches for
inclusion into the upstream Linux kernel if that is not what you want.

Thanks,
Guenter

Re: [PATCH 1/3] hwmon: (asus_rog_ryujin) Add per-device configuration

[Arimil]

This patch has already been submitted there for months, I'm now
submitting this to be included in the kernel so it doesn't have to be
compiled in via dkms. The patch I was talking about when saying I
would create a new series was the null check asked by the bot.

On Sun, Aug 9, 2026 at 6:54 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 8/9/26 15:03, Arimil wrote:
> > The github mirror that hosts the same code here:
> > https://github.com/aleksamagicka/asus_rog_ryujin-hwmon
> >
>
> Sorry, you lost me. Why did you submit a patch series for inclusion
> into the upstream Linux kernel if you want it to be applied to some
> downstream driver on github ?
>
> Either case, sure, go ahead, and feel free to discuss with the maintainer
> of that driver if and when to submit the patches for inclusion into the
> upstream Linux kernel. Going forward, please do not submit patches for
> inclusion into the upstream Linux kernel if that is not what you want.
>
> Thanks,
> Guenter
>

Re: [PATCH 1/3] hwmon: (asus_rog_ryujin) Add per-device configuration

[Guenter Roeck]

On 8/9/26 18:08, Arimil wrote:
> This patch has already been submitted there for months, I'm now
> submitting this to be included in the kernel so it doesn't have to be
> compiled in via dkms. The patch I was talking about when saying I
> would create a new series was the null check asked by the bot.
> 

Please stop top-posting. Then why do you even mention the downstream driver ?
Its existence and/or status is completely irrelevant for the upstream kernel.

Guenter

> On Sun, Aug 9, 2026 at 6:54 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 8/9/26 15:03, Arimil wrote:
>>> The github mirror that hosts the same code here:
>>> https://github.com/aleksamagicka/asus_rog_ryujin-hwmon
>>>
>>
>> Sorry, you lost me. Why did you submit a patch series for inclusion
>> into the upstream Linux kernel if you want it to be applied to some
>> downstream driver on github ?
>>
>> Either case, sure, go ahead, and feel free to discuss with the maintainer
>> of that driver if and when to submit the patches for inclusion into the
>> upstream Linux kernel. Going forward, please do not submit patches for
>> inclusion into the upstream Linux kernel if that is not what you want.
>>
>> Thanks,
>> Guenter
>>

Re: [PATCH 1/3] hwmon: (asus_rog_ryujin) Add per-device configuration

[Arimil]

On Sun, Aug 9, 2026 at 9:19 PM Guenter Roeck <linux@roeck-us.net> wrote:
> Please stop top-posting. Then why do you even mention the downstream driver ?
> Its existence and/or status is completely irrelevant for the upstream kernel.
>

Sorry for mentioning something not relevant to the kernel or this series.