[ 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>
In the code, start_fetch can try to access the
buffer pointer variable after free, as the
same pointer can be freed at RELEASE_BUF call at
the same time.
Change-Id: Ic83f22336504cf67afe12131f791eee25477f011
Signed-off-by: Meera Gande <mgande@codeaurora.org>
Signed-off-by: Darshan Kumsi Srinivasa <darssr@codeaurora.org>
There is race condition around private data used in put() and get()
of few mixer ctls with close() callback.Add global mutex lock and
code changes to protect such critical section by accessing such lock.
Change-Id: I276c2a234cfcbef88b4272b945e5c3f121e8eb32
Signed-off-by: Soumya Managoli <smanag@codeaurora.org>
In the API, the driver inserts 0 after the SSID name, to mark the
end of the ssid, but if the SSID name is 32 characters which is
the max SSID length possible, the driver puts 0 at the 33rd
place of memory which is not the part of the SSID name, which
results in OOB write, or off-by-one write condition.
Fix is to remove the addition of 0 after ssid, as in every
case the driver prints the ssid, taking the ssid length
as the input, and in that case insertion of 0 will not serve
any purpose.
Change-Id: I1d58026ec9f48fe9d00bd2f50783c65899588978
CRs-Fixed: 2541970
In the function ConvertWscOpaque, driver does copy of the
new parameters present in the additional IEs of the upstream
assoc request frame. While copy of the IE length pOld->length to
curAddIELen, possible integer truncation could occur, as the
curAddIELen is of the type tANI_U8 whereas pOld->length is of
type tANI_U16.
Change the data type of curAddIELen to tANI_U16. Make changes in
ConvertP2POpaque and ConvertWFDOpaque as well.
Change-Id: Ic26660fca4a02a265bfc9553b066c7ee42f1d1f4
CRs-Fixed: 2528392
Currently, capabilities suBeamformeeCap and muBeamformeeCap are set
during association request but not in re-association request. This
can lead to failure in beamforming after roaming. Fix this by updating
them during roaming as well.
Change-Id: I28e86b93a5114f3b76733effe4428a92cf94b441
CRs-Fixed: 1033328
Fix the index error of chanBondingSet element. If not, the channel list
[116,120,124,128] will be ingored to consider adding into the available
channels, when channel bonding is set as 40/80Mhz during sapRandomChannelSel
stage.
Change-Id: Ia90ece227c32fd9aad4a3cb69372e9cb8cf981a8
CRs-Fixed: 1037612
It's a fix for sns issue. Set DUT as sap, ref client sends assoc req
to DUT and as part of this frame processing lim does ADD_STA and posts
eWNI_SME_ASSOC_IND to sme layer. Before SME layer sends eWNI_SME_ASSOC_CNF,
DUT receives auth frame which triggers deauth. In this case lim layer
will delete ref client's related info, but wma layer doesn't get any
notification.
To fix this lim has to notify wma to do DEL_STA for that peer.
Change-Id: Id4aae51aae3fb68e752d09793ad3bce17665fc2e
CRs-Fixed: 979687
When leave ibss is called, disconnect ibss command is posted to
SME and leave ibss function returns without waiting for disconnect
to get complete.
Now if unload is started before ibss disconnect is completed, as
part of stop adapter again ibss disconnect command is posted to SME
as HDD state is still not disconnected.
The first disconnect sets the BSSID to zero and thus once second
disconnect calls disconnect handler, warning is seen as BSSID passed
to ipa event handler is zero.
As part of fix add wait for disconnect completion in leave ibss and
move the BSSID check after SAP device mode check.
Change-Id: I83cdac1514833d21aa19052cde9b32476348f0c4
CRs-Fixed: 1017319
wma_ibss_peer_info_event_handler returns error when peer_info is NULL.
However, peer_info can be NULL in case num_peers connected is 0.
Handle this case in hdd_get_ibss_peer_info_cb so that callers of
GETIBSSPEERINFOALL do not see stale results after all connected peers
have left the IBSS. Also, log the errors for enabling debug and reset
the ibss_peer_info statistics.
CRs-Fixed: 1007555
Change-Id: I913748bf11f9362e5faaaf29c26fc39fda85f4a9
Presently the Roam Scan Offload commands(Start/Restart/Stop etc) are all
sent directly from CSR to WDA. This fix reroutes these commands to LIM
and send them to WDA from there so that any session specific data
can be updated on this RSO command exchange. "roaming_in_progress"
is a PE session parameter which needs to be reset for STOP/START/RESTART
commands. If not even though firmware sends KICK STA event driver wont
disconnect from AP
Change-Id: I86c3b93570a38329cbc6a8a31017ece172164732
CRs-fixed: 1009486
During P2P functionality, Host will send GO NEG REQ and
receives ACK completion from firmware which will be queued
to indicate HDD. Meanwhile if host receives GO-NEG RESP it
will be sent directly to HDD via function callback. In HDD as
we got GO NEG RESP before ACK completion for GO-NEG REQ, HDD
will generate pkt completion for GO NEG Request.
Now GO NEG CONFORMATION frame will be sent and driver will be
expecting completion for this. The GO NEG REQ ACK completion
which got buffered in PE will be delivered to Supplicant and
Supplicant assumes that this is the ACK for GO NEG CONF frame.
This causes early termination of remain on channel due to which
firmware may drop the GO NEG CONF frame and may not retry as ROC
is terminated.
Fix this by making ACK Completion indication to HDD via function
callback.
Change-Id: I0dd3acb236b270839649d2becfdc007e7aae9fdd
CRs-Fixed: 1012547
In function lim_update_ibss_prop_add_ies size of a malloc is based on
sum of two integers. Add check for integer overflow before malloc.
Change-Id: I53ad59f0a38b102d714fa8cfe9471b52935d8376
CRs-Fixed: 2116415
Eric Dumazet
VijayaKumar T M
Florian Westphal
Priyanka Gujjula
Jann Horn
Wenwen Wang
Takashi Iwai
Dan Carpenter
syphyr
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
Meera Gande
Padma, Santhosh Kumar
lifeng
kaliu
Abhishek Singh
Sriram, Madhvapathi
Selvaraj, Sridhar
Masti, Narayanraddi
gaurank kathpalia