This patch (of 6):
The i_mmap_writable field counts existing writable mappings of an
address_space. To allow drivers to prevent new writable mappings, make
this counter signed and prevent new writable mappings if it is negative.
This is modelled after i_writecount and DENYWRITE.
This will be required by the shmem-sealing infrastructure to prevent any
new writable mappings after the WRITE seal has been set. In case there
exists a writable mapping, this operation will fail with EBUSY.
Note that we rely on the fact that iff you already own a writable mapping,
you can increase the counter without using the helpers. This is the same
that we do for i_writecount.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Ryan Lortie <desrt@desrt.ca>
Cc: Lennart Poettering <lennart@poettering.net>
Cc: Daniel Mack <zonque@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If two processes share a common memory region, they usually want some
guarantees to allow safe access. This often includes:
- one side cannot overwrite data while the other reads it
- one side cannot shrink the buffer while the other accesses it
- one side cannot grow the buffer beyond previously set boundaries
If there is a trust-relationship between both parties, there is no need
for policy enforcement. However, if there's no trust relationship (eg.,
for general-purpose IPC) sharing memory-regions is highly fragile and
often not possible without local copies. Look at the following two
use-cases:
1) A graphics client wants to share its rendering-buffer with a
graphics-server. The memory-region is allocated by the client for
read/write access and a second FD is passed to the server. While
scanning out from the memory region, the server has no guarantee that
the client doesn't shrink the buffer at any time, requiring rather
cumbersome SIGBUS handling.
2) A process wants to perform an RPC on another process. To avoid huge
bandwidth consumption, zero-copy is preferred. After a message is
assembled in-memory and a FD is passed to the remote side, both sides
want to be sure that neither modifies this shared copy, anymore. The
source may have put sensible data into the message without a separate
copy and the target may want to parse the message inline, to avoid a
local copy.
While SIGBUS handling, POSIX mandatory locking and MAP_DENYWRITE provide
ways to achieve most of this, the first one is unproportionally ugly to
use in libraries and the latter two are broken/racy or even disabled due
to denial of service attacks.
This patch introduces the concept of SEALING. If you seal a file, a
specific set of operations is blocked on that file forever. Unlike locks,
seals can only be set, never removed. Hence, once you verified a specific
set of seals is set, you're guaranteed that no-one can perform the blocked
operations on this file, anymore.
An initial set of SEALS is introduced by this patch:
- SHRINK: If SEAL_SHRINK is set, the file in question cannot be reduced
in size. This affects ftruncate() and open(O_TRUNC).
- GROW: If SEAL_GROW is set, the file in question cannot be increased
in size. This affects ftruncate(), fallocate() and write().
- WRITE: If SEAL_WRITE is set, no write operations (besides resizing)
are possible. This affects fallocate(PUNCH_HOLE), mmap() and
write().
- SEAL: If SEAL_SEAL is set, no further seals can be added to a file.
This basically prevents the F_ADD_SEAL operation on a file and
can be set to prevent others from adding further seals that you
don't want.
The described use-cases can easily use these seals to provide safe use
without any trust-relationship:
1) The graphics server can verify that a passed file-descriptor has
SEAL_SHRINK set. This allows safe scanout, while the client is
allowed to increase buffer size for window-resizing on-the-fly.
Concurrent writes are explicitly allowed.
2) For general-purpose IPC, both processes can verify that SEAL_SHRINK,
SEAL_GROW and SEAL_WRITE are set. This guarantees that neither
process can modify the data while the other side parses it.
Furthermore, it guarantees that even with writable FDs passed to the
peer, it cannot increase the size to hit memory-limits of the source
process (in case the file-storage is accounted to the source).
The new API is an extension to fcntl(), adding two new commands:
F_GET_SEALS: Return a bitset describing the seals on the file. This
can be called on any FD if the underlying file supports
sealing.
F_ADD_SEALS: Change the seals of a given file. This requires WRITE
access to the file and F_SEAL_SEAL may not already be set.
Furthermore, the underlying file must support sealing and
there may not be any existing shared mapping of that file.
Otherwise, EBADF/EPERM is returned.
The given seals are _added_ to the existing set of seals
on the file. You cannot remove seals again.
The fcntl() handler is currently specific to shmem and disabled on all
files. A file needs to explicitly support sealing for this interface to
work. A separate syscall is added in a follow-up, which creates files that
support sealing. There is no intention to support this on other
file-systems. Semantics are unclear for non-volatile files and we lack any
use-case right now. Therefore, the implementation is specific to shmem.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Ryan Lortie <desrt@desrt.ca>
Cc: Lennart Poettering <lennart@poettering.net>
Cc: Daniel Mack <zonque@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Angelo G. Del Regno <kholk11@gmail.com>
memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
that you can pass to mmap(). It can support sealing and avoids any
connection to user-visible mount-points. Thus, it's not subject to quotas
on mounted file-systems, but can be used like malloc()'ed memory, but with
a file-descriptor to it.
memfd_create() returns the raw shmem file, so calls like ftruncate() can
be used to modify the underlying inode. Also calls like fstat() will
return proper information and mark the file as regular file. If you want
sealing, you can specify MFD_ALLOW_SEALING. Otherwise, sealing is not
supported (like on all other regular files).
Compared to O_TMPFILE, it does not require a tmpfs mount-point and is not
subject to a filesystem size limit. It is still properly accounted to
memcg limits, though, and to the same overcommit or no-overcommit
accounting as all user memory.
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Ryan Lortie <desrt@desrt.ca>
Cc: Lennart Poettering <lennart@poettering.net>
Cc: Daniel Mack <zonque@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Angelo G. Del Regno <kholk11@gmail.com>
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>
[ 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>
David Herrmann
Liangwei Dong
Maciej Żenczykowski
syphyr
Diogo Ferreira
Christoph Hellwig
Trishansh Bhardwaj
Lakshmi Narayana Kalavala
Ajit Pandey
Piotr Krysiuk
Hui Peng
Deepak Kumar Singh
bings
jitendrathakare
David Howells
Will Huang
Alan Stern
Oliver Neukum
Corinna Vinschen
Andrea Arcangeli
Min Liu
Jingxiang Ge
Amar Singhal
Chaoli Zhou
Rajeev Kumar Sirasanagandla
c_manjee
Paras Nagda
gaolez
Zhang Qian
hqu
Theodore Ts'o
Andy Shevchenko
Eric Dumazet
VijayaKumar T M
Florian Westphal
Priyanka Gujjula
Jann Horn
Wenwen Wang
Takashi Iwai
Dan Carpenter
Suren Baghdasaryan