linux-stable.git/drivers/platform/chrome, branch linux-5.4.y

platform/chrome: cros_ec_debugfs: fix wrong EC message version

2024-08-19T03:33:25+00:00

[ Upstream commit c2a28647bbb4e0894e8824362410f72b06ac57a4 ]

ec_read_version_supported() uses ec_params_get_cmd_versions_v1 but it
wrongly uses message version 0.

Fix it.

Fixes: e86264595225 ("mfd: cros_ec: add debugfs, console log file")
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20240611113110.16955-1-tzungbi@kernel.org
Signed-off-by: Tzung-Bi Shih 
Signed-off-by: Sasha Levin

platform/chrome: cros_ec_chardev: fix kernel data leak from ioctl

2023-04-05T09:16:38+00:00

[ Upstream commit b20cf3f89c56b5f6a38b7f76a8128bf9f291bbd3 ]

It is possible to peep kernel page's data by providing larger `insize`
in struct cros_ec_command[1] when invoking EC host commands.

Fix it by using zeroed memory.

[1]: https://elixir.bootlin.com/linux/v6.2/source/include/linux/platform_data/cros_ec_proto.h#L74

Fixes: eda2e30c6684 ("mfd / platform: cros_ec: Miscellaneous character device to talk with the EC")
Signed-off-by: Tzung-Bi Shih 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20230324010658.1082361-1-tzungbi@kernel.org
Signed-off-by: Sasha Levin

platform/chrome: fix memory corruption in ioctl

2022-10-26T11:22:28+00:00

[ Upstream commit 8a07b45fd3c2dda24fad43639be5335a4595196a ]

If "s_mem.bytes" is larger than the buffer size it leads to memory
corruption.

Fixes: eda2e30c6684 ("mfd / platform: cros_ec: Miscellaneous character device to talk with the EC")
Signed-off-by: Dan Carpenter 
Reviewed-by: Guenter Roeck 
Signed-off-by: Tzung-Bi Shih 
Link: https://lore.kernel.org/r/Yv8dpCFZJdbUT5ye@kili
Signed-off-by: Sasha Levin

platform/chrome: fix double-free in chromeos_laptop_prepare()

2022-10-26T11:22:28+00:00

[ Upstream commit 6ad4194d6a1e1d11b285989cd648ef695b4a93c0 ]

If chromeos_laptop_prepare_i2c_peripherals() fails after allocating memory
for 'cros_laptop->i2c_peripherals', this memory is freed at 'err_out' label
and nonzero value is returned. Then chromeos_laptop_destroy() is called,
resulting in double-free error.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Rustam Subkhankulov 
Fixes: 5020cd29d8bf ("platform/chrome: chromeos_laptop - supply properties for ACPI devices")
Reviewed-by: Dmitry Torokhov 
Signed-off-by: Tzung-Bi Shih 
Link: https://lore.kernel.org/r/20220813220843.2373004-1-subkhankulov@ispras.ru
Signed-off-by: Sasha Levin

platform/chrome: cros_ec_debugfs: detach log reader wq from devm

2022-05-25T07:14:33+00:00

[ Upstream commit 0e8eb5e8acbad19ac2e1856b2fb2320184299b33 ]

Debugfs console_log uses devm memory (e.g. debug_info in
cros_ec_console_log_poll()).  However, lifecycles of device and debugfs
are independent.  An use-after-free issue is observed if userland
program operates the debugfs after the memory has been freed.

The call trace:
 do_raw_spin_lock
 _raw_spin_lock_irqsave
 remove_wait_queue
 ep_unregister_pollwait
 ep_remove
 do_epoll_ctl

A Python example to reproduce the issue:
... import select
... p = select.epoll()
... f = open('/sys/kernel/debug/cros_scp/console_log')
... p.register(f, select.POLLIN)
... p.poll(1)
[(4, 1)]                    # 4=fd, 1=select.POLLIN

[ shutdown cros_scp at the point ]

... p.poll(1)
[(4, 16)]                   # 4=fd, 16=select.POLLHUP
... p.unregister(f)

An use-after-free issue raises here.  It called epoll_ctl with
EPOLL_CTL_DEL which in turn to use the workqueue in the devm (i.e.
log_wq).

Detaches log reader's workqueue from devm to make sure it is persistent
even if the device has been removed.

Signed-off-by: Tzung-Bi Shih 
Reviewed-by: Guenter Roeck 
Link: https://lore.kernel.org/r/20220209051130.386175-1-tzungbi@google.com
Signed-off-by: Benson Leung 
Signed-off-by: Sasha Levin

platform/chrome: cros_ec_proto: Send command again when timeout occurs

2021-09-22T10:26:38+00:00

commit 3abc16af57c9939724df92fcbda296b25cc95168 upstream.

Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it
hasn't initialized SPI yet. This can happen because FPMCU is restarted
during system boot and kernel can send message in short window
eg. between sysjump to RW and SPI initialization.

Cc:  # 4.4+
Signed-off-by: Patryk Duda 
Link: https://lore.kernel.org/r/20210518140758.29318-1-pdk@semihalf.com
Signed-off-by: Benson Leung 
Signed-off-by: Greg Kroah-Hartman

platform/chrome: cros_ec_spi: Don't overwrite spi::mode

2020-12-30T10:51:23+00:00

[ Upstream commit 74639cbf51d7c0304342544a83dfda354a6bd208 ]

There isn't any need to overwrite the mode here in the driver with what
has been detected by the firmware, such as DT or ACPI. In fact, if we
use the SPI CS gpio descriptor feature we will overwrite the mode with
SPI_MODE_0 where it already contains SPI_MODE_0 and more importantly
SPI_CS_HIGH. Clearing the SPI_CS_HIGH bit causes the CS line to toggle
when the device is probed when it shouldn't change, confusing the driver
and making it fail to probe. Drop the assignment and let the spi core
take care of it.

Fixes: a17d94f0b6e1 ("mfd: Add ChromeOS EC SPI driver")
Cc: Simon Glass 
Cc: Gwendal Grignou 
Reviewed-by: Douglas Anderson 
Tested-by: Douglas Anderson 
Acked-by: Enric Balletbo i Serra 
Cc: Alexandru M Stan 
Signed-off-by: Stephen Boyd 
Reviewed-by: Simon Glass 
Link: https://lore.kernel.org/r/20201204193540.3047030-2-swboyd@chromium.org
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

platform/chrome: cros_ec_ishtp: Fix a double-unlock issue

2020-08-21T11:05:30+00:00

[ Upstream commit aaa3cbbac326c95308e315f1ab964a3369c4d07d ]

In function cros_ec_ishtp_probe(), "up_write" is already called
before function "cros_ec_dev_init". But "up_write" will be called
again after the calling of the function "cros_ec_dev_init" failed.
Thus add a call of the function “down_write” in this if branch
for the completion of the exception handling.

Fixes: 26a14267aff2 ("platform/chrome: Add ChromeOS EC ISHTP driver")
Signed-off-by: Qiushi Wu 
Tested-by: Mathew King 
Signed-off-by: Enric Balletbo i Serra 
Signed-off-by: Sasha Levin

platform/chrome: cros_ec_rpmsg: Fix race with host event

2020-04-21T07:04:51+00:00

commit f775ac78fcfc6bdc96bdda07029d11f2a5e84869 upstream.

Host event can be sent by remoteproc by any time, and
cros_ec_rpmsg_callback would be called after cros_ec_rpmsg_create_ept.
But the cros_ec_device is initialized after that, which cause host event
handler to use cros_ec_device that are not initialized properly yet.

Fix this by don't schedule host event handler before cros_ec_register
returns. Instead, remember that we have a pending host event, and
schedule host event handler after cros_ec_register.

Fixes: 71cddb7097e2 ("platform/chrome: cros_ec_rpmsg: Fix race with host command when probe failed.")
Signed-off-by: Pi-Hsun Shih 
Signed-off-by: Enric Balletbo i Serra 
Signed-off-by: Greg Kroah-Hartman

platform/chrome: wilco_ec: fix use after free issue

2020-01-26T09:01:08+00:00

[ Upstream commit 856a0a6e2d09d31fd8f00cc1fc6645196a509d56 ]

This is caused by dereferencing 'dev_data' after put_device() in
the telem_device_remove() function.
This patch just moves the put_device() down a bit to avoid this
issue.

Fixes: 1210d1e6bad1 ("platform/chrome: wilco_ec: Add telemetry char device interface")
Signed-off-by: Wen Yang 
Cc: Benson Leung 
Cc: Enric Balletbo i Serra 
Cc: Nick Crews 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Enric Balletbo i Serra 
Signed-off-by: Sasha Levin