kernel/git/stable/linux-stable.git/drivers/platform, branch linux-5.15.y

platform/x86: dell-wmi-sysman: Fix instance ID bounds

2026-09-14T11:20:49+00:00

[ 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 Link: https://patch.msgid.link/20260814132535.4169956-1-sammiee5311@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin

platform/surface: acpi-notify: Check ACPI companion before use

2026-09-14T11:20:29+00:00

[ 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 Link: https://patch.msgid.link/20260706012512.524359-2-lilinmao@kylinos.cn Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin

platform/mellanox: mlxbf-pmc: Check ACPI_COMPANION() against NULL

2026-09-14T11:20:29+00:00

[ Upstream commit c38cce70adef874c2a7b5132c14d6c221401deff ] 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(), so platform drivers that rely on the existence of a device's ACPI companion object need to verify its presence. mlxbf_pmc_probe() passes the result of ACPI_COMPANION() to acpi_device_hid(), which dereferences it, so force-binding the driver to a device without an ACPI companion leads to a NULL pointer dereference. Accordingly, add a requisite ACPI_COMPANION() check against NULL to the mlxbf-pmc driver and return -ENODEV when the companion is missing. Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Signed-off-by: Linmao Li Link: https://patch.msgid.link/20260706012056.524096-1-lilinmao@kylinos.cn Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin

platform/x86: dell-wmi-base: Fix resource leak on module load failure

2026-09-14T11:20:29+00:00

[ Upstream commit 072841e02cf9c00a7e8a9c567a14239e02ca47ad ] We need to properly clean up the SMBIOS request and the privacy driver when the module load fails. Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260612173451.467629-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin

platform/x86: dell-privacy: Fix race condition

2026-09-14T11:20:29+00:00

[ Upstream commit ca9338dbc64759b30741b12017c050b33c94dfa2 ] Accessing priv->features_present needs to happen with the list mutex being held, otherwise priv can be freed at any moment. Fixes: 8af9fa37b8a3 ("platform/x86: dell-privacy: Add support for Dell hardware privacy") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260612173451.467629-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin

platform/chrome: sensorhub: Fix memory overread in ring handler

2026-09-14T11:20:26+00:00

[ Upstream commit d1ceb2b2324717fa30b44d56ef0c52813e239569 ] `max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length. Fixes: 145d59baff59 ("platform/chrome: cros_ec_sensorhub: Add FIFO support") Reviewed-by: Tomasz Figa Link: https://lore.kernel.org/r/20260702082745.1014968-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih Signed-off-by: Sasha Levin

platform/chrome: sensorhub: Fix dropped timestamp events and log spam

2026-09-14T11:20:15+00:00

commit 9a3f43b30373c61477d0d3ab52946c05f9492bf9 upstream. Commit 833740a2333c ("platform/chrome: sensorhub: Bound the EC-reported sensor number") evaluated the `sensor_num` against the bounds limit even for timestamp events. A timestamp event typically has a `sensor_num` of 0xff [1], causing the driver to flag it as invalid and skip to the next event. As a result, we'd see a flooding of "Invalid sensor number 255 from EC" warning logs and these timestamp events were being dropped. Move the bounds-check into cros_ec_sensor_ring_process_event() and evaluate it only after standalone timestamp events have already been processed and returned early. [1] https://crrev.com/219ca6ef82ba266da788b673ee4ad50bd3ea1285/common/motion_sense_fifo.c#427 Fixes: 833740a2333c ("platform/chrome: sensorhub: Bound the EC-reported sensor number") Reviewed-by: Tomasz Figa Link: https://lore.kernel.org/r/20260715024454.4127571-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih Signed-off-by: Greg Kroah-Hartman

platform/chrome: sensorhub: Bound the EC-reported sensor number

2026-09-14T11:20:12+00:00

commit 833740a2333c2e4db4e02e3d0ffba04e8718a5f3 upstream. Each EC FIFO event carries an 8-bit sensor number (in->sensor_num). cros_ec_sensorhub_ring_handler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which cros_ec_sensor_ring_process_event() then uses unchecked to index sensorhub->batch_state[] - allocated with only sensorhub->sensor_num entries. A sensor number of sensor_num or larger is an out-of-bounds read and write of batch_state[]. Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used. Fixes: 145d59baff59 ("platform/chrome: cros_ec_sensorhub: Add FIFO support") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://lore.kernel.org/r/20260618-b4-disp-adb3f790-v3-1-3a164ed63cbd@proton.me Signed-off-by: Tzung-Bi Shih Signed-off-by: Greg Kroah-Hartman

platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer

2026-09-14T11:20:12+00:00

commit 83c80495e45eddf64c6525fb582d8db68f256b71 upstream. set_attribute() populates the security area of the BIOS attribute request buffer with the current admin password via populate_security_buffer(), then dumps the whole request buffer with print_hex_dump_bytes(). This can expose the plaintext admin password in the kernel log. The same issue was fixed for the password attribute path by commit d1a196e0a6dc ("platform/x86: dell-wmi-sysman: Don't hex dump plaintext password data"). Remove the remaining dump from the BIOS attribute path. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5 Signed-off-by: HyeongJun An Link: https://patch.msgid.link/20260614045353.143500-1-sammiee5311@gmail.com Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman

platform/x86: xo15-ebook: Fix wakeup source and GPE handling

2026-07-24T13:51:37+00:00

[ Upstream commit b2fc2c6ebbd2d49935c8960755d8170faead2159 ] The device_set_wakeup_enable() call in ebook_switch_add() doesn't actually do anything because power.can_wakeup is not set for ACPI device objects. Moreover, had it done anything, it would have registered a wakeup source object that wouldn't have been used going forward and that wakeup source would have been leaked after driver removal because ebook_switch_remove() doesn't clean it up. Accordingly, remove that call from ebook_switch_add(). Also prevent leaking an enabled ACPI GPE after removing the driver by adding appropriate cleanup code to ebook_switch_remove(). Fixes: 89ca11771a4b ("OLPC XO-1.5 ebook switch driver") Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/1966125.tdWV9SEqCh@rafael.j.wysocki Reviewed-by: Ilpo Järvinen Signed-off-by: Ilpo Järvinen Signed-off-by: Sasha Levin