linux-toradex.git/drivers, branch v3.10.37

cpufreq: Fix timer/workqueue corruption due to double queueing

2014-04-14T13:42:19+00:00

commit 3617f2ca6d0eba48114308532945a7f1577816a4 upstream.

When a CPU is hot removed we'll cancel all the delayed work items
via gov_cancel_work(). Normally this will just cancels a delayed
timer on each CPU that the policy is managing and the work won't
run, but if the work is already running the workqueue code will
wait for the work to finish before continuing to prevent the
work items from re-queuing themselves like they normally do. This
scheme will work most of the time, except for the case where the
work function determines that it should adjust the delay for all
other CPUs that the policy is managing. If this scenario occurs,
the canceling CPU will cancel its own work but queue up the other
CPUs works to run. For example:

 CPU0                                        CPU1
 ----                                        ----
 cpu_down()
  ...
  __cpufreq_remove_dev()
   cpufreq_governor_dbs()
    case CPUFREQ_GOV_STOP:
     gov_cancel_work(dbs_data, policy);
      cpu0 work is canceled
       timer is canceled
       cpu1 work is canceled                    
                                od_dbs_timer()
                                                 gov_queue_work(*, *, true);
 						  cpu0 work queued
 						  cpu1 work queued
						  cpu2 work queued
						  ...
       cpu1 work is canceled
       cpu2 work is canceled
       ...

At the end of the GOV_STOP case cpu0 still has a work queued to
run although the code is expecting all of the works to be
canceled. __cpufreq_remove_dev() will then proceed to
re-initialize all the other CPUs works except for the CPU that is
going down. The CPUFREQ_GOV_START case in cpufreq_governor_dbs()
will trample over the queued work and debugobjects will spit out
a warning:

WARNING: at lib/debugobjects.c:260 debug_print_object+0x94/0xbc()
ODEBUG: init active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x10
Modules linked in:
CPU: 0 PID: 1491 Comm: sh Tainted: G        W    3.10.0 #19
[] (unwind_backtrace+0x0/0x11c) from [] (show_stack+0x10/0x14)
[] (show_stack+0x10/0x14) from [] (warn_slowpath_common+0x4c/0x6c)
[] (warn_slowpath_common+0x4c/0x6c) from [] (warn_slowpath_fmt+0x2c/0x3c)
[] (warn_slowpath_fmt+0x2c/0x3c) from [] (debug_print_object+0x94/0xbc)
[] (debug_print_object+0x94/0xbc) from [] (__debug_object_init+0x2d0/0x340)
[] (__debug_object_init+0x2d0/0x340) from [] (init_timer_key+0x14/0xb0)
[] (init_timer_key+0x14/0xb0) from [] (cpufreq_governor_dbs+0x3e8/0x5f8)
[] (cpufreq_governor_dbs+0x3e8/0x5f8) from [] (__cpufreq_governor+0xdc/0x1a4)
[] (__cpufreq_governor+0xdc/0x1a4) from [] (__cpufreq_remove_dev.isra.10+0x3b4/0x434)
[] (__cpufreq_remove_dev.isra.10+0x3b4/0x434) from [] (cpufreq_cpu_callback+0x60/0x80)
[] (cpufreq_cpu_callback+0x60/0x80) from [] (notifier_call_chain+0x38/0x68)
[] (notifier_call_chain+0x38/0x68) from [] (__cpu_notify+0x28/0x40)
[] (__cpu_notify+0x28/0x40) from [] (_cpu_down+0x7c/0x2c0)
[] (_cpu_down+0x7c/0x2c0) from [] (cpu_down+0x24/0x40)
[] (cpu_down+0x24/0x40) from [] (store_online+0x2c/0x74)
[] (store_online+0x2c/0x74) from [] (dev_attr_store+0x18/0x24)
[] (dev_attr_store+0x18/0x24) from [] (sysfs_write_file+0x100/0x148)
[] (sysfs_write_file+0x100/0x148) from [] (vfs_write+0xcc/0x174)
[] (vfs_write+0xcc/0x174) from [] (SyS_write+0x38/0x64)
[] (SyS_write+0x38/0x64) from [] (ret_fast_syscall+0x0/0x30)

Signed-off-by: Stephen Boyd 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Cc: Krzysztof Kozlowski 
Signed-off-by: Greg Kroah-Hartman

cpufreq: Fix governor start/stop race condition

2014-04-14T13:42:19+00:00

commit 95731ebb114c5f0c028459388560fc2a72fe5049 upstream.

Cpufreq governors' stop and start operations should be carried out
in sequence.  Otherwise, there will be unexpected behavior, like in
the example below.

Suppose there are 4 CPUs and policy->cpu=CPU0, CPU1/2/3 are linked
to CPU0.  The normal sequence is:

 1) Current governor is userspace.  An application tries to set the
    governor to ondemand.  It will call __cpufreq_set_policy() in
    which it will stop the userspace governor and then start the
    ondemand governor.

 2) Current governor is userspace.  The online of CPU3 runs on CPU0.
    It will call cpufreq_add_policy_cpu() in which it will first
    stop the userspace governor, and then start it again.

If the sequence of the above two cases interleaves, it becomes:

 1) Application stops userspace governor
 2)                                  Hotplug stops userspace governor

which is a problem, because the governor shouldn't be stopped twice
in a row.  What happens next is:

 3) Application starts ondemand governor
 4)                                  Hotplug starts a governor

In step 4, the hotplug is supposed to start the userspace governor,
but now the governor has been changed by the application to ondemand,
so the ondemand governor is started once again, which is incorrect.

The solution is to prevent policy governors from being stopped
multiple times in a row.  A governor should only be stopped once for
one policy.  After it has been stopped, no more governor stop
operations should be executed.

Also add a mutex to serialize governor operations.

[rjw: Changelog.  And you owe me a beverage of my choice.]
Signed-off-by: Xiaoguang Chen 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Cc: Krzysztof Kozlowski 
Signed-off-by: Greg Kroah-Hartman

isdnloop: several buffer overflows

2014-04-14T13:42:18+00:00

[ Upstream commit 7563487cbf865284dcd35e9ef5a95380da046737 ]

There are three buffer overflows addressed in this patch.

1) In isdnloop_fake_err() we add an 'E' to a 60 character string and
then copy it into a 60 character buffer.  I have made the destination
buffer 64 characters and I'm changed the sprintf() to a snprintf().

2) In isdnloop_parse_cmd(), p points to a 6 characters into a 60
character buffer so we have 54 characters.  The ->eazlist[] is 11
characters long.  I have modified the code to return if the source
buffer is too long.

3) In isdnloop_command() the cbuf[] array was 60 characters long but the
max length of the string then can be up to 79 characters.  I made the
cbuf array 80 characters long and changed the sprintf() to snprintf().
I also removed the temporary "dial" buffer and changed it to use "p"
directly.

Unfortunately, we pass the "cbuf" string from isdnloop_command() to
isdnloop_writecmd() which truncates anything over 60 characters to make
it fit in card->omsg[].  (It can accept values up to 255 characters so
long as there is a '\n' character every 60 characters).  For now I have
just fixed the memory corruption bug and left the other problems in this
driver alone.

Signed-off-by: Dan Carpenter 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

isdnloop: Validate NUL-terminated strings from user.

2014-04-14T13:42:18+00:00

[ Upstream commit 77bc6bed7121936bb2e019a8c336075f4c8eef62 ]

Return -EINVAL unless all of user-given strings are correctly
NUL-terminated.

Signed-off-by: YOSHIFUJI Hideaki 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

xen-netback: remove pointless clause from if statement

2014-04-14T13:42:18+00:00

[ Upstream commit 0576eddf24df716d8570ef8ca11452a9f98eaab2 ]

This patch removes a test in start_new_rx_buffer() that checks whether
a copy operation is less than MAX_BUFFER_OFFSET in length, since
MAX_BUFFER_OFFSET is defined to be PAGE_SIZE and the only caller of
start_new_rx_buffer() already limits copy operations to PAGE_SIZE or less.

Signed-off-by: Paul Durrant 
Cc: Ian Campbell 
Cc: Wei Liu 
Cc: Sander Eikelenboom 
Reported-By: Sander Eikelenboom 
Tested-By: Sander Eikelenboom 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

vhost: validate vhost_get_vq_desc return value

2014-04-14T13:42:18+00:00

[ Upstream commit a39ee449f96a2cd44ce056d8a0a112211a9b1a1f ]

vhost fails to validate negative error code
from vhost_get_vq_desc causing
a crash: we are using -EFAULT which is 0xfffffff2
as vector size, which exceeds the allocated size.

The code in question was introduced in commit
8dd014adfea6f173c1ef6378f7e5e7924866c923
    vhost-net: mergeable buffers support

CVE-2014-0055

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

vhost: fix total length when packets are too short

2014-04-14T13:42:18+00:00

[ Upstream commit d8316f3991d207fe32881a9ac20241be8fa2bad0 ]

When mergeable buffers are disabled, and the
incoming packet is too large for the rx buffer,
get_rx_bufs returns success.

This was intentional in order for make recvmsg
truncate the packet and then handle_rx would
detect err != sock_len and drop it.

Unfortunately we pass the original sock_len to
recvmsg - which means we use parts of iov not fully
validated.

Fix this up by detecting this overrun and doing packet drop
immediately.

CVE-2014-0077

Signed-off-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

usbnet: include wait queue head in device structure

2014-04-14T13:42:18+00:00

[ Upstream commit 14a0d635d18d0fb552dcc979d6d25106e6541f2e ]

This fixes a race which happens by freeing an object on the stack.
Quoting Julius:
> The issue is
> that it calls usbnet_terminate_urbs() before that, which temporarily
> installs a waitqueue in dev->wait in order to be able to wait on the
> tasklet to run and finish up some queues. The waiting itself looks
> okay, but the access to 'dev->wait' is totally unprotected and can
> race arbitrarily. I think in this case usbnet_bh() managed to succeed
> it's dev->wait check just before usbnet_terminate_urbs() sets it back
> to NULL. The latter then finishes and the waitqueue_t structure on its
> stack gets overwritten by other functions halfway through the
> wake_up() call in usbnet_bh().

The fix is to just not allocate the data structure on the stack.
As dev->wait is abused as a flag it also takes a runtime PM change
to fix this bug.

Signed-off-by: Oliver Neukum 
Reported-by: Grant Grundler 
Tested-by: Grant Grundler 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tg3: Do not include vlan acceleration features in vlan_features

2014-04-14T13:42:17+00:00

[ Upstream commit 51dfe7b944998eaeb2b34d314f3a6b16a5fd621b ]

Including hardware acceleration features in vlan_features breaks
stacked vlans (Q-in-Q) by marking the bottom vlan interface as
capable of acceleration.  This causes one of the tags to be lost
and the packets are sent with a sing vlan header.

CC: Nithin Nayak Sujir 
CC: Michael Chan 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

vxlan: fix potential NULL dereference in arp_reduce()

2014-04-14T13:42:17+00:00

[ Upstream commit 7346135dcd3f9b57f30a5512094848c678d7143e ]

This patch fixes a NULL pointer dereference in the event of an
skb allocation failure in arp_reduce().

Signed-Off-By: David L Stevens 
Acked-by: Cong Wang 

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman