linux-stable.git/drivers/platform, branch v7.2.6 Linux kernel stable tree mlxbf-bootctl: fix the build error with FIELD_PREP() 2026-09-14T11:40:56+00:00 Nikolay Kulikov nikolayof23@gmail.com 2026-08-10T19:10:02+00:00 1058c4379959c9aaecd9ab9b780dfdc604ec985b [ Upstream commit 46b14c6f11f558362391e308f4f184ee867ef58f ] rsh_log_store() calls the FIELD_PREP() macro without including the required header file, resulting a build error: CC drivers/platform/mellanox/mlxbf-bootctl.o drivers/platform/mellanox/mlxbf-bootctl.c: In function ‘rsh_log_store’: drivers/platform/mellanox/mlxbf-bootctl.c:429:16: error: implicit declaration of function ‘FIELD_PREP’ [-Wimplicit-function-declaration] 429 | data = FIELD_PREP(MLXBF_RSH_LOG_TYPE_MASK, MLXBF_RSH_LOG_TYPE_MSG); | ^~~~~~~~~~ Fix this by including the <linux/bitfield.h> file. Fixes: e9d1b2d0f7d0 ("mlxbf-bootctl: Add sysfs file for BlueField boot log") Signed-off-by: Nikolay Kulikov <nikolayof23@gmail.com> Link: https://patch.msgid.link/20260810-mellanox_fix_implicit_declaration-v1-1-352e647b8f28@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 46b14c6f11f558362391e308f4f184ee867ef58f ]

rsh_log_store() calls the FIELD_PREP() macro without including the
required header file, resulting a build error:

  CC      drivers/platform/mellanox/mlxbf-bootctl.o
drivers/platform/mellanox/mlxbf-bootctl.c: In function ‘rsh_log_store’:
drivers/platform/mellanox/mlxbf-bootctl.c:429:16: error: implicit declaration of function ‘FIELD_PREP’ [-Wimplicit-function-declaration]
  429 |         data = FIELD_PREP(MLXBF_RSH_LOG_TYPE_MASK, MLXBF_RSH_LOG_TYPE_MSG);
      |                ^~~~~~~~~~

Fix this by including the <linux/bitfield.h> file.

Fixes: e9d1b2d0f7d0 ("mlxbf-bootctl: Add sysfs file for BlueField boot log")
Signed-off-by: Nikolay Kulikov <nikolayof23@gmail.com>
Link: https://patch.msgid.link/20260810-mellanox_fix_implicit_declaration-v1-1-352e647b8f28@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/x86/amd/hsmp: Reject negative power cap writes in hwmon 2026-09-14T11:40:56+00:00 Hemanth Selam hemanth.selam@gmail.com 2026-08-12T09:00:12+00:00 1b0a3d915320f1600e5ff43f8bc21b73118480b8 [ Upstream commit 3921bb8635ff2836622df1cdf3194d4f3c1835a4 ] hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long and assigns "val / MICROWATT_PER_MILLIWATT" to msg.args[0], which is a __u32. MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write to power1_cap (e.g. "echo -1 > power1_cap") is first converted to a huge unsigned value by the division and then stored into the u32 argument. As a result a nonsensical, multi-gigawatt socket power limit is sent to the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being rejected. Reject negative values with -EINVAL before the conversion. Tested with HSMP enabled: CAP=$(dirname $(grep -l amd_hsmp_hwmon \ /sys/class/hwmon/hwmon*/name | head -1))/power1_cap # negative write echo -1000000 > $CAP ; echo "ret=$?" # valid positive write must still work echo 400000000 > $CAP ; echo "ret=$?" Before: # echo -1000000 > $CAP ; echo "ret=$?" ret=0 <- accepted; bogus limit sent to SMU # echo 400000000 > $CAP ; echo "ret=$?" ret=0 After: # echo -1000000 > $CAP ; echo "ret=$?" bash: echo: write error: Invalid argument ret=1 <- rejected with -EINVAL # echo 400000000 > $CAP ; echo "ret=$?" ret=0 <- valid write still works Fixes: 92c025db52bb ("platform/x86/amd/hsmp: Report power via hwmon sensors") Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Link: https://patch.msgid.link/20260812090012.140193-1-hemanth.selam@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3921bb8635ff2836622df1cdf3194d4f3c1835a4 ]

hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long
and assigns "val / MICROWATT_PER_MILLIWATT" to msg.args[0], which is a
__u32.  MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write
to power1_cap (e.g. "echo -1 > power1_cap") is first converted to a huge
unsigned value by the division and then stored into the u32 argument.

As a result a nonsensical, multi-gigawatt socket power limit is sent to
the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being
rejected.

Reject negative values with -EINVAL before the conversion.

Tested with HSMP enabled:

  CAP=$(dirname $(grep -l amd_hsmp_hwmon \
        /sys/class/hwmon/hwmon*/name | head -1))/power1_cap

  # negative write
  echo -1000000 > $CAP ; echo "ret=$?"
  # valid positive write must still work
  echo 400000000 > $CAP ; echo "ret=$?"

Before:
  # echo -1000000 > $CAP ; echo "ret=$?"
  ret=0                             <- accepted; bogus limit sent to SMU
  # echo 400000000 > $CAP ; echo "ret=$?"
  ret=0

After:
  # echo -1000000 > $CAP ; echo "ret=$?"
  bash: echo: write error: Invalid argument
  ret=1                             <- rejected with -EINVAL
  # echo 400000000 > $CAP ; echo "ret=$?"
  ret=0                             <- valid write still works

Fixes: 92c025db52bb ("platform/x86/amd/hsmp: Report power via hwmon sensors")
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260812090012.140193-1-hemanth.selam@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/x86: hp-bioscfg: fix password encoding bounds check 2026-09-14T11:40:55+00:00 Guangshuo Li lgs201920130244@gmail.com 2026-07-08T09:09:37+00:00 8a7499b8fd34438c1b11964e0e7ef5bd590fec92 [ Upstream commit e213939ed9e6e6badf7aa48c4c8dd9a9cdf00615 ] The password PSWD_ENCODINGS parser reads password_obj[elem + pos_values] while copying the supported password encodings from the ACPI package. The outer loop only guarantees that elem is within password_obj_count. The encoding count is bounded by MAX_ENCODINGS_SIZE, but that does not guarantee that the ACPI package contains enough entries for all elem + pos_values accesses. A malformed package can therefore declare a non-zero encoding count without providing enough string objects, causing the parser to read past the ACPI package array and pass an out-of-bounds string pointer and length to hp_convert_hexstr_to_str(). Add the same computed-index bounds check used by the other offset-based package parsing loops before reading password_obj[elem + pos_values]. Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Link: https://patch.msgid.link/20260708090937.740435-1-lgs201920130244@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e213939ed9e6e6badf7aa48c4c8dd9a9cdf00615 ]

The password PSWD_ENCODINGS parser reads password_obj[elem + pos_values]
while copying the supported password encodings from the ACPI package.

The outer loop only guarantees that elem is within password_obj_count.
The encoding count is bounded by MAX_ENCODINGS_SIZE, but that does not
guarantee that the ACPI package contains enough entries for all
elem + pos_values accesses.

A malformed package can therefore declare a non-zero encoding count
without providing enough string objects, causing the parser to read past
the ACPI package array and pass an out-of-bounds string pointer and
length to hp_convert_hexstr_to_str().

Add the same computed-index bounds check used by the other offset-based
package parsing loops before reading password_obj[elem + pos_values].

Fixes: 8646a3b5ee3a ("platform/x86: hp-bioscfg: passwdobj-attributes")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Link: https://patch.msgid.link/20260708090937.740435-1-lgs201920130244@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/x86: dell-wmi-sysman: Fix instance ID bounds 2026-09-14T11:40:55+00:00 HyeongJun An sammiee5311@gmail.com 2026-08-14T13:25:35+00:00 cfcc833cb43b49edfae80803b3d86fb4f00d8694 [ Upstream commit 5ab078e3241da0beec2022254b5811a8a52cff84 ] The get_instance_id() macro walks the per-type attribute array with 'i <= instances_count'. Each array is allocated with exactly instances_count entries, so the valid range is [0, instances_count) and the last iteration reads one element past the end. On a name miss that out-of-bounds attribute_name is handed to strcmp(), which reads on until it finds a NUL byte. Every kobject in these ksets is built from an entry that was populated, so a miss does not look reachable from sysfs today. The bound is wrong either way and the read is out of bounds. The matching macro in hp-bioscfg carried the same off-by-one and was corrected by commit 25150715e0b0 ("platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro"). That macro takes a kobject pointer out of the out-of-bounds element and dereferences it, so it could fault. This one reads a char array. Use '<' to match the allocation. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Link: https://patch.msgid.link/20260814132535.4169956-1-sammiee5311@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 5ab078e3241da0beec2022254b5811a8a52cff84 ]

The get_instance_id() macro walks the per-type attribute array with
'i <= instances_count'.  Each array is allocated with exactly
instances_count entries, so the valid range is [0, instances_count)
and the last iteration reads one element past the end.  On a name miss
that out-of-bounds attribute_name is handed to strcmp(), which reads on
until it finds a NUL byte.

Every kobject in these ksets is built from an entry that was populated,
so a miss does not look reachable from sysfs today.  The bound is wrong
either way and the read is out of bounds.

The matching macro in hp-bioscfg carried the same off-by-one and was
corrected by commit 25150715e0b0 ("platform/x86: hp-bioscfg: Fix kernel
panic in GET_INSTANCE_ID macro").  That macro takes a kobject pointer
out of the out-of-bounds element and dereferences it, so it could fault.
This one reads a char array.

Use '<' to match the allocation.

Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Assisted-by: Claude:claude-opus-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260814132535.4169956-1-sammiee5311@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform: arm64: qcom-hamoa-ec: reject incomplete responses 2026-09-14T11:40:13+00:00 Linmao Li lilinmao@kylinos.cn 2026-07-28T11:19:24+00:00 5aed69e20fd3d4b4129d0f2f81c5631eaa6bfc87 [ Upstream commit 1b04f556e8428a3865a95627ab7a0acb5d9b93a5 ] qcom_ec_read() accepts short positive transfers, while both callers unconditionally consume every field in their fixed-size response. A short transfer can therefore make them use trailing stack bytes that were not returned by the device. The first response byte contains the number of payload bytes, excluding the byte count itself. A complete response of resp_len bytes must therefore report resp_len - 1 payload bytes. The existing check only rejects counts that do not fit in the response buffer and still accepts an incomplete payload. Require both the SMBus transfer length and the EC-provided payload count to match the expected response size. Fixes: 5c44f48e91de ("platform: arm64: Add driver for EC found on Qualcomm reference devices") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com> Link: https://patch.msgid.link/20260728111924.4106898-1-lilinmao@kylinos.cn Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 1b04f556e8428a3865a95627ab7a0acb5d9b93a5 ]

qcom_ec_read() accepts short positive transfers, while both callers
unconditionally consume every field in their fixed-size response. A short
transfer can therefore make them use trailing stack bytes that were not
returned by the device.

The first response byte contains the number of payload bytes, excluding
the byte count itself. A complete response of resp_len bytes must
therefore report resp_len - 1 payload bytes. The existing check only
rejects counts that do not fit in the response buffer and still accepts
an incomplete payload.

Require both the SMBus transfer length and the EC-provided payload count
to match the expected response size.

Fixes: 5c44f48e91de ("platform: arm64: Add driver for EC found on Qualcomm reference devices")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Link: https://patch.msgid.link/20260728111924.4106898-1-lilinmao@kylinos.cn
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/chrome: lightbar: Limit payload to max packet size 2026-09-14T11:40:00+00:00 Alexis Savery asavery@google.com 2026-07-30T20:42:40+00:00 65e7240d679fe73297666718d9926dbc8508d44a [ Upstream commit ed1d1f519c56c6c2ffa13f3d52cd77beb023db13 ] The LIGHTBAR_CMD_SET_PROGRAM command uses an 8-bit size field for its payload length, but the protocol-negotiated `max_request` may exceed the maximum value an 8-bit integer can represent. When this occurs, large payloads (e.g., >255 bytes) integer wrap the 8-bit size variable when assigning `param->set_program_ex.size`, causing truncation and parse failures downstream in the EC firmware stack. Clamp `max_size` to the maximum value the structural size field can support. Fixes: 9600b8bdbfe4 ("platform/chrome: lightbar: Add support for large sequence") Signed-off-by: Alexis Savery <asavery@google.com> Link: https://lore.kernel.org/r/20260730204240.2227178-1-asavery@google.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ed1d1f519c56c6c2ffa13f3d52cd77beb023db13 ]

The LIGHTBAR_CMD_SET_PROGRAM command uses an 8-bit size field for its
payload length, but the protocol-negotiated `max_request` may exceed
the maximum value an 8-bit integer can represent.

When this occurs, large payloads (e.g., >255 bytes) integer wrap the
8-bit size variable when assigning `param->set_program_ex.size`, causing
truncation and parse failures downstream in the EC firmware stack.

Clamp `max_size` to the maximum value the structural size field can
support.

Fixes: 9600b8bdbfe4 ("platform/chrome: lightbar: Add support for large sequence")
Signed-off-by: Alexis Savery <asavery@google.com>
Link: https://lore.kernel.org/r/20260730204240.2227178-1-asavery@google.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/chrome: cros_ec_debugfs: Unregister panic notifier 2026-09-14T11:39:55+00:00 Hongyan Xu getshell@seu.edu.cn 2026-07-29T10:32:17+00:00 05c1081ae4503e45b934b390350f942db3208892 [ Upstream commit e5954d3031fb55dd31aa59bae477d63c68e941c0 ] cros_ec_debugfs_probe() registers notifier_panic with the EC panic notifier chain. The remove path tears down debugfs and the console log, but leaves the notifier registered. A later panic notification can call back into the removed instance and queue work that accesses released data. Unregister the panic notifier before tearing down the debugfs and console log state. This issue was found by a static analysis tool. Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic") Signed-off-by: Hongyan Xu <getshell@seu.edu.cn> Link: https://lore.kernel.org/r/f3ab74ef8034be63bb45a325f3d54656d658817f.1785320940.git.getshell@seu.edu.cn Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e5954d3031fb55dd31aa59bae477d63c68e941c0 ]

cros_ec_debugfs_probe() registers notifier_panic with the EC panic
notifier chain. The remove path tears down debugfs and the console log,
but leaves the notifier registered. A later panic notification can call
back into the removed instance and queue work that accesses released
data.

Unregister the panic notifier before tearing down the debugfs and
console log state.

This issue was found by a static analysis tool.

Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic")
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
Link: https://lore.kernel.org/r/f3ab74ef8034be63bb45a325f3d54656d658817f.1785320940.git.getshell@seu.edu.cn
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/chrome: cros_ec_debugfs: Clean up console log on probe failure 2026-09-14T11:39:55+00:00 Hongyan Xu getshell@seu.edu.cn 2026-07-29T10:32:16+00:00 e97d1fce7173f0ebbbfa618265821071a4714ca6 [ Upstream commit 5d187600c4603b8f7812b12ce359a11ad7a7fd3a ] Add a dedicated error label for failures after successful console log setup. Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic") Signed-off-by: Hongyan Xu <getshell@seu.edu.cn> Link: https://lore.kernel.org/r/c00974953a1b952f51f0f021d7f9fad134159909.1785320940.git.getshell@seu.edu.cn Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 5d187600c4603b8f7812b12ce359a11ad7a7fd3a ]

Add a dedicated error label for failures after successful console log
setup.

Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic")
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
Link: https://lore.kernel.org/r/c00974953a1b952f51f0f021d7f9fad134159909.1785320940.git.getshell@seu.edu.cn
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/x86: acer-wmi: reject missing gaming WMI results 2026-09-14T11:39:41+00:00 Yousef Alhouseen alhouseenyousef@gmail.com 2026-07-01T16:42:04+00:00 27a3be4e965bfac88e35dd17ec3097a6f5ee637e [ Upstream commit caf8342512c3056005f475d350eeca089c3c6623 ] WMI_gaming_execute_u32_u64() returns success when firmware supplies no output object, leaving the caller output untouched. Gaming getters then inspect an uninitialized result value. When the caller requests an output value, return -ENOMSG if firmware supplies no object. Preserve a NULL output pointer as the supported way for callers to ignore the result. Fixes: 2d76708c2221 ("platform/x86: acer-wmi: use WMI calls for platform profile handling") Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com> Link: https://patch.msgid.link/20260701164208.8998-1-alhouseenyousef@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit caf8342512c3056005f475d350eeca089c3c6623 ]

WMI_gaming_execute_u32_u64() returns success when firmware supplies
no output object, leaving the caller output untouched. Gaming getters
then inspect an uninitialized result value.

When the caller requests an output value, return -ENOMSG if firmware
supplies no object. Preserve a NULL output pointer as the supported way
for callers to ignore the result.

Fixes: 2d76708c2221 ("platform/x86: acer-wmi: use WMI calls for platform profile handling")
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
Link: https://patch.msgid.link/20260701164208.8998-1-alhouseenyousef@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
platform/surface: acpi-notify: Check ACPI companion before use 2026-09-14T11:39:24+00:00 Linmao Li lilinmao@kylinos.cn 2026-07-06T01:25:11+00:00 428a82d987fcd8844e8868c85582eae75b4b5c51 [ Upstream commit 2b3a5dabe89e330413af403246b648c1890f368f ] Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of device_match_driver_override(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence. san_probe() dereferences the result of ACPI_COMPANION() when installing the GSBUS address space handler, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. The dereference was introduced when the probe function was switched from ACPI_HANDLE() to ACPI_COMPANION(). Check the ACPI companion against NULL and return -ENODEV when it is missing, like commit e4865a56d013 ("ACPI: driver: Check ACPI_COMPANION() against NULL during probe") does for the core ACPI platform drivers. Fixes: a9e10e587304 ("ACPI: scan: Extend acpi_walk_dep_device_list()") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Link: https://patch.msgid.link/20260706012512.524359-2-lilinmao@kylinos.cn Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 2b3a5dabe89e330413af403246b648c1890f368f ]

Since every platform driver can be forced to match a device that doesn't
match its list of device IDs because of device_match_driver_override(),
platform drivers that rely on the existence of a device's ACPI companion
object should verify its presence.

san_probe() dereferences the result of ACPI_COMPANION() when installing
the GSBUS address space handler, so force-binding the driver to a device
without an ACPI companion leads to a NULL pointer dereference.  The
dereference was introduced when the probe function was switched from
ACPI_HANDLE() to ACPI_COMPANION().

Check the ACPI companion against NULL and return -ENODEV when it is
missing, like commit e4865a56d013 ("ACPI: driver: Check ACPI_COMPANION()
against NULL during probe") does for the core ACPI platform drivers.

Fixes: a9e10e587304 ("ACPI: scan: Extend acpi_walk_dep_device_list()")
Signed-off-by: Linmao Li <lilinmao@kylinos.cn>
Link: https://patch.msgid.link/20260706012512.524359-2-lilinmao@kylinos.cn
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>