Adding fix to check the upper limit on the length
of the destination array while copying elements from
source address to avoid stack out of bound error.
Change-Id: I783f8ab3eb5a94cf503f831df8325c214ca710e4
Signed-off-by: Tanwee Kausar <tkausar@codeaurora.org>
Adding fix to check the upper limit on the length
of the destination array while copying elements from
source address to avoid stack out of bound error.
Change-Id: Ieb24e8f9b4a2b53fbc9442b25d790b12f737d471
Signed-off-by: Tanwee Kausar <tkausar@codeaurora.org>
commit 3dc289f8f139997f4e9d3cfccf8738f20d23e47b upstream.
In nl80211_parse_key(), key.idx is first initialized as -1.
If this value of key.idx remains unmodified and gets returned, and
nl80211_key_allowed() also returns 0, then rdev_del_key() gets called
with key.idx = -1.
This causes an out-of-bounds array access.
Handle this issue by checking if the value of key.idx after
nl80211_parse_key() is called and return -EINVAL if key.idx < 0.
Change-Id: Ie00275076bb4ee6a31d0e59b4b0e477ae732327d
Cc: stable@vger.kernel.org
Reported-by: syzbot+b1bb342d1d097516cbda@syzkaller.appspotmail.com
Tested-by: syzbot+b1bb342d1d097516cbda@syzkaller.appspotmail.com
Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Link: https://lore.kernel.org/r/20201007035401.9522-1-anant.thazhemadam@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It is not allowed to enable high speed support when Secure Simple
Pairing is not available or disabled.
However the support for high speed gets advertised on a controller
that does not even support Secure Simple Pairing. Since there is
no way to enable high speed support on such a controller, do not
even advertise its support.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Change-Id: I31a94ba5e41f4e45b32b2ca5db6a17f24688f711
[CV: backported to 3.10]
Signed-off-by: Corinna Vinschen <xda@vinschen.de>
commit b560a208cda0297fef6ff85bbfd58a8f0a52a543 upstream.
This checks if BT_HS is enabled relecting it on MGMT_SETTING_HS instead
of always reporting it as supported.
Change-Id: I765cd569da2ca946c8cf5728dc91901813015d9c
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eddb7732119d53400f48a02536a84c509692faa8 upstream.
This fixes various places where a stack variable is used uninitialized.
Change-Id: I5dd74e73b332a5762f1b2a32084c1e9a1e0d584d
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit acf69c946233259ab4d64f8869d4037a198c7f06 upstream.
Using tp_reserve to calculate netoff can overflow as
tp_reserve is unsigned int and netoff is unsigned short.
This may lead to macoff receving a smaller value then
sizeof(struct virtio_net_hdr), and if po->has_vnet_hdr
is set, an out-of-bounds write will occur when
calling virtio_net_hdr_from_skb.
The bug is fixed by converting netoff to unsigned int
and checking if it exceeds USHRT_MAX.
This addresses CVE-2020-14386
Fixes: 8913336a7e ("packet: add PACKET_RESERVE sockopt")
Signed-off-by: Or Cohen <orcohen@paloaltonetworks.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[ snu: backported to pre-5.3, changed tp_drops counting/locking ]
Signed-off-by: Stefan Nuernberger <snu@amazon.com>
CC: David Woodhouse <dwmw@amazon.co.uk>
CC: Amit Shah <aams@amazon.com>
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Id70a19d5550c27f8527f95b2a838d53e3bb73ffb
When VM_MAYWRITE flag is used during mmap(), mprotect()
can be used later to change the protection of memstore
to allow write. Make sure this does not happen by
removing VM_MAYWRITE from the vm_flags of vma.
Change-Id: I6f69f05858ea40611d512cfa796caabeaa88cdb5
Signed-off-by: Indira Biruduraju <ibirudur@codeaurora.org>
In kgsl_ioctl_gpuobj_import(), user memory of type KGSL_USER_MEM_TYPE_ADDR
can also lead to setting up a dma buffer. When attaching mem entry to
process fails, dma buffer attachment is cleaned up only in case of
KGSL_USER_MEM_TYPE_DMABUF. Similar situation can arise in case of
kgsl_ioctl_map_user_mem(). Fix this by obtaining user memory type from
the memdesc flags.
Change-Id: I502bd0ae19241802e8f835f20391b2ce67999418
Signed-off-by: Puranam V G Tejaswi <pvgtejas@codeaurora.org>
Initialize preauth node memory after allocated to
avoid invalid content being used in protocol stack.
Change-Id: Id66fee1bd3684aff2d94108c2b864e3f458fe7c0
CRs-Fixed: 2701488
If quota is precisely equal to skb->len then a notification
would not be sent due to immediately hitting 0.
This fixes that, and takes the opportunity to slightly clean
up the code and make quota behave more correctly for packet mode
as well.
Test: builds, net tests continue to pass
Bug: 164336990
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I78a11b48794496255513a6226c0469d809d7aa56
(cherry picked from commit b20eacd8ddbd1dbf403df94f5ba6384e6fef0113)
[ Upstream commit 5bf9917452112694b2c774465ee4dbe441c84b77 ]
vm_map_ram can keep mappings around after the vm_unmap_ram. Using that
with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: Gao Xiang <xiang@kernel.org>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Paul Mackerras <paulus@ozlabs.org>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Will Deacon <will@kernel.org>
Link: http://lkml.kernel.org/r/20200414131348.444715-4-hch@lst.de
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I10e16b456cad271b6e12b6bec9425392aa71b6c0
Ratelimit log in msm_vb2_buf_cleanup to prevent excessive logging when
stream is NULL.
Change-Id: Ia687375c8e2a2683a4d32cd0eb984f731b2288e7
Signed-off-by: Trishansh Bhardwaj <tbhardwa@codeaurora.org>
The camera generic buffer manager and isp buffer
manager keep references of vb2 buffers locally during
buffer circulation. If for some reason the vb2 buffers
are freed from a cleanup call from mediaserver. The memory
for the buffers is freed. But the camera buffer managers
still access them for a fraction of time before the cleanup
call is triggered from daemon process. Hence make sure
to access the vb2 buffers only after checking for
the existence in vb2 queues to avoid memory corruption.
Change-Id: I7a1e5f9a3af3345e0c37d3208facbab107a6b9ed
Signed-off-by: Lakshmi Narayana Kalavala <lkalaval@codeaurora.org>
A race condition between threads updating mountpoint reference counter
affects longterm releases 4.4.220, 4.9.220, 4.14.177 and 4.19.118.
The mountpoint reference counter corruption may occur when:
* one thread increments m_count member of struct mountpoint
[under namespace_sem, but not holding mount_lock]
pivot_root()
* another thread simultaneously decrements the same m_count
[under mount_lock, but not holding namespace_sem]
put_mountpoint()
unhash_mnt()
umount_mnt()
mntput_no_expire()
To fix this race condition, grab mount_lock before updating m_count in
pivot_root().
Reference: CVE-2020-12114
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Piotr Krysiuk <piotras@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Change-Id: I2b2cfdbf6529c9d72d54738db6169dd421eb1f51
`check_input_term` recursively calls itself with input from
device side (e.g., uac_input_terminal_descriptor.bCSourceID)
as argument (id). In `check_input_term`, if `check_input_term`
is called with the same `id` argument as the caller, it triggers
endless recursive call, resulting kernel space stack overflow.
This patch fixes the bug by adding a bitmap to `struct mixer_build`
to keep track of the checked ids and stop the execution if some id
has been checked (similar to how parse_audio_unit handles unitid
argument).
Change-Id: Ibc4ab23c7d7c2fc96ff85d7cf1a1205bbd632cb5
Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
Signed-off-by: Hui Peng <benquike@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Default security rule is freed while it is being used to check
security permission in ipcrtr send api. This results in use
after free case.
Default security rule should not be changed, removing the code
to change default rule from user space.
CRs-Fixed: 2591650
Change-Id: I08788102a0748b6bc72cb3c77b46de2d65ede91d
Signed-off-by: Deepak Kumar Singh <deesin@codeaurora.org>
Propagation from qcacld-3.0 to qcacld-2.0
Check for the minimum allowed data that can be written into
the buffer param_buf->num_wow_packet_buffer in the function
wma_process_utf_event.
Change-Id: I8b83bc973fd6f0d7ad9e421a387ce3f03d6b6939
CRs-Fixed: 2379462
When unloading the app, reset all client members to NULL
to protect from accessing the memory after being freed.
Change-Id: I573b9c6fde03539522d2b04724a2246660c62518
Signed-off-by: jitendra thakare <jitendrathakare@codeaurora.org>
If request_key() is used to find a keyring, only do the search part - don't
do the construction part if the keyring was not found by the search. We
don't really want keyrings in the negative instantiated state since the
rejected/negative instantiation error value in the payload is unioned with
keyring metadata.
Now the kernel gives an error:
request_key("keyring", "#selinux,bdekeyring", "keyring", KEY_SPEC_USER_SESSION_KEYRING) = -1 EPERM (Operation not permitted)
Signed-off-by: David Howells <dhowells@redhat.com>
CVE-2015-7872
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I3603fec8fab929d7636d7223901f16dc8d8026cc
In function rrm_fill_beacon_ies, do while loop is checked
for BcnNumIes if it is greater than IE length 0. Fix the
check to be greater than 2 as the first two bytes is IE
header(element ID and IE length fields both 1 byte each.)
Change-Id: I11e5de481cd49a22acafee938fbe73f839f5b0e4
CRs-Fixed: 2635664
commit d9d4b1e46d9543a82c23f6df03f4ad697dab361b upstream.
The syzbot fuzzer found a slab-out-of-bounds write bug in the hid-gaff
driver. The problem is caused by the driver's assumption that the
device must have an input report. While this will be true for all
normal HID input devices, a suitably malicious device can violate the
assumption.
The same assumption is present in over a dozen other HID drivers.
This patch fixes them by checking that the list of hid_inputs for the
hid_device is nonempty before allowing it to be used.
Reported-and-tested-by: syzbot+403741a091bf41d4ae79@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@vger.kernel.org>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ica4d1b6adc1bcb30ce077f7d954cb8ba94bce730
commit fa3a5a1880c91bb92594ad42dfe9eedad7996b86 upstream.
No timer must be left running when the device goes away.
Change-Id: Icd16bfab1811857f77e026577f340ad072aadab0
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Reported-and-tested-by: syzbot+b6c55daa701fc389e286@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/1573726121.17351.3.camel@suse.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
"ALSA: timer: Handle disconnection more safely" was applied
after "ALSA: timer: Fix race at concurrent reads", which
left a break in place of the correct goto _error.
Fix that.
Thanks to Elektroschmock <elektroschmock78@googlemail.com> for
pointing out the problem.
Change-Id: I85252c1d40c4bd88ca86fa8c0bb228d7ed6b12ed
Signed-off-by: Corinna Vinschen <xda@vinschen.de>
commit daac07156b330b18eb5071aec4b3ddca1c377f2c upstream.
The `uac_mixer_unit_descriptor` shown as below is read from the
device side. In `parse_audio_mixer_unit`, `baSourceID` field is
accessed from index 0 to `bNrInPins` - 1, the current implementation
assumes that descriptor is always valid (the length of descriptor
is no shorter than 5 + `bNrInPins`). If a descriptor read from
the device side is invalid, it may trigger out-of-bound memory
access.
```
struct uac_mixer_unit_descriptor {
__u8 bLength;
__u8 bDescriptorType;
__u8 bDescriptorSubtype;
__u8 bUnitID;
__u8 bNrInPins;
__u8 baSourceID[];
}
```
This patch fixes the bug by add a sanity check on the length of
the descriptor.
Change-Id: Ifa5b3c5177dd5a3c93e4523516014664313e7523
Reported-by: Hui Peng <benquike@gmail.com>
Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
Signed-off-by: Hui Peng <benquike@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
commit 04f5866e41fb70690e28397487d8bd8eea7d712a upstream.
The core dumping code has always run without holding the mmap_sem for
writing, despite that is the only way to ensure that the entire vma
layout will not change from under it. Only using some signal
serialization on the processes belonging to the mm is not nearly enough.
This was pointed out earlier. For example in Hugh's post from Jul 2017:
https://lkml.kernel.org/r/alpine.LSU.2.11.1707191716030.2055@eggly.anvils
"Not strictly relevant here, but a related note: I was very surprised
to discover, only quite recently, how handle_mm_fault() may be called
without down_read(mmap_sem) - when core dumping. That seems a
misguided optimization to me, which would also be nice to correct"
In particular because the growsdown and growsup can move the
vm_start/vm_end the various loops the core dump does around the vma will
not be consistent if page faults can happen concurrently.
Pretty much all users calling mmget_not_zero()/get_task_mm() and then
taking the mmap_sem had the potential to introduce unexpected side
effects in the core dumping code.
Adding mmap_sem for writing around the ->core_dump invocation is a
viable long term fix, but it requires removing all copy user and page
faults and to replace them with get_dump_page() for all binary formats
which is not suitable as a short term fix.
For the time being this solution manually covers the places that can
confuse the core dump either by altering the vma layout or the vma flags
while it runs. Once ->core_dump runs under mmap_sem for writing the
function mmget_still_valid() can be dropped.
Allowing mmap_sem protected sections to run in parallel with the
coredump provides some minor parallelism advantage to the swapoff code
(which seems to be safe enough by never mangling any vma field and can
keep doing swapins in parallel to the core dumping) and to some other
corner case.
In order to facilitate the backporting I added "Fixes: 86039bd3b4e6"
however the side effect of this same race condition in /proc/pid/mem
should be reproducible since before 2.6.12-rc2 so I couldn't add any
other "Fixes:" because there's no hash beyond the git genesis commit.
Because find_extend_vma() is the only location outside of the process
context that could modify the "mm" structures under mmap_sem for
reading, by adding the mmget_still_valid() check to it, all other cases
that take the mmap_sem for reading don't need the new check after
mmget_not_zero()/get_task_mm(). The expand_stack() in page fault
context also doesn't need the new check, because all tasks under core
dumping are frozen.
Link: http://lkml.kernel.org/r/20190325224949.11068-1-aarcange@redhat.com
Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization")
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Reported-by: Jann Horn <jannh@google.com>
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Jann Horn <jannh@google.com>
Acked-by: Jason Gunthorpe <jgg@mellanox.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.16:
- Drop changes in Infiniband and userfaultfd
- In clear_refs_write(), use up_read() as we never upgrade to a write lock
- Adjust filename, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[haggertk: Backport to android/3.4
- Re-add changes to binder_update_page_range()
- Drop changes to task_mmu. We don't have soft-dirty bits]
CVE-2019-11599
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Ie1dcffd91ea896688e11c9729243e15461eee1a4
In function rrmFillBeaconIes, the total IE length is calculated
as sum of length field of the IE and 2 (element id 1 bytr and IE
length field 1 byte). The total IE length is defined of type
uint16_t and will overflow if the *(pBcnIes + 1) = 0xfe.
Validate the len against total IE length to avoid overfloa.
Change-Id: If8f86952ce43c5923906fc6ef18705f1785c5d88
CRs-Fixed: 2617005
Propagation from qcacld-3.0 to qcacld-2.0
When host sends ft assoc response to supplicant, it
allocates a buffer of fixed size and copies a variable
length of assoc response IEs to this fixed sized buffer.
There is a possibility of OOB write to the allocated buffer
if the assoc response IEs length is greater than the
allocated buffer size.
To avoid above issue validate the assoc response IEs length
with the allocated buffer size before data copy to the buffer.
Change-Id: I7f9998c4964bfb38a493d76954e00197aada1986
CRs-Fixed: 2616227
Propagate from qcacld3.0 to qcacld2.0
When host sends assoc response to supplicant, it
allocates a buffer of fixed size and copies a variable
length of assoc response IEs to this fixed sized buffer.
There is a possibility of OOB write to the allocated buffer
if the assoc response IEs length is greater than the
allocated buffer size.
To avoid above issue validate the assoc response IEs length
with the allocated buffer size before data copy to the buffer.
Change-ID: Ib12385e9ff04e5172ae8b505faf959e426fda439
CRs-Fixed: 2616229
Channels 5150-5350 are INDOOR only channels for Japan.
Modify the Japan regulatory rules accordingly.
CRs-Fixed: 886169
Change-Id: Ied8c87131f38121ddb3173c565bcbe2740ce9528
Signed-off-by: Amar Singhal <asinghal@codeaurora.org>
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>