kernel.git/drivers/platform/x86/wmi.c, branch linux-4.20.y

platform/x86: wmi: declare device_type structure as constant

2018-10-31T14:11:39Z

The only usage of device_type structure is getting stored as a reference in the type field of device structure. This type field is declared const. Therefore, the device_type structure can never be modified and can be declared as const. Signed-off-by: Bhumika Goyal Signed-off-by: Andy Shevchenko

platform/x86: wmi: Do not mix pages and kmalloc

2018-06-22T23:24:40Z

The probe handler_data was being allocated with __get_free_pages() for no reason I could find. The error path was using kfree(). Since other things are happily using kmalloc() in the probe path, switch to kmalloc() entirely. This fixes the error path mismatch and will avoid issues with CONFIG_HARDENED_USERCOPY_PAGESPAN=y. Reported-by: Mihai Donțu Signed-off-by: Kees Cook Acked-by: Mario Limonciello Cc: stable@vger.kernel.org Signed-off-by: Darren Hart (VMware)

platform/x86: wmi: Fix misuse of vsprintf extension %pULL

2018-03-01T17:57:04Z

%pULL doesn't officially exist but %pUL does. Miscellanea: o Add missing newlines to a couple logging messages Signed-off-by: Joe Perches Signed-off-by: Darren Hart (VMware)

platform/x86: wmi: Replace list_for_each() by list_for_each_entry()

2018-02-23T16:43:39Z

In all cases list_for_each() followed by list_entry(), so, replace them by list_for_each_entry() macro. Signed-off-by: Andy Shevchenko Reviewed-by: Darren Hart (VMware)

platform/x86: wmi: Replace kmalloc + sprintf() with kasprintf()

2018-02-19T15:03:43Z

kasprintf() does the job of two: kmalloc() and sprintf(). Replace two calls with one. Reviewed-by: Darren Hart (VMware) Signed-off-by: Andy Shevchenko

platform/x86: wmi: fix off-by-one write in wmi_dev_probe()

2018-02-15T10:18:32Z

wmi_dev_probe() allocates one byte less than necessary, thus subsequent sprintf() call writes trailing zero past the end of the 'buf': BUG: KASAN: slab-out-of-bounds in vsnprintf+0xda4/0x1240 Write of size 1 at addr ffff880423529caf by task kworker/1:1/32 Call Trace: dump_stack+0xb3/0x14d print_address_description+0xd7/0x380 kasan_report+0x166/0x2b0 vsnprintf+0xda4/0x1240 sprintf+0x9b/0xd0 wmi_dev_probe+0x1c3/0x400 driver_probe_device+0x5d1/0x990 bus_for_each_drv+0x109/0x190 __device_attach+0x217/0x360 bus_probe_device+0x1ad/0x260 deferred_probe_work_func+0x10f/0x5d0 process_one_work+0xa8b/0x1dc0 worker_thread+0x20d/0x17d0 kthread+0x311/0x3d0 ret_from_fork+0x3a/0x50 Allocated by task 32: kasan_kmalloc+0xa0/0xd0 __kmalloc+0x14f/0x3e0 wmi_dev_probe+0x182/0x400 driver_probe_device+0x5d1/0x990 bus_for_each_drv+0x109/0x190 __device_attach+0x217/0x360 bus_probe_device+0x1ad/0x260 deferred_probe_work_func+0x10f/0x5d0 process_one_work+0xa8b/0x1dc0 worker_thread+0x20d/0x17d0 kthread+0x311/0x3d0 ret_from_fork+0x3a/0x50 Increment allocation size to fix this. Fixes: 44b6b7661132 ("platform/x86: wmi: create userspace interface for drivers") Signed-off-by: Andrey Ryabinin Cc: Signed-off-by: Andy Shevchenko

platform/x86: wmi: Call acpi_wmi_init() later

2018-01-08T18:47:48Z

Calling acpi_wmi_init() at the subsys_initcall() level causes ordering issues to appear on some systems and they are difficult to reproduce, because there is no guaranteed ordering between subsys_initcall() calls, so they may occur in different orders on different systems. In particular, commit 86d9f48534e8 (mm/slab: fix kmemcg cache creation delayed issue) exposed one of these issues where genl_init() and acpi_wmi_init() are both called at the same initcall level, but the former must run before the latter so as to avoid a NULL pointer dereference. For this reason, move the acpi_wmi_init() invocation to the initcall_sync level which should still be early enough for things to work correctly in the WMI land. Link: https://marc.info/?t=151274596700002&r=1&w=2 Reported-by: Jonathan McDowell Reported-by: Joonsoo Kim Tested-by: Jonathan McDowell Signed-off-by: Rafael J. Wysocki Signed-off-by: Darren Hart (VMware)

platform/x86: wmi: release mutex on module acquistion failure

2017-11-08T20:58:36Z

This failure mode should have also released the mutex. Signed-off-by: Mario Limonciello Signed-off-by: Darren Hart (VMware)

platform/x86: wmi: create userspace interface for drivers

2017-11-03T23:34:00Z

For WMI operations that are only Set or Query readable and writable sysfs attributes created by WMI vendor drivers or the bus driver makes sense. For other WMI operations that are run on Method, there needs to be a way to guarantee to userspace that the results from the method call belong to the data request to the method call. Sysfs attributes don't work well in this scenario because two userspace processes may be competing at reading/writing an attribute and step on each other's data. When a WMI vendor driver declares a callback method in the wmi_driver the WMI bus driver will create a character device that maps to that function. This callback method will be responsible for filtering invalid requests and performing the actual call. That character device will correspond to this path: /dev/wmi/$driver Performing read() on this character device will provide the size of the buffer that the character device needs to perform calls. This buffer size can be set by vendor drivers through a new symbol or when MOF parsing is available by the MOF. Performing ioctl() on this character device will be interpretd by the WMI bus driver. It will perform sanity tests for size of data, test them for a valid instance, copy the data from userspace and pass iton to the vendor driver to further process and run. This creates an implicit policy that each driver will only be allowed a single character device. If a module matches multiple GUID's, the wmi_devices will need to be all handled by the same wmi_driver. The WMI vendor drivers will be responsible for managing inappropriate access to this character device and proper locking on data used by it. When a WMI vendor driver is unloaded the WMI bus driver will clean up the character device and any memory allocated for the call. Signed-off-by: Mario Limonciello Reviewed-by: Edward O'Callaghan Signed-off-by: Darren Hart (VMware)

platform/x86: wmi: Don't allow drivers to get each other's GUIDs

2017-11-03T23:33:58Z

The only driver using this was dell-wmi, and it really was a hack. The driver was getting a data attribute from another driver and this type of action should not be encouraged. Rather drivers that need to interact with one another should pass data back and forth via exported functions. Signed-off-by: Mario Limonciello Reviewed-by: Edward O'Callaghan Reviewed-by: Pali Rohár Signed-off-by: Darren Hart (VMware)