linux.git/drivers/base, branch v3.18.81

driver core: platform: Don't read past the end of "driver_override" buffer

2017-10-12T07:18:03+00:00

commit bf563b01c2895a4bfd1a29cc5abc67fe706ecffd upstream.

When printing the driver_override parameter when it is 4095 and 4094 bytes
long, the printing code would access invalid memory because we need count+1
bytes for printing.

Reject driver_override values of these lengths in driver_override_store().

This is in close analogy to commit 4efe874aace5 ("PCI: Don't read past the
end of sysfs "driver_override" buffer") from Sasha Levin.

Fixes: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'")
Signed-off-by: Nicolai Stange 
Signed-off-by: Greg Kroah-Hartman

driver core: bus: Fix a potential double free

2017-09-13T21:03:46+00:00

commit 0f9b011d3321ca1079c7a46c18cb1956fbdb7bcb upstream.

The .release function of driver_ktype is 'driver_release()'.
This function frees the container_of this kobject.

So, this memory must not be freed explicitly in the error handling path of
'bus_add_driver()'. Otherwise a double free will occur.

Signed-off-by: Christophe JAILLET 
Signed-off-by: Greg Kroah-Hartman

mm: cma: fix incorrect type conversion for size during dma allocation

2017-09-02T05:05:46+00:00

commit 67a2e213e7e937c41c52ab5bc46bf3f4de469f6e upstream.

This was found during userspace fuzzing test when a large size dma cma
allocation is made by driver(like ion) through userspace.

  show_stack+0x10/0x1c
  dump_stack+0x74/0xc8
  kasan_report_error+0x2b0/0x408
  kasan_report+0x34/0x40
  __asan_storeN+0x15c/0x168
  memset+0x20/0x44
  __dma_alloc_coherent+0x114/0x18c

Signed-off-by: Rohit Vaswani 
Acked-by: Greg Kroah-Hartman 
Cc: Marek Szyprowski 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Cc: Miles Chen 
Signed-off-by: Greg Kroah-Hartman

PM / Domains: Fix unsafe iteration over modified list of domain providers

2017-07-27T22:03:25+00:00

commit b556b15dc04e9b9b98790f04c21acf5e24f994b2 upstream.

of_genpd_del_provider() iterates over list of domain provides and
removes matching element thus it has to use safe version of list
iteration.

Fixes: aa42240ab254 (PM / Domains: Add generic OF-based PM domain look-up)
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Ulf Hansson 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM / Domains: Fix unsafe iteration over modified list of device links

2017-07-27T22:03:25+00:00

commit c6e83cac3eda5f7dd32ee1453df2f7abb5c6cd46 upstream.

pm_genpd_remove_subdomain() iterates over domain's master_links list and
removes matching element thus it has to use safe version of list
iteration.

Fixes: f721889ff65a ("PM / Domains: Support for generic I/O PM domains (v8)")
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Ulf Hansson 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM / QoS: return -EINVAL for bogus strings

2017-07-21T06:12:23+00:00

commit 2ca30331c156ca9e97643ad05dd8930b8fe78b01 upstream.

In the current code, if the user accidentally writes a bogus command to
this sysfs file, then we set the latency tolerance to an uninitialized
variable.

Fixes: 2d984ad132a8 (PM / QoS: Introcuce latency tolerance device PM QoS type)
Signed-off-by: Dan Carpenter 
Acked-by: Pavel Machek 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

driver core: platform: fix race condition with driver_override

2017-07-15T08:14:38+00:00

commit 6265539776a0810b7ce6398c27866ddb9c6bd154 upstream.

The driver_override implementation is susceptible to race condition when
different threads are reading vs storing a different driver override.
Add locking to avoid race condition.

Fixes: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'")
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Salido 
Signed-off-by: Greg Kroah-Hartman

base: make module_create_drivers_dir race-free

2016-07-12T12:46:52+00:00

[ Upstream commit 7e1b1fc4dabd6ec8e28baa0708866e13fa93c9b3 ]

Modules which register drivers via standard path (driver_register) in
parallel can cause a warning:
WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
sysfs: cannot create duplicate filename '/module/saa7146/drivers'
Modules linked in: hexium_gemini(+) mxb(+) ...
...
Call Trace:
...
 [] sysfs_warn_dup+0x62/0x80
 [] sysfs_create_dir_ns+0x77/0x90
 [] kobject_add_internal+0xb4/0x340
 [] kobject_add+0x68/0xb0
 [] kobject_create_and_add+0x31/0x70
 [] module_add_driver+0xc3/0xd0
 [] bus_add_driver+0x154/0x280
 [] driver_register+0x60/0xe0
 [] __pci_register_driver+0x60/0x70
 [] saa7146_register_extension+0x64/0x90 [saa7146]
 [] hexium_init_module+0x11/0x1000 [hexium_gemini]
...

As can be (mostly) seen, driver_register causes this call sequence:
  -> bus_add_driver
    -> module_add_driver
      -> module_create_drivers_dir
The last one creates "drivers" directory in /sys/module/<...>. When
this is done in parallel, the directory is attempted to be created
twice at the same time.

This can be easily reproduced by loading mxb and hexium_gemini in
parallel:
while :; do
  modprobe mxb &
  modprobe hexium_gemini
  wait
  rmmod mxb hexium_gemini saa7146_vv saa7146
done

saa7146 calls pci_register_driver for both mxb and hexium_gemini,
which means /sys/module/saa7146/drivers is to be created for both of
them.

Fix this by a new mutex in module_create_drivers_dir which makes the
test-and-create "drivers" dir atomic.

I inverted the condition and removed 'return' to avoid multiple
unlocks or a goto.

Signed-off-by: Jiri Slaby 
Fixes: fe480a2675ed (Modules: only add drivers/ direcory if needed)
Cc: v2.6.21+ 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

PM / sleep: Handle failures in device_suspend_late() consistently

2016-06-06T23:11:10+00:00

[ Upstream commit 3a17fb329da68cb00558721aff876a80bba2fdb9 ]

Grygorii Strashko reports:

 The PM runtime will be left disabled for the device if its
 .suspend_late() callback fails and async suspend is not allowed
 for this device. In this case device will not be added in
 dpm_late_early_list and dpm_resume_early() will ignore this
 device, as result PM runtime will be disabled for it forever
 (side effect: after 8 subsequent failures for the same device
 the PM runtime will be reenabled due to disable_depth overflow).

To fix this problem, add devices to dpm_late_early_list regardless
of whether or not device_suspend_late() returns errors for them.

That will ensure failures in there to be handled consistently for
all devices regardless of their async suspend/resume status.

Reported-by: Grygorii Strashko 
Tested-by: Grygorii Strashko 
Signed-off-by: Rafael J. Wysocki 
Cc: All applicable 
Signed-off-by: Sasha Levin

PM / Runtime: Fix error path in pm_runtime_force_resume()

2016-06-03T15:30:27+00:00

[ Upstream commit 0ae3aeefabbeef26294e7a349b51f1c761d46c9f ]

As pm_runtime_set_active() may fail because the device's parent isn't
active, we can end up executing the ->runtime_resume() callback for the
device when it isn't allowed.

Fix this by invoking pm_runtime_set_active() before running the callback
and let's also deal with the error code.

Fixes: 37f204164dfb (PM: Add pm_runtime_suspend|resume_force functions)
Signed-off-by: Ulf Hansson 
Reviewed-by: Linus Walleij 
Cc: 3.15+  # 3.15+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin