linux-kernel - Re: [PATCH] platform/x86: quickstart: Fix race condition when reporting input event

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b5d808fd-f9c4-48d5-b888-c4ded4b0cad6@redhat.com>
Date: Sun, 7 Apr 2024 17:32:56 +0200
From: Hans de Goede <hdegoede@...hat.com>
To: Armin Wolf <W_Armin@....de>, ilpo.jarvinen@...ux.intel.com
Cc: rafael@...nel.org, linux-acpi@...r.kernel.org,
 platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] platform/x86: quickstart: Fix race condition when
 reporting input event

Hi,

On 4/6/24 8:57 PM, Armin Wolf wrote:
> Am 27.03.24 um 22:45 schrieb Armin Wolf:
> 
>> Since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run
>> on all CPUs"), the ACPI core allows multiple notify calls to be active
>> at the same time. This means that two instances of quickstart_notify()
>> running at the same time can mess which each others input sequences.
>>
>> Fix this by protecting the input sequence with a mutex.
>>
>> Compile-tested only.
> 
> Any thoughts on this?

I wonder if we need this at all ?

The input_event() / input_report_key() / input_sync() functions
which underpin sparse_keymap_report_event() all are safe to be called
from multiple threads at the same time AFAIK.

The only thing which can then still go "wrong" if we have
2 sparse_keymap_report_event() functions racing for the same
quickstart button and thus for the same keycode is that we may
end up with:

input_report_key(dev, keycode, 1);
input_report_key(dev, keycode, 1); /* This is a no-op */
input_sync(); /* + another input_sync() somewhere which is a no-op */
input_report_key(dev, keycode, 0);
input_report_key(dev, keycode, 0); /* This is a no-op */
input_sync(); /* + another input_sync() somewhere which is a no-op */

IOW if 2 racing notifiers hit the perfect race conditions then
only 1 key press is reported, instead of 2 which seems like
it is not a problem since arguably if the same event gets
reported twice at the exact same time it probably really
is only a single button press.

Also I think it is highly unlikely we will actually see
2 notifiers for this racing in practice.

So I don't think we need this at all. But if others feel strongly
about adding this I can still merge it... ?

Regards,

Hans





>> Fixes: afd66f2a739e ("platform/x86: Add ACPI quickstart button (PNP0C32) driver")
>> Signed-off-by: Armin Wolf <W_Armin@....de>
>> ---
>> This applies on the branch "review-hans". Maybe we could somehow
>> document the concurrency rules for ACPI notify handlers?
>> ---
>>   drivers/platform/x86/quickstart.c | 17 +++++++++++++++++
>>   1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/platform/x86/quickstart.c b/drivers/platform/x86/quickstart.c
>> index ba3a7a25dda7..e40f852d42c1 100644
>> --- a/drivers/platform/x86/quickstart.c
>> +++ b/drivers/platform/x86/quickstart.c
>> @@ -18,6 +18,7 @@
>>   #include <linux/input/sparse-keymap.h>
>>   #include <linux/kernel.h>
>>   #include <linux/module.h>
>> +#include <linux/mutex.h>
>>   #include <linux/platform_device.h>
>>   #include <linux/sysfs.h>
>>   #include <linux/types.h>
>> @@ -35,6 +36,7 @@
>>
>>   struct quickstart_data {
>>       struct device *dev;
>> +    struct mutex input_lock;    /* Protects input sequence during notify */
>>       struct input_dev *input_device;
>>       char input_name[32];
>>       char phys[32];
>> @@ -73,7 +75,10 @@ static void quickstart_notify(acpi_handle handle, u32 event, void *context)
>>
>>       switch (event) {
>>       case QUICKSTART_EVENT_RUNTIME:
>> +        mutex_lock(&data->input_lock);
>>           sparse_keymap_report_event(data->input_device, 0x1, 1, true);
>> +        mutex_unlock(&data->input_lock);
>> +
>>           acpi_bus_generate_netlink_event(DRIVER_NAME, dev_name(data->dev), event, 0);
>>           break;
>>       default:
>> @@ -147,6 +152,13 @@ static void quickstart_notify_remove(void *context)
>>       acpi_remove_notify_handler(handle, ACPI_DEVICE_NOTIFY, quickstart_notify);
>>   }
>>
>> +static void quickstart_mutex_destroy(void *data)
>> +{
>> +    struct mutex *lock = data;
>> +
>> +    mutex_destroy(lock);
>> +}
>> +
>>   static int quickstart_probe(struct platform_device *pdev)
>>   {
>>       struct quickstart_data *data;
>> @@ -165,6 +177,11 @@ static int quickstart_probe(struct platform_device *pdev)
>>       data->dev = &pdev->dev;
>>       dev_set_drvdata(&pdev->dev, data);
>>
>> +    mutex_init(&data->input_lock);
>> +    ret = devm_add_action_or_reset(&pdev->dev, quickstart_mutex_destroy, &data->input_lock);
>> +    if (ret < 0)
>> +        return ret;
>> +
>>       /* We have to initialize the device wakeup before evaluating GHID because
>>        * doing so will notify the device if the button was used to wake the machine
>>        * from S5.
>> -- 
>> 2.39.2
>>
>>
>