| Message ID | 20241128154212.6216-1-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [1/4] platform/x86: int3472: Check for adev == NULL | expand |
On Thu, Nov 28, 2024 at 04:42:09PM +0100, Hans de Goede wrote: > Not all devices have an ACPI companion fwnode, so adev might be NULL. This > can e.g. (theoretically) happen when a user manually binds one of > the int3472 drivers to another i2c/platform device through sysfs. > > Add a check for adev not being set and return -ENODEV in that case. But what kind of "bad thing" can happen in such cases? If none, why this change?
Hi, On 28-Nov-24 4:51 PM, Andy Shevchenko wrote: > On Thu, Nov 28, 2024 at 04:42:09PM +0100, Hans de Goede wrote: >> Not all devices have an ACPI companion fwnode, so adev might be NULL. This >> can e.g. (theoretically) happen when a user manually binds one of >> the int3472 drivers to another i2c/platform device through sysfs. >> >> Add a check for adev not being set and return -ENODEV in that case. > > But what kind of "bad thing" can happen in such cases? NULL pointer deref oops in skl_int3472_get_acpi_buffer() during probe() when it tries to get adev->handle. I guess for v2 you want me to reword the second paragraph of the commit message to e.g. : Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer(). ? Regards, Hans
On Wed, Dec 4, 2024 at 7:40 PM Hans de Goede <hdegoede@redhat.com> wrote: > On 28-Nov-24 4:51 PM, Andy Shevchenko wrote: > > On Thu, Nov 28, 2024 at 04:42:09PM +0100, Hans de Goede wrote: > >> Not all devices have an ACPI companion fwnode, so adev might be NULL. This > >> can e.g. (theoretically) happen when a user manually binds one of > >> the int3472 drivers to another i2c/platform device through sysfs. > >> > >> Add a check for adev not being set and return -ENODEV in that case. > > > > But what kind of "bad thing" can happen in such cases? > > NULL pointer deref oops in skl_int3472_get_acpi_buffer() during > probe() when it tries to get adev->handle. > > I guess for v2 you want me to reword the second paragraph of the commit > message to e.g. : > > Add a check for adev not being set and return -ENODEV in that case to > avoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer(). > > ? I don't remember, but it sounds good to me.
diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c index 3de463c3d13b..15678508ee50 100644 --- a/drivers/platform/x86/intel/int3472/discrete.c +++ b/drivers/platform/x86/intel/int3472/discrete.c @@ -336,6 +336,9 @@ static int skl_int3472_discrete_probe(struct platform_device *pdev) struct int3472_cldb cldb; int ret; + if (!adev) + return -ENODEV; + ret = skl_int3472_fill_cldb(adev, &cldb); if (ret) { dev_err(&pdev->dev, "Couldn't fill CLDB structure\n"); diff --git a/drivers/platform/x86/intel/int3472/tps68470.c b/drivers/platform/x86/intel/int3472/tps68470.c index 1e107fd49f82..81ac4c691963 100644 --- a/drivers/platform/x86/intel/int3472/tps68470.c +++ b/drivers/platform/x86/intel/int3472/tps68470.c @@ -152,6 +152,9 @@ static int skl_int3472_tps68470_probe(struct i2c_client *client) int ret; int i; + if (!adev) + return -ENODEV; + n_consumers = skl_int3472_fill_clk_pdata(&client->dev, &clk_pdata); if (n_consumers < 0) return n_consumers;
Not all devices have an ACPI companion fwnode, so adev might be NULL. This can e.g. (theoretically) happen when a user manually binds one of the int3472 drivers to another i2c/platform device through sysfs. Add a check for adev not being set and return -ENODEV in that case. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/platform/x86/intel/int3472/discrete.c | 3 +++ drivers/platform/x86/intel/int3472/tps68470.c | 3 +++ 2 files changed, 6 insertions(+)