linux-stable.git/drivers/acpi, branch v4.4.271

ACPI: custom_method: fix a possible memory leak

2021-05-22T08:38:16+00:00

commit 1cfd8956437f842836e8a066b40d1ec2fc01f13e upstream.

In cm_write(), if the 'buf' is allocated memory but not fully consumed,
it is possible to reallocate the buffer without freeing it by passing
'*ppos' as 0 on a subsequent call.

Add an explicit kfree() before kzalloc() to prevent the possible memory
leak.

Fixes: 526b4af47f44 ("ACPI: Split out custom_method functionality into an own driver")
Signed-off-by: Mark Langsdorf 
Cc: 5.4+  # 5.4+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: custom_method: fix potential use-after-free issue

2021-05-22T08:38:16+00:00

commit e483bb9a991bdae29a0caa4b3a6d002c968f94aa upstream.

In cm_write(), buf is always freed when reaching the end of the
function.  If the requested count is less than table.length, the
allocated buffer will be freed but subsequent calls to cm_write() will
still try to access it.

Remove the unconditional kfree(buf) at the end of the function and
set the buf to NULL in the -EINVAL error path to match the rest of
function.

Fixes: 03d1571d9513 ("ACPI: custom_method: fix memory leaks")
Signed-off-by: Mark Langsdorf 
Cc: 5.4+  # 5.4+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: thermal: Do not call acpi_thermal_check() directly

2021-02-10T08:07:28+00:00

commit 81b704d3e4674e09781d331df73d76675d5ad8cb upstream.

Calling acpi_thermal_check() from acpi_thermal_notify() directly
is problematic if _TMP triggers Notify () on the thermal zone for
which it has been evaluated (which happens on some systems), because
it causes a new acpi_thermal_notify() invocation to be queued up
every time and if that takes place too often, an indefinite number of
pending work items may accumulate in kacpi_notify_wq over time.

Besides, it is not really useful to queue up a new invocation of
acpi_thermal_check() if one of them is pending already.

For these reasons, rework acpi_thermal_notify() to queue up a thermal
check instead of calling acpi_thermal_check() directly and only allow
one thermal check to be pending at a time.  Moreover, only allow one
acpi_thermal_check_fn() instance at a time to run
thermal_zone_device_update() for one thermal zone and make it return
early if it sees other instances running for the same thermal zone.

While at it, fold acpi_thermal_check() into acpi_thermal_check_fn(),
as it is only called from there after the other changes made here.

[This issue appears to have been exposed by commit 6d25be5782e4
 ("sched/core, workqueues: Distangle worker accounting from rq
 lock"), but it is unclear why it was not visible earlier.]

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=208877
Reported-by: Stephen Berman 
Diagnosed-by: Sebastian Andrzej Siewior 
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Sebastian Andrzej Siewior 
Tested-by: Stephen Berman 
Cc: All applicable 
[bigeasy: Backported to v4.4.y, use atomic_t instead of refcount_t]
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman

ACPI: sysfs: Prefer "compatible" modalias

2021-02-03T22:16:15+00:00

commit 36af2d5c4433fb40ee2af912c4ac0a30991aecfc upstream.

Commit 8765c5ba1949 ("ACPI / scan: Rework modalias creation when
"compatible" is present") may create two "MODALIAS=" in one uevent
file if specific conditions are met.

This breaks systemd-udevd, which assumes each "key" in one uevent file
to be unique. The internal implementation of systemd-udevd overwrites
the first MODALIAS with the second one, so its kmod rule doesn't load
the driver for the first MODALIAS.

So if both the ACPI modalias and the OF modalias are present, use the
latter to ensure that there will be only one MODALIAS.

Link: https://github.com/systemd/systemd/pull/18163
Suggested-by: Mika Westerberg 
Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present")
Signed-off-by: Kai-Heng Feng 
Reviewed-by: Mika Westerberg 
Reviewed-by: Greg Kroah-Hartman 
Cc: 4.1+  # 4.1+
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: scan: Make acpi_bus_get_device() clear return pointer on error

2021-01-30T12:25:54+00:00

commit 78a18fec5258c8df9435399a1ea022d73d3eceb9 upstream.

Set the acpi_device pointer which acpi_bus_get_device() returns-by-
reference to NULL on errors.

We've recently had 2 cases where callers of acpi_bus_get_device()
did not properly error check the return value, so set the returned-
by-reference acpi_device pointer to NULL, because at least some
callers of acpi_bus_get_device() expect that to be done on errors.

[ rjw: This issue was exposed by commit 71da201f38df ("ACPI: scan:
  Defer enumeration of devices with _DEP lists") which caused it to
  be much more likely to occur on some systems, but the real defect
  had been introduced by an earlier commit. ]

Fixes: 40e7fcb19293 ("ACPI: Add _DEP support to fix battery issue on Asus T100TA")
Fixes: bcfcd409d4db ("usb: split code locating ACPI companion into port and device")
Reported-by: Pierre-Louis Bossart 
Tested-by: Pierre-Louis Bossart 
Diagnosed-by: Rafael J. Wysocki 
Signed-off-by: Hans de Goede 
Cc: All applicable 
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: PNP: compare the string length in the matching_id()

2020-12-29T12:42:42+00:00

commit b08221c40febcbda9309dd70c61cf1b0ebb0e351 upstream.

Recently we met a touchscreen problem on some Thinkpad machines, the
touchscreen driver (i2c-hid) is not loaded and the touchscreen can't
work.

An i2c ACPI device with the name WACF2200 is defined in the BIOS, with
the current rule in matching_id(), this device will be regarded as
a PNP device since there is WACFXXX in the acpi_pnp_device_ids[] and
this PNP device is attached to the acpi device as the 1st
physical_node, this will make the i2c bus match fail when i2c bus
calls acpi_companion_match() to match the acpi_id_table in the i2c-hid
driver.

WACF2200 is an i2c device instead of a PNP device, after adding the
string length comparing, the matching_id() will return false when
matching WACF2200 and WACFXXX, and it is reasonable to compare the
string length when matching two IDs.

Suggested-by: Rafael J. Wysocki 
Signed-off-by: Hui Wang 
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

Revert "ACPI / resources: Use AE_CTRL_TERMINATE to terminate resources walks"

2020-12-29T12:42:42+00:00

commit 12fc4dad94dfac25599f31257aac181c691ca96f upstream.

This reverts commit 8a66790b7850a6669129af078768a1d42076a0ef.

Switching this function to AE_CTRL_TERMINATE broke the documented
behaviour of acpi_dev_get_resources() - AE_CTRL_TERMINATE does not, in
fact, terminate the resource walk because acpi_walk_resource_buffer()
ignores it (specifically converting it to AE_OK), referring to that
value as "an OK termination by the user function". This means that
acpi_dev_get_resources() does not abort processing when the preproc
function returns a negative value.

Signed-off-by: Daniel Scally 
Cc: 3.10+  # 3.10+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: video: use ACPI backlight for HP 635 Notebook

2020-11-10T09:22:15+00:00

commit b226faab4e7890bbbccdf794e8b94276414f9058 upstream.

The default backlight interface is AMD's radeon_bl0 which does not
work on this system, so use the ACPI backlight interface on it
instead.

BugLink: https://bugs.launchpad.net/bugs/1894667
Cc: All applicable 
Signed-off-by: Alex Hung 
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI / extlog: Check for RDMSR failure

2020-11-10T09:22:15+00:00

commit 7cecb47f55e00282f972a1e0b09136c8cd938221 upstream.

extlog_init() uses rdmsrl() to read an MSR, which on older CPUs
provokes a error message at boot:

    unchecked MSR access error: RDMSR from 0x179 at rIP: 0xcd047307 (native_read_msr+0x7/0x40)

Use rdmsrl_safe() instead, and return -ENODEV if it fails.

Reported-by: jim@photojim.ca
References: https://bugs.debian.org/971058
Cc: All applicable 
Signed-off-by: Ben Hutchings 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

ACPI: EC: Reference count query handlers under lock

2020-10-01T09:11:51+00:00

[ Upstream commit 3df663a147fe077a6ee8444ec626738946e65547 ]

There is a race condition in acpi_ec_get_query_handler()
theoretically allowing query handlers to go away before refernce
counting them.

In order to avoid it, call kref_get() on query handlers under
ec->mutex.

Also simplify the code a bit while at it.

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin