Use android-msm-bullhead-3.10-oreo-m7 regulatory db instead of Samsung's
changes that incorrectly revert newer commits.
Change-Id: Ibc85dbe7621ca1a3a7f22b4a745227142031649e
qcacld-3.0 to qcacld-2.0 propagation
Add new user country XA to regulatory tables. This is an 'engineered'
country for Japan that has channels 5150-5230 marked as passive.
Change-Id: I6c582bc0635ecae2c37b98d761f72f222c408d2f
CRS-Fixed: 1007217
Currently, if no country is set with FCC3_FCCA regdomain
,then default country is picked as 'NA' i.e no country set from the country
list. This causes certain channels to be disabled in the valid channels
list; A valid country needs to be set as the default one. For this
the offending 'NA' entry needs to be removed.
Change-Id: Ib132ff92e1aacc1012e6a1eeb3437be78f7f98df
CRs-fixed: 980447
Exclude 4 bytes which holds the size of the buffer while
calculating the actual buffer size to avoid OOB write.
CRs-Fixed: 2534791
Change-Id: Ic8a80e07a2cbadd6cce197dcf4f359bdaea373d6
Signed-off-by: Paras Nagda <pnagda@codeaurora.org>
propagation from qcacld-3.0 to qcacld-2.0.
The frame received time is updated even when the frame was
dropped and thus the received time of the frame keeps on increasing.
Thus the condition to check if frame is allowed after
TLSHIM_MGMT_FRAME_DETECT_DOS_TIMER ms always fails if driver
continuously keep on getting the frames.
This can lead to dropping of valid deauth/disassoc frames in case
if RMF is enabled and some rogue peer keep on sending rogue
deauth/disassoc frames and thus even if peer send valid deauth
peer will not get disconnected.
Fix this by updating the rcvd time stamp only when the frame is
allowed, as this timestamp should be used to block the duplicate
frames for TLSHIM_MGMT_FRAME_DETECT_DOS_TIMER ms.
Change-Id: I4f480e21369b585d78f240c5f4f062d010d889a8
CRs-Fixed: 2258844
The subtype values used in the DoS attacks check are not correct.
No MGMT frame will be dropped in a DoS attack.
Change-Id: I0fdcffd7151a78abf21bb0f4223aaba3e86a46ab
CRs-Fixed: 2103880
qcacld-3.0 to qcacld-2.0 propagation.
In SME layer, boundary check for dscp_to_up_map array is not present.
The dscpmapping is an array of 0x40 elements. Values in dscp_exceptions
are used to index dscpmapping. The indices are not validated to be less
than 0x40. The dscp_exceptions array is received from association
response frame. A malicious AP can send values up to 0xff, causing OOB
write of dscpmapping array.
Hence, max index check is added to avoid OOB write of dscpmapping array.
Change-Id: I73526849677e867673fc0bd0024ed2b003e4f89e
CRs-Fixed: 2585141
propagation from qcacld-3.0 to qcacld-2.0
In SAP mode, one peer sends multiple deauth frames which
results in queuing multiple WM status change cmd which
is added at head of queue. WM status change cmd is added
at head of queue for other peers which results in delay
in processing the cmd for first peer. The WM status cmd
is processed and peer is deleted and connection is
initiated by the same peer. The remaining WM status change
cmd is now processed and del_sta is triggered. On receiving
del_sta response, cleanup_trigger in sta_ds is checked
and eWNI_SME_DISASSOC_RSP message is posted to SME instead
of eWNI_SME_DISCONNECT_DONE_IND since the sta_ds entry is
added newly. This will result in active command timeout
since WM status change cmd is not removed from active queue.
Fix is to drop deauth or disassoc frame after the first one
is processed and use normal priority to queue WM status
change cmd.
Change-Id: Ib87fa7496d4adb6e25c30de657ce62101ca6f263
CRs-Fixed: 2589737
psessionEntry->pSchBeaconFrameBegin is allocated with fix length
SCH_MAX_BEACON_SIZE. Do not copy the value to the buffer exceeding
psessionEntry->pSchBeaconFrameBegin.
Change-Id: I539692c01753b991a963b0416177cf5b474cfdf8
CRs-Fixed: 2577682
[ Upstream commit c7df4a1ecb8579838ec8c56b2bb6a6716e974f37 ]
If the file system is corrupted such that a file's i_links_count is
too small, then it's possible that when unlinking that file, i_nlink
will already be zero. Previously we were working around this kind of
corruption by forcing i_nlink to one; but we were doing this before
trying to delete the directory entry --- and if the file system is
corrupted enough that ext4_delete_entry() fails, then we exit with
i_nlink elevated, and this causes the orphan inode list handling to be
FUBAR'ed, such that when we unmount the file system, the orphan inode
list can get corrupted.
A better way to fix this is to simply skip trying to call drop_nlink()
if i_nlink is already zero, thus moving the check to the place where
it makes the most sense.
https://bugzilla.kernel.org/show_bug.cgi?id=205433
Link: https://lore.kernel.org/r/20191112032903.8828-1-tytso@mit.edu
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I9a08356694b4ef9823e9c8c417fa4a1a3fab4cdb
[ Upstream commit f4d7b3e23d259c44f1f1c39645450680fcd935d6 ]
1 << 31 is Undefined Behaviour according to the C standard.
Use U type modifier to avoid theoretical overflow.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I48de91875ac92bb7f551f145684204c12affe4f3
[ Upstream commit 5bf325a53202b8728cf7013b72688c46071e212e ]
With many active TCP sockets, fat TCP sockets could fool
__sk_mem_raise_allocated() thanks to an overflow.
They would increase their share of the memory, instead
of decreasing it.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I5904c40be0d5ccee1e961094d409050a35c5b2da
Issue:
the region index is not validated against the region size.
this cause out-of-bound read on the KASAN kernel.
Fix:
Add restriction that region index smaller than region size.
CRs-Fixed: 2153841
Change-Id: I141bba45662769f0661c947fb642c2671578f32e
Signed-off-by: Haibin Liu <haibinl@codeaurora.org>
Signed-off-by: VijayaKumar T M <vtmuni@codeaurora.org>
[ Upstream commit 18a110b022a5c02e7dc9f6109d0bd93e58ac6ebb ]
Curtis Taylor and Jon Maxwell reported and debugged a crash on 3.10
based kernel.
Crash occurs in ctnetlink_conntrack_events because net->nfnl socket is
NULL. The nfnl socket was set to NULL by netns destruction running on
another cpu.
The exiting network namespace calls the relevant destructors in the
following order:
1. ctnetlink_net_exit_batch
This nulls out the event callback pointer in struct netns.
2. nfnetlink_net_exit_batch
This nulls net->nfnl socket and frees it.
3. nf_conntrack_cleanup_net_list
This removes all remaining conntrack entries.
This is order is correct. The only explanation for the crash so ar is:
cpu1: conntrack is dying, eviction occurs:
-> nf_ct_delete()
-> nf_conntrack_event_report \
-> nf_conntrack_eventmask_report
-> notify->fcn() (== ctnetlink_conntrack_events).
cpu1: a. fetches rcu protected pointer to obtain ctnetlink event callback.
b. gets interrupted.
cpu2: runs netns exit handlers:
a runs ctnetlink destructor, event cb pointer set to NULL.
b runs nfnetlink destructor, nfnl socket is closed and set to NULL.
cpu1: c. resumes and trips over NULL net->nfnl.
Problem appears to be that ctnetlink_net_exit_batch only prevents future
callers of nf_conntrack_eventmask_report() from obtaining the callback.
It doesn't wait of other cpus that might have already obtained the
callbacks address.
I don't see anything in upstream kernels that would prevent similar
crash: We need to wait for all cpus to have exited the event callback.
Fixes: 9592a5c01e ("netfilter: ctnetlink: netns support")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: Iad93478e7bf5dc987ae5d1cd10cf261af41c313a
Use trusted packet size on the received packet and check for
the size of the data received against the expected size
before accessing the packet.
Bug: 140423290
Change-Id: I1bd6008249a0bf4edeec711ec8d23cf7b8dac1f1
Signed-off-by: Priyanka Gujjula <pgujjula@codeaurora.org>
commit 2a9edd056ed4fbf9d2e797c3fc06335af35bccc4 upstream.
The old loop wouldn't stop when reaching `start` if `start==NULL`, instead
continuing backwards to index -1 and crashing.
Luckily you need to be highly privileged to map things at NULL, so it's not
a big problem.
Fix it by adjusting the loop so that the loop variable is always in bounds.
This patch is deliberately minimal to simplify backporting, but IMO this
function could use a refactor. The jump labels in the second loop body are
horrible (the error gotos should be jumping to free_range instead), and
both loops would look nicer if they just iterated upwards through indices.
And the up_read()+mmput() shouldn't be duplicated like that.
Fixes: 457b9a6f09 ("Staging: android: add binder driver")
Change-Id: I4ad9023a3a40e1a6afdeb01a0bcee6a12e667a47
Signed-off-by: Jann Horn <jannh@google.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20191018205631.248274-3-jannh@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.16: There is no continue statement in the loop,
so we only need to check the exit condition at the bottom]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit c7cd7c748a3250ca33509f9235efab9c803aca09 upstream.
In sound_insert_unit(), the controlling structure 's' is allocated through
kmalloc(). Then it is added to the sound driver list by invoking
__sound_insert_unit(). Later on, if __register_chrdev() fails, 's' is
removed from the list through __sound_remove_unit(). If 'index' is not less
than 0, -EBUSY is returned to indicate the error. However, 's' is not
deallocated on this execution path, leading to a memory leak bug.
To fix the above issue, free 's' before -EBUSY is returned.
Change-Id: I47c3baf7ad029e4c36db0540b2b0010599975256
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
There are two loops that are almost identical but only with different
checks. Refactor them with a simple helper, and give a bit more
comments what's doing there.
Change-Id: I7d968abfc13155acc3479615c43b62e32059f004
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The test here is intended intended to prevent shift wrapping bugs when
we do "1U << idx2". We should consider the number of bits in a u32
instead of the number of bytes.
[fix another chunk similarly by tiwai]
Fixes: 7bb2491b35a2 ('ALSA: Add kconfig to specify the max card numbers')
Change-Id: Ia4b36f3fdb3920a0640b8891253df12bbca88c73
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit "qcacld-2.0: Fix multiple length definition issue in WLAN FW
message" introduced a new error path that requires an additional unlock.
Change-Id: I9acaac64b4ed2fdbdf6bd18cf6428b658ca75556
When ashmem file is being mmapped the resulting vma->vm_file points to the
backing shmem file with the generic fops that do not check ashmem
permissions like fops of ashmem do. Fix that by disallowing mapping
operation for backing shmem file.
Bug: 142938932
Bug: 142903466
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I718dfca02c83845f8a41d88506871b0aa21326d7
CVE-2020-0009
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Parameter fragments and fragment_size are type of u32. U32_MAX is
the correct check.
CRs-Fixed: 1014726
Change-Id: Ia6d4755408646ac4a75724f3c6f2177651875da3
Signed-off-by: Xiaojun Sang <xsang@codeaurora.org>
Increment data ready only if it is not incremented earlier.
Change-Id: Ia61e638bcf18e17dfe4bef15fc8ed4168b4c1891
Signed-off-by: Sreelakshmi Gownipalli <sgownipa@codeaurora.org>
Signed-off-by: Hardik Arya <harya@codeaurora.org>
Propagate from qcacld3.0 to qcacld2.0
Currently variable "num_mpdu_ranges" is from message, which is used
directly without any validation which causes buffer over-write.
To avoid buffer over-write add check for the valid num_mpdu_ranges
Change-Id: I93e1e26a7b41ca5ab66d5f7efb92d5d64e6c7612
CRs-Fixed: 2500393
Currently, firmware fills the num variables value of param_tlvs
structure for all wmi commands. But during buffer write the fixed param
values are used to check maximum limit of buffer in wmi commands.
Due to multiple length definition of num variable in WLAN FW message,
num variables of param_tlvs may not equal to max limit defined in
fixed_param, resulting OOB issues in WLAN FW messages during buffer write.
Add sanity check to make sure that num variables value doesn’t exceed max
limit of num value defined in param_tlvs.
Change-Id: I43c15557057ab5b900f19b9f54426dcdf85e2c27
CRs-Fixed: 2226556
On high latency platform host driver has pause/unpause count per vdev,
so should do pause/unpause with pair. wma_unpause_vdev() want to unpause
all pausing with all reasons, and clear pause reason bitmap forcedly,
it works on low latency platform which depends on reason bitmap to
unpause, but it possible has unpause count less then paused count on HL
platform and lead to vdev peer tx queue can’t unpause after resume and
data stall in host tx queue.
Fix it by unpause reason by reason in wma_unpause_vdev().
Change-Id: I3aef06eeec42de5a56a98322670efa3ee453a94c
CRs-Fixed: 2525548
If the firmware gets compromised, the values sent to
the driver could result in buffer overflows.
Validate HTT MSG "msg_word" to avoid buffer overflows.
Change-Id: I635e9ca3fee8b865a99d1d5a6da2447ac9801c7d
CRs-Fixed: 2529113
[ Upstream commit b501426cf86e70649c983c52f4c823b3c40d72a3 ]
If the interface is not in MESH mode, the command 'iw wlanx mpath del'
will cause kernel panic.
The root cause is null pointer access in mpp_flush_by_proxy(), as the
pointer 'sdata->u.mesh.mpp_paths' is NULL for non MESH interface.
Unable to handle kernel NULL pointer dereference at virtual address 00000068
[...]
PC is at _raw_spin_lock_bh+0x20/0x5c
LR is at mesh_path_del+0x1c/0x17c [mac80211]
[...]
Process iw (pid: 4537, stack limit = 0xd83e0238)
[...]
[<c021211c>] (_raw_spin_lock_bh) from [<bf8c7648>] (mesh_path_del+0x1c/0x17c [mac80211])
[<bf8c7648>] (mesh_path_del [mac80211]) from [<bf6cdb7c>] (extack_doit+0x20/0x68 [compat])
[<bf6cdb7c>] (extack_doit [compat]) from [<c05c309c>] (genl_rcv_msg+0x274/0x30c)
[<c05c309c>] (genl_rcv_msg) from [<c05c25d8>] (netlink_rcv_skb+0x58/0xac)
[<c05c25d8>] (netlink_rcv_skb) from [<c05c2e14>] (genl_rcv+0x20/0x34)
[<c05c2e14>] (genl_rcv) from [<c05c1f90>] (netlink_unicast+0x11c/0x204)
[<c05c1f90>] (netlink_unicast) from [<c05c2420>] (netlink_sendmsg+0x30c/0x370)
[<c05c2420>] (netlink_sendmsg) from [<c05886d0>] (sock_sendmsg+0x70/0x84)
[<c05886d0>] (sock_sendmsg) from [<c0589f4c>] (___sys_sendmsg.part.3+0x188/0x228)
[<c0589f4c>] (___sys_sendmsg.part.3) from [<c058add4>] (__sys_sendmsg+0x4c/0x70)
[<c058add4>] (__sys_sendmsg) from [<c0208c80>] (ret_fast_syscall+0x0/0x44)
Code: e2822c02 e2822001 e5832004 f590f000 (e1902f9f)
---[ end trace bbd717600f8f884d ]---
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Link: https://lore.kernel.org/r/1569485810-761-1-git-send-email-miaoqing@codeaurora.org
[trim useless data from commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I0af06ab88a75b6f7528bb1a134115b530cfb7595
An out-of-bound write can be triggered by a specially-crafted
command supplied by a userspace application via the NL80211
(Netlink) interface in function wma_apfind_set_cmd if
apfind_req->request_data_len is a large value that's close to
the limit of uint16_t (such as 0xffff).
Change-Id: Iea43469cc78bebe3f8603ac14ff8253687307beb
CRs-Fixed: 2539113
If the firmware gets compromised, the values sent to
the driver could result in buffer overflows.
Validate HTT MSG "msg_word" to avoid buffer overflows.
Change-Id: I6073029f61a358da32bcc0dcfc339d9bb7ee8218
CRs-Fixed: 2529113
commit b9023b91dd020ad7e093baa5122b6968c48cc9e0 upstream.
When a cpu requests broadcasting, before starting the tick broadcast
hrtimer, bc_set_next() checks if the timer callback (bc_handler) is active
using hrtimer_try_to_cancel(). But hrtimer_try_to_cancel() does not provide
the required synchronization when the callback is active on other core.
The callback could have already executed tick_handle_oneshot_broadcast()
and could have also returned. But still there is a small time window where
the hrtimer_try_to_cancel() returns -1. In that case bc_set_next() returns
without doing anything, but the next_event of the tick broadcast clock
device is already set to a timeout value.
In the race condition diagram below, CPU #1 is running the timer callback
and CPU #2 is entering idle state and so calls bc_set_next().
In the worst case, the next_event will contain an expiry time, but the
hrtimer will not be started which happens when the racing callback returns
HRTIMER_NORESTART. The hrtimer might never recover if all further requests
from the CPUs to subscribe to tick broadcast have timeout greater than the
next_event of tick broadcast clock device. This leads to cascading of
failures and finally noticed as rcu stall warnings
Here is a depiction of the race condition
CPU #1 (Running timer callback) CPU #2 (Enter idle
and subscribe to
tick broadcast)
--------------------- ---------------------
__run_hrtimer() tick_broadcast_enter()
bc_handler() __tick_broadcast_oneshot_control()
tick_handle_oneshot_broadcast()
raw_spin_lock(&tick_broadcast_lock);
dev->next_event = KTIME_MAX; //wait for tick_broadcast_lock
//next_event for tick broadcast clock
set to KTIME_MAX since no other cores
subscribed to tick broadcasting
raw_spin_unlock(&tick_broadcast_lock);
if (dev->next_event == KTIME_MAX)
return HRTIMER_NORESTART
// callback function exits without
restarting the hrtimer //tick_broadcast_lock acquired
raw_spin_lock(&tick_broadcast_lock);
tick_broadcast_set_event()
clockevents_program_event()
dev->next_event = expires;
bc_set_next()
hrtimer_try_to_cancel()
//returns -1 since the timer
callback is active. Exits without
restarting the timer
cpu_base->running = NULL;
The comment that hrtimer cannot be armed from within the callback is
wrong. It is fine to start the hrtimer from within the callback. Also it is
safe to start the hrtimer from the enter/exit idle code while the broadcast
handler is active. The enter/exit idle code and the broadcast handler are
synchronized using tick_broadcast_lock. So there is no need for the
existing try to cancel logic. All this can be removed which will eliminate
the race condition as well.
Fixes: 5d1638acb9f6 ("tick: Introduce hrtimer based broadcast")
Change-Id: I4f5d95fad77d252df9334c2bbf997342ecc19d41
Originally-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Balasubramani Vivekanandan <balasubramani_vivekanandan@mentor.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20190926135101.12102-2-balasubramani_vivekanandan@mentor.com
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 38d23a6cc16c02f7b0c920266053f340b5601735 upstream.
The hrtimer callback in the hrtimer's tick broadcast code sometimes
incorrectly ends up scheduling events at the current tick causing the
kernel to hang servicing the same hrtimer forever. This typically
happens when a device is swapped out by
tick_install_broadcast_device(), which replaces the event handler with
clock_events_handle_noop() and sets the device mode to
CLOCK_EVT_MODE_UNUSED. If the timer is scheduled when this happens,
the next_event field will not be updated and the hrtimer ends up being
restarted at the current tick. To prevent this from happening, only
try to restart the hrtimer if the broadcast clock event device is in
one of the active modes and try to cancel the timer when entering the
CLOCK_EVT_MODE_UNUSED mode.
Change-Id: I6ee36e3dbc52428a6790a732b400ca1a9db9eacd
Signed-off-by: Andreas Sandberg <andreas.sandberg@arm.com>
Tested-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/1429880765-5558-1-git-send-email-andreas.sandberg@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[bwh: Backported to 3.16 as dependency of commit b9023b91dd02
"tick: broadcast-hrtimer: Fix a race in bc_set_next"]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit b8a62f1ff0ccb18fdc25c6150d1cd394610f4753 upstream.
The assignment of bc_moved in the conditional construct relies on the
fact that in the case of hrtimer_start() invocation the return value
is always 0. It took me a while to understand it.
We want to get rid of the hrtimer_start() return value. Open code the
logic which makes it readable as well.
Change-Id: Ieca53b0b6ba6f94567329196da2e94f8c6b0fa09
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/20150414203503.404751457@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[bwh: Backported to 3.16 to ease backporting commit b9023b91dd02
"tick: broadcast-hrtimer: Fix a race in bc_set_next"]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit a127d2bcf1fbc8c8e0b5cf0dab54f7d3ff50ce47 upstream.
The hrtimer mode of broadcast queues hrtimers in the idle entry
path so as to wakeup cpus in deep idle states. The associated
call graph is :
cpuidle_idle_call()
|____ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, ....))
|_____tick_broadcast_set_event()
|____clockevents_program_event()
|____bc_set_next()
The hrtimer_{start/cancel} functions call into tracing which uses RCU.
But it is not legal to call into RCU in cpuidle because it is one of the
quiescent states. Hence protect this region with RCU_NONIDLE which informs
RCU that the cpu is momentarily non-idle.
As an aside it is helpful to point out that the clock event device that is
programmed here is not a per-cpu clock device; it is a
pseudo clock device, used by the broadcast framework alone.
The per-cpu clock device programming never goes through bc_set_next().
Change-Id: If3ee2d37d773e23a4a145c17fa4e1e1cd31c74cf
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: linuxppc-dev@ozlabs.org
Cc: mpe@ellerman.id.au
Cc: tglx@linutronix.de
Link: http://lkml.kernel.org/r/20150318104705.17763.56668.stgit@preeti.in.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
commit cddd02489f52ccf635ed65931214729a23b93cd6 upstream.
In lowres mode, hrtimers are serviced by the tick instead of a clock
event. Now it works well as long as the tick stays periodic but we
must also make sure that the hrtimers are serviced in dynticks mode.
Part of that job consist in kicking a dynticks hrtimer target in order
to make it reconsider the next tick to schedule to correctly handle the
hrtimer's expiring time. And that part isn't handled by the hrtimers
subsystem.
To prepare for fixing this, we need __hrtimer_start_range_ns() to be
able to resolve the CPU target associated to a hrtimer's object
'cpu_base' so that the kick can be centralized there.
So lets store it in the 'struct hrtimer_cpu_base' to resolve the CPU
without overhead. It is set once at CPU's online notification.
Change-Id: I8e1869072756fe412c212f2da0a252ced5f44441
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/1403393357-2070-4-git-send-email-fweisbec@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[bwh: Backported to 3.16 as dependency of commit b9023b91dd02
"tick: broadcast-hrtimer: Fix a race in bc_set_next":
- Adjust filename, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
The hrtimer mode of broadcast is supported only when
GENERIC_CLOCKEVENTS_BROADCAST and TICK_ONESHOT config options
are enabled. Hence compile in the functions for hrtimer mode
of broadcast only when these options are selected.
Also fix max_delta_ticks value for the pseudo clock device.
Change-Id: I637aafb2e5df14916d8e673f8333af0e1662d1bb
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/52F719EE.9010304@linux.vnet.ibm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[ Upstream commit ef8d8ccdc216f797e66cb4a1372f5c4c285ce1e4 ]
As Jason Baron explained in commit 790ba4566c1a ("tcp: set SOCK_NOSPACE
under memory pressure"), it is crucial we properly set SOCK_NOSPACE
when needed.
However, Jason patch had a bug, because the 'nonblocking' status
as far as sk_stream_wait_memory() is concerned is governed
by MSG_DONTWAIT flag passed at sendmsg() time :
long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);
So it is very possible that tcp sendmsg() calls sk_stream_wait_memory(),
and that sk_stream_wait_memory() returns -EAGAIN with SOCK_NOSPACE
cleared, if sk->sk_sndtimeo has been set to a small (but not zero)
value.
This patch removes the 'noblock' variable since we must always
set SOCK_NOSPACE if -EAGAIN is returned.
It also renames the do_nonblock label since we might reach this
code path even if we were in blocking mode.
Fixes: 790ba4566c1a ("tcp: set SOCK_NOSPACE under memory pressure")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jason Baron <jbaron@akamai.com>
Reported-by: Vladimir Rutsky <rutsky@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I28920747f7b8ad326178970262cb59b13857ca71
Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
triggers following stack trace:
[25244.848046] kernel BUG at ./include/linux/skbuff.h:1406!
[25244.859335] RIP: 0010:skb_queue_prev+0x9/0xc
[25244.888167] Call Trace:
[25244.889182] <IRQ>
[25244.890001] tcp_fragment+0x9c/0x2cf
[25244.891295] tcp_write_xmit+0x68f/0x988
[25244.892732] __tcp_push_pending_frames+0x3b/0xa0
[25244.894347] tcp_data_snd_check+0x2a/0xc8
[25244.895775] tcp_rcv_established+0x2a8/0x30d
[25244.897282] tcp_v4_do_rcv+0xb2/0x158
[25244.898666] tcp_v4_rcv+0x692/0x956
[25244.899959] ip_local_deliver_finish+0xeb/0x169
[25244.901547] __netif_receive_skb_core+0x51c/0x582
[25244.903193] ? inet_gro_receive+0x239/0x247
[25244.904756] netif_receive_skb_internal+0xab/0xc6
[25244.906395] napi_gro_receive+0x8a/0xc0
[25244.907760] receive_buf+0x9a1/0x9cd
[25244.909160] ? load_balance+0x17a/0x7b7
[25244.910536] ? vring_unmap_one+0x18/0x61
[25244.911932] ? detach_buf+0x60/0xfa
[25244.913234] virtnet_poll+0x128/0x1e1
[25244.914607] net_rx_action+0x12a/0x2b1
[25244.915953] __do_softirq+0x11c/0x26b
[25244.917269] ? handle_irq_event+0x44/0x56
[25244.918695] irq_exit+0x61/0xa0
[25244.919947] do_IRQ+0x9d/0xbb
[25244.921065] common_interrupt+0x85/0x85
[25244.922479] </IRQ>
tcp_rtx_queue_tail() (called by tcp_fragment()) can call
tcp_write_queue_prev() on the first packet in the queue, which will trigger
the BUG in tcp_write_queue_prev(), because there is no previous packet.
This happens when the retransmit queue is empty, for example in case of a
zero window.
Commit 8c3088f895a0 ("tcp: be more careful in tcp_fragment()") was not a
simple cherry-pick of the original one from master (b617158dc096)
because there is a specific TCP rtx queue only since v4.15. For more
details, please see the commit message of b617158dc096 ("tcp: be more
careful in tcp_fragment()").
The BUG() is hit due to the specific code added to versions older than
v4.15. The comment in skb_queue_prev() (include/linux/skbuff.h:1406),
just before the BUG_ON() somehow suggests to add a check before using
it, what Tim did.
In master, this code path causing the issue will not be taken because
the implementation of tcp_rtx_queue_tail() is different:
tcp_fragment() → tcp_rtx_queue_tail() → tcp_write_queue_prev() →
skb_queue_prev() → BUG_ON()
Fixes: 8c3088f895a0 ("tcp: be more careful in tcp_fragment()")
Signed-off-by: Tim Froidcoeur <tim.froidcoeur@tessares.net>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Reviewed-by: Christoph Paasch <cpaasch@apple.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: Icd3dbde6043a7d09ac437c0aefd115c482845290
Currently variable "tid" is from message, which is used
directly as array size which causes buffer over-write.
To address this issue add check for the array size in the
ol_rx_delba_handler & ol_rx_pn_ind_handler.
Change-Id: I39e5d9c5315a2bf9f34a65651025a1d8fc919c28
CRs-Fixed: 2178818
It looks like there is a possibility of a double-free vulnerability on an
error path of the f_midi_set_alt function in the f_midi driver. If the
path is feasible then free_ep_req gets called twice:
req->complete = f_midi_complete;
err = usb_ep_queue(midi->out_ep, req, GFP_ATOMIC);
=> ...
usb_gadget_giveback_request
=>
f_midi_complete (CALLBACK)
(inside f_midi_complete, for various cases of status)
free_ep_req(ep, req); // first kfree
if (err) {
ERROR(midi, "%s: couldn't enqueue request: %d\n",
midi->out_ep->name, err);
free_ep_req(midi->out_ep, req); // second kfree
return err;
}
The double-free possibility was introduced with commit ad0d1a058eac
("usb: gadget: f_midi: fix leak on failed to enqueue out requests").
Found by MOXCAFE tool.
Signed-off-by: Tuba Yavuz <tuba@ece.ufl.edu>
Fixes: ad0d1a058eac ("usb: gadget: f_midi: fix leak on failed to enqueue out requests")
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I93342475b7e72ae44fed7d7c8f92d5f8dbf53c8a
This ensures that the midi function will only work if the proper number of
IN and OUT requrests are allocated. Otherwise the function will work with less
requests then what the user wants.
Change-Id: If5964d44ebd1dfc7e705c7695ce9d12f83007cd2
Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch fixes a memory leak that occurs when an endpoint fails to enqueue
the request. If that happens the complete function will never be called, thus
never freeing the request.
Signed-off-by: Felipe F. Tonello <eu@felipetonello.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Change-Id: Ia0bcb5cbb7db7adb920402340f7ae658e2d32ae7
CV: Propagate from qcacld3.0 to qcacld2.0:
- fill_ieee80211_hdr_data doesn't exist, it's just a code snippet inside
process_tx_info.
- pl_msdu_info->num_msdu -> pl_msdu_info.num_msdu.
- QDF_TRACE -> adf_os_print.
- qdf_assert -> adf_os_assert.
Currently variable pl_msdu_info->num_msdu is from message, and
is used directly as array size. This may cause buffer overflow.
To address this issue add qdf_assert check.
Change-Id: Ice78633314b321243136ce4987c633e1201d3cb8
CRs-Fixed: 2187441
Signed-off-by: Corinna Vinschen <xda@vinschen.de>
Check if the handle data_type received from userspace is valid
for app loaded query request to avoid the offset boundary check
for qseecom_send_modfd_resp is bypassed.
Change-Id: I5f3611a8f830d6904213781c5ba70cfc0ba3e2e0
Signed-off-by: Zhen Kong <zkong@codeaurora.org>
validate structures and payload sizes in the
packet against packet size to avoid OOB access.
Change-Id: I3749ae5d322140c98eb0227cfa31ab32459fc492
Signed-off-by: Manikanta Kanamarlapudi <kmanikan@codeaurora.org>
Signed-off-by: Sanjay Singh <sisanj@codeaurora.org>
Add mutex lock to protect private data in _put() and
get() calls.
Change-Id: I776ba5739fec4f1ff6542ef48de79ad3873f1161
Signed-off-by: Soumya Managoli <smanag@codeaurora.org>
Add mutex lock to protect private data in _put() and
get() calls.
Change-Id: I92f5a6515b6d1c4ad650a7dcf22a0a231a84dd30
Signed-off-by: Soumya Managoli <smanag@codeaurora.org>
At start axi stream, we are acquiring the
buffer lock and releasing after completing
the stream configuration operations. In case
of live snapshot,this is causing the buffer
operations to halt and leading to sof freeze.
Change-Id: I2a3d05742e0cc8921787516c6d444937047c1fef
CRs-Fixed: 2149998
Signed-off-by: Meera Gande <mgande@codeaurora.org>
Signed-off-by: Vijay Kumar TM <vtmuni@codeaurora.org>
Signed-off-by: Darshan Kumsi Srinivasa <darssr@codeaurora.org>
syphyr
Chaoli Zhou
Rajeev Kumar Sirasanagandla
c_manjee
Paras Nagda
gaolez
Zhang Qian
hqu
bings
Theodore Ts'o
Andy Shevchenko
Eric Dumazet
VijayaKumar T M
Florian Westphal
Priyanka Gujjula
Jann Horn
Wenwen Wang
Takashi Iwai
Dan Carpenter
Suren Baghdasaryan
Xiaojun Sang
Hardik Arya
Lihua Liu
Tiger Yu
Will Huang
Alok Kumar
Miaoqing Pan
Paul Zhang
Balasubramani Vivekanandan
Andreas Sandberg
Thomas Gleixner
Preeti U Murthy
Viresh Kumar
Tim Froidcoeur
Yavuz, Tuba
Felipe F. Tonello
Zhen Kong
Sanjay Singh
Soumya Managoli