linux-kernel - Re: [PATCH v4 1/5] hwmon: it87: describe per-chip temperature resources

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-prev] [day] [month] [year] [list]

Message-ID: <174f13cc-f4a5-4fe4-b0e4-1107c90309b7@roeck-us.net>
Date: Sat, 17 Jan 2026 15:10:32 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Benoit Masson <yahoo@...enite.com>
Cc: Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org,
	linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
	linux-doc@...r.kernel.org
Subject: Re: [PATCH v4 1/5] hwmon: it87: describe per-chip temperature
 resources

On Sat, Jan 17, 2026 at 11:11:32PM +0100, Benoit Masson wrote:
> On Sat, Jan 17, 2026 at 3:39 PM Guenter Roeck <linux@...ck-us.net> wrote:
> > Series applied.
> Guenter, my appologies but after changing some BIOS parameters of the
> IT8613E it seems the patch has something wrong and creates a null
> pointer exception. Can you please remove patch for now until I test
> all BIOS/changes before re-submiting. I'm sorry for the miss here and
> your work pushing for this but prefer to prevent the patch for getting
> deeping in the submission chain.
> 

Does this help ? It is what Gemini had to say about your series.

Guenter

---
My analysis of the top 5 patches in the it87 driver reveals a NULL pointer regression introduced by the series.

  The regression is caused by the addition of the IT8613E chip support in commits 8e6b5dcdb757 and 21506a88d3d5. These commits failed to initialize the .reg_pwm field for the it8613 entry in the it87_devices array.

  Technical Details:
   1. Commit `2fc4e2363316` introduced a new pointer field reg_pwm to struct it87_devices and struct it87_data. It also updated the it87_reg_pwm helper to dereference this pointer:

   1     static inline u16 it87_reg_pwm(const struct it87_data *data, int nr)
   2     {
   3         return data->reg_pwm[nr];
   4     }
   2. Commit `8e6b5dcdb757` added the it8613 entry to the it87_devices array but missed the .reg_pwm initialization (leaving it as NULL).
   3. Commit `21506a88d3d5` further configured the it8613 entry but still did not provide a .reg_pwm value.
   4. Registration Crash: During the probe of an IT8613E chip, it87_probe sets data->reg_pwm = chip->reg_pwm (which is NULL). It then calls it87_check_pwm(dev), which calls it87_reg_pwm(data, i). This result in a NULL pointer dereference
      when attempting to access data->reg_pwm[i].

  Why commit f977d3bf3614 was suspected:
  While commit f977d3bf3614 itself is technically safe (as it only added resource counts which were initialized for all existing chips at the time), it was the first patch in the series that introduced per-chip configuration requirements.
  The user likely associated the crash with this starting point of the series.

  Conclusion:
  The bug is in the it8613 device definition. It must be updated to include .reg_pwm = IT87_REG_PWM (or the appropriate register map for that chip). Additionally, there is a potential out-of-bounds access in it87_update_device because it8613
  defines .num_temp_offset = 6, but the IT87_REG_TEMP_OFFSET array only has 3 elements.