commit b60fe990c6b07ef6d4df67bc0530c7c90a62623a upstream.
The first/last indexes are typically shared with a user app.
The app can change the 'last' index that the kernel uses
to store the next result. This change sanity checks the index
before using it for writing to a potentially arbitrary address.
This fixes CVE-2019-14821.
Fixes: 5f94c1741b ("KVM: Add coalesced MMIO support (common part)")
Signed-off-by: Matt Delco <delco@chromium.org>
Signed-off-by: Jim Mattson <jmattson@google.com>
Reported-by: syzbot+983c866c3dd6efa3662a@syzkaller.appspotmail.com
[Use READ_ONCE. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[bwh: Backported to 3.16:
- Use ACCESS_ONCE() instead of READ_ONCE()
- kvm_coalesced_mmio_zone::pio field is not supported]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I9e34e14d695dc507757fa215407f0b7ac9445e2b
commit da99466ac243f15fbba65bd261bfc75ffa1532b6 upstream.
This fixes a global out-of-bounds read access in the copy_buffer
function of the floppy driver.
The FDDEFPRM ioctl allows one to set the geometry of a disk. The sect
and head fields (unsigned int) of the floppy_drive structure are used to
compute the max_sector (int) in the make_raw_rw_request function. It is
possible to overflow the max_sector. Next, max_sector is passed to the
copy_buffer function and used in one of the memcpy calls.
An unprivileged user could trigger the bug if the device is accessible,
but requires a floppy disk to be inserted.
The patch adds the check for the .sect * .head multiplication for not
overflowing in the set_geometry function.
The bug was found by syzkaller.
Signed-off-by: Denis Efremov <efremov@ispras.ru>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-14283
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Idb3e900d17920e6339b862419018f4740a7d4caf
commit 3864d33943b4a76c6e64616280e98d2410b1190f upstream.
This driver is using a global variable. It cannot handle more than
one device at a time. The issue has been existing since the dawn
of the driver.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Reported-by: syzbot+35f04d136fc975a70da4@syzkaller.appspotmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-15212
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I96bac47f327839f08944cb047f20e328ed8e3473
commit 5d6751eaff672ea77642e74e92e6c0ac7f9709ab upstream.
The "ev->traffic_class" and "reply->ac" variables come from the network
and they're used as an offset into the wmi->stream_exist_for_ac[] array.
Those variables are u8 so they can be 0-255 but the stream_exist_for_ac[]
array only has WMM_NUM_AC (4) elements. We need to add a couple bounds
checks to prevent array overflows.
I also modified one existing check from "if (traffic_class > 3) {" to
"if (traffic_class >= WMM_NUM_AC) {" just to make them all consistent.
Fixes: bdcd817079 (" Add ath6kl cleaned up driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-15926
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I0bcdbfb3acdbabfe4bc232431a91405155f34771
commit 0c4df39e504bf925ab666132ac3c98d6cbbe380b upstream.
Ensure we do not access the buffer beyond the end if no 0xff byte
is encountered.
Reported-by: syzbot+eaaaf38a95427be88f4b@syzkaller.appspotmail.com
Signed-off-by: Sean Young <sean@mess.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
[bwh: Backported to 3.16: technisat_usb2_get_ir() still uses a stack
buffer, which is not worth fixing on this branch]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-15505
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I9561df3437dec3d0bd2770c1f831d68bb26a9a6e
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.
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>
CVE-2019-15117
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I4173c102a7f0752d8113823f5070ccb7de5f8914
commit df453700e8d81b1bdafdf684365ee2b9431fb702 upstream.
According to Amit Klein and Benny Pinkas, IP ID generation is too weak
and might be used by attackers.
Even with recent net_hash_mix() fix (netns: provide pure entropy for net_hash_mix())
having 64bit key and Jenkins hash is risky.
It is time to switch to siphash and its 128bit keys.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Amit Klein <aksecurity@gmail.com>
Reported-by: Benny Pinkas <benny@pinkas.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-10638
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I607618745f8725e7318ec60e470a77bf0e53df8b
commit 5a352dd0a3aac03b443c94828dfd7144261c8636 upstream.
As namespaces are sometimes used with overlapping ip address ranges,
we should also use the namespace as input to the hash to select the ip
fragmentation counter bucket.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I4cd053112b178ddb0e0efbd1282478075dd064cb
commit 926a882f6916fd76b6f8ee858d45a2241c5e7999 upstream.
The socket parameter might legally be NULL, thus sock_net is sometimes
causing a NULL pointer dereference. Using net_device pointer in dst_entry
is more reliable.
Fixes: b6a7719aedd7e5c ("ipv4: hash net ptr into fragmentation bucket selection")
Reported-by: Rick Jones <rick.jones2@hp.com>
Cc: Rick Jones <rick.jones2@hp.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I7492f0e579973198c292195b36ca9475bf7f5bb3
commit b6a7719aedd7e5c0f2df7641aa47386111682df4 upstream.
As namespaces are sometimes used with overlapping ip address ranges,
we should also use the namespace as input to the hash to select the ip
fragmentation counter bucket.
Cc: Eric Dumazet <edumazet@google.com>
Cc: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I7d76a6f5820ae05a159c8207fe52a6e58db6f024
commit 2c956a60778cbb6a27e0c7a8a52a91378c90e1d1 upstream.
SipHash is a 64-bit keyed hash function that is actually a
cryptographically secure PRF, like HMAC. Except SipHash is super fast,
and is meant to be used as a hashtable keyed lookup function, or as a
general PRF for short input use cases, such as sequence numbers or RNG
chaining.
For the first usage:
There are a variety of attacks known as "hashtable poisoning" in which an
attacker forms some data such that the hash of that data will be the
same, and then preceeds to fill up all entries of a hashbucket. This is
a realistic and well-known denial-of-service vector. Currently
hashtables use jhash, which is fast but not secure, and some kind of
rotating key scheme (or none at all, which isn't good). SipHash is meant
as a replacement for jhash in these cases.
There are a modicum of places in the kernel that are vulnerable to
hashtable poisoning attacks, either via userspace vectors or network
vectors, and there's not a reliable mechanism inside the kernel at the
moment to fix it. The first step toward fixing these issues is actually
getting a secure primitive into the kernel for developers to use. Then
we can, bit by bit, port things over to it as deemed appropriate.
While SipHash is extremely fast for a cryptographically secure function,
it is likely a bit slower than the insecure jhash, and so replacements
will be evaluated on a case-by-case basis based on whether or not the
difference in speed is negligible and whether or not the current jhash usage
poses a real security risk.
For the second usage:
A few places in the kernel are using MD5 or SHA1 for creating secure
sequence numbers, syn cookies, port numbers, or fast random numbers.
SipHash is a faster and more fitting, and more secure replacement for MD5
in those situations. Replacing MD5 and SHA1 with SipHash for these uses is
obvious and straight-forward, and so is submitted along with this patch
series. There shouldn't be much of a debate over its efficacy.
Dozens of languages are already using this internally for their hash
tables and PRFs. Some of the BSDs already use this in their kernels.
SipHash is a widely known high-speed solution to a widely known set of
problems, and it's time we catch-up.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Eric Biggers <ebiggers3@gmail.com>
Cc: David Laight <David.Laight@aculab.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I0af6b25995c1d4f77b1f6c3467571abe54ad182e
commit 355b98553789b646ed97ad801a619ff898471b92 upstream.
net_hash_mix() currently uses kernel address of a struct net,
and is used in many places that could be used to reveal this
address to a patient attacker, thus defeating KASLR, for
the typical case (initial net namespace, &init_net is
not dynamically allocated)
I believe the original implementation tried to avoid spending
too many cycles in this function, but security comes first.
Also provide entropy regardless of CONFIG_NET_NS.
Fixes: 0b4419162a ("netns: introduce the net_hash_mix "salt" for hashes")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Amit Klein <aksecurity@gmail.com>
Reported-by: Benny Pinkas <benny@pinkas.net>
Cc: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-10638
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Iefa96bd40b5918e3e878182f9de7e978ea975fb0
commit b91ee4aa2a2199ba4d4650706c272985a5a32d80 upstream.
When creating a raw AF_ISDN socket, CAP_NET_RAW needs to be checked
first.
Signed-off-by: Ori Nimron <orinimron123@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-17052
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: If153b6f54818550d9d900bc202295a1bfa471ac4
commit 6cc03e8aa36c51f3b26a0d21a3c4ce2809c842ac upstream.
When creating a raw AF_APPLETALK socket, CAP_NET_RAW needs to be checked
first.
Signed-off-by: Ori Nimron <orinimron123@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-17052
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I7de244c5a2c55503ffe31b2f384fd02da77b94c3
commit e69dbd4619e7674c1679cba49afd9dd9ac347eef upstream.
When creating a raw AF_IEEE802154 socket, CAP_NET_RAW needs to be
checked first.
Signed-off-by: Ori Nimron <orinimron123@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-17052
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Idb2e9c9181c99e92d7faab05e29dacda942f9387
commit 0614e2b73768b502fc32a75349823356d98aae2c upstream.
When creating a raw AF_AX25 socket, CAP_NET_RAW needs to be checked
first.
Signed-off-by: Ori Nimron <orinimron123@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-17052
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I4b781c10113621f943df41bb5ed7caf2219ae36f
Denis Andzakovic discovered a potential use-after-free in older kernel
versions, using syzkaller. tcp_write_queue_purge() frees all skbs in
the TCP write queue and can leave sk->sk_send_head pointing to freed
memory. tcp_disconnect() clears that pointer after calling
tcp_write_queue_purge(), but tcp_connect() does not. It is
(surprisingly) possible to add to the write queue between
disconnection and reconnection, so this needs to be done in both
places.
This bug was introduced by backports of commit 7f582b248d0a ("tcp:
purge write queue in tcp_connect_init()") and does not exist upstream
because of earlier changes in commit 75c119afe14f ("tcp: implement
rb-tree based retransmit queue"). The latter is a major change that's
not suitable for stable.
Reported-by: Denis Andzakovic <denis.andzakovic@pulsesecurity.co.nz>
Bisected-by: Salvatore Bonaccorso <carnil@debian.org>
Fixes: 7f582b248d0a ("tcp: purge write queue in tcp_connect_init()")
Cc: <stable@vger.kernel.org> # before 4.15
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2020-0040
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I3c20d87056584d59741e8c94137c495e37581d84
commit 303911cfc5b95d33687d9046133ff184cf5043ff upstream.
The syzbot fuzzer has found two (!) races in the USB character device
registration and deregistration routines. This patch fixes the races.
The first race results from the fact that usb_deregister_dev() sets
usb_minors[intf->minor] to NULL before calling device_destroy() on the
class device. This leaves a window during which another thread can
allocate the same minor number but will encounter a duplicate name
error when it tries to register its own class device. A typical error
message in the system log would look like:
sysfs: cannot create duplicate filename '/class/usbmisc/ldusb0'
The patch fixes this race by destroying the class device first.
The second race is in usb_register_dev(). When that routine runs, it
first allocates a minor number, then drops minor_rwsem, and then
creates the class device. If the device creation fails, the minor
number is deallocated and the whole routine returns an error. But
during the time while minor_rwsem was dropped, there is a window in
which the minor number is allocated and so another thread can
successfully open the device file. Typically this results in
use-after-free errors or invalid accesses when the other thread closes
its open file reference, because the kernel then tries to release
resources that were already deallocated when usb_register_dev()
failed. The patch fixes this race by keeping minor_rwsem locked
throughout the entire routine.
Reported-and-tested-by: syzbot+30cf45ebfe0b0c4847a1@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1908121607590.1659-100000@iolanthe.rowland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-19537
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Iddf3d25faa97821489bf8201ac18802c7985ea02
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
Call trace:
[<ffffff9203a8d7a8>] dump_backtrace+0x0/0x428
[<ffffff9203a8dbf8>] show_stack+0x28/0x38
[<ffffff920409bfb8>] dump_stack+0xd4/0x124
[<ffffff9203d187e8>] print_address_description+0x68/0x258
[<ffffff9203d18c00>] kasan_report.part.2+0x228/0x2f0
[<ffffff9203d1927c>] kasan_report+0x5c/0x70
[<ffffff9203d1776c>] check_memory_region+0x12c/0x1c0
[<ffffff9203d17cdc>] memcpy+0x34/0x68
[<ffffff9203d75348>] xattr_getsecurity+0xe0/0x160
[<ffffff9203d75490>] vfs_getxattr+0xc8/0x120
[<ffffff9203d75d68>] getxattr+0x100/0x2c8
[<ffffff9203d76fb4>] SyS_fgetxattr+0x64/0xa0
[<ffffff9203a83f70>] el0_svc_naked+0x24/0x28
If user get root access and calls security.selinux setxattr() with an
embedded NUL on a file and then if some process performs a getxattr()
on that file with a length greater than the actual length of the string,
it would result in a panic.
To fix this, add the actual length of the string to the security context
instead of the length passed by the userspace process.
Change-Id: Ie0b8bfc7c96bc12282b955fb3adf41b3c2d011cd
Signed-off-by: Sachin Grover <sgrover@codeaurora.org>
CVE-2019-10607
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
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>
commit 2a3f7221acddfe1caa9ff09b3a8158c39b2fdeac upstream.
There is a small race window in the card disconnection code that
allows the registration of another card with the very same card id.
This leads to a warning in procfs creation as caught by syzkaller.
The problem is that we delete snd_cards and snd_cards_lock entries at
the very beginning of the disconnection procedure. This makes the
slot available to be assigned for another card object while the
disconnection procedure is being processed. Then it becomes possible
to issue a procfs registration with the existing file name although we
check the conflict beforehand.
The fix is simply to move the snd_cards and snd_cards_lock clearances
at the end of the disconnection procedure. The references to these
entries are merely either from the global proc files like
/proc/asound/cards or from the card registration / disconnection, so
it should be fine to shift at the very end.
Reported-by: syzbot+48df349490c36f9f54ab@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[haggertk: Backport to 3.4]
CVE-2019-15214
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I7c7c3fb4d49c0ab25abc75d2d8f1a5345f9bad02
The patch validates the dci entries and its task
structure before accessing structure members avoiding possible
kernel bug.
CRs-Fixed: 2035140
Change-Id: I7b0813defef1cb60400184acc631047cf72af94e
Signed-off-by: Manoj Prabhu B <bmanoj@codeaurora.org>
CVE-2018-11266
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
- using flash_boost_reg prevents charging after turned off torch, so revert to change_boost_control to allow qpnp to resume charging.
Change-Id: Ibf7462df9f87df367b190c18061f3a0628b30451
- Allow the camera driver to load old libmmcamera2* modules without the support of flicker_type and new frame_id.
Change-Id: Ief714adbccca6de10f643ea314714a8e9c69f4f8
using mms100_reset instead of mms_pwr_on_reset in mms100_ISC_download_mbinary function may fixes unexpected touchscreen freezes.
Change-Id: I1a7de26ac33f3f0a8d004c5e33a697e441f1ea76
using flash_boost_reg prevents charging after turned off torch, so revert to change_boost_control to allow qpnp to resume charging
Change-Id: I903925aa19ced91f2fb5af439443ede8264308cb
mdss_mdp_video_reconfigure_splash_done function blank/unblank the screen panel if handoff isn't set to false, however mdss do blank/unblank before already so we don't need to do it a second time. Skip compiling this part speeds up the transition from splash screen to bootanimation.
Change-Id: I9f88ab4e427c8f4f883ef17d2baae06d198248e6
Opening of multiple instance of voice_svc user space from app will
lead to pointer deference of private data within apr callback. As
multi-instance not supported added check to deny open() from user
space if previous instance hasn't been closed.
Change-Id: Ia5ef16c69a517760fc9d45530a8a41a333fa2a21
Signed-off-by: Ajit Pandey <ajitp@codeaurora.org>
[haggertk: Backport to 3.4/msm8974]
CVE-2019-10497
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Issue is seen when apr callback is received while voice_svc_release
is in process of freeing the driver private data.
Avoid invalid access of private data pointer by putting
the callback and release functions in the same locked context.
Change-Id: I93af13cab0a3c7e653a9bc9fa7f4f86bfa0502df
Signed-off-by: smanag <smanag@codeaurora.org>
[haggertk: Backport to 3.4/msm8974]
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
The range checking for audio buffer copying in function
"audio_in_write" is using the incorrect buffer size.
Change it to the actual allocated audio buffer size.
Change-Id: Ib7aaa2163c0d99161369eb85d09dc2d23d8c787b
Signed-off-by: Xiaoyu Ye <benyxy@codeaurora.org>
[haggertk: Backport to 3.4/msm8974]
CVE-2019-2341
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Adding code changes to validate buffer size.
While calling ipa_read verifying the kernel buffer
size in range or not.
Change-Id: Idc608c2cf0587a00f19ece38a4eb646f7fde68e3
Signed-off-by: Praveen Kurapati <pkurapat@codeaurora.org>
CVE-2019-2333
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Free the memory pointed by msg pointer if
copy_to_user fails.
Change-Id: I628e089d844a3e1818a1a550e77ac10f33640ac9
Acked-by: Mohammed Javid <mjavid@qti.qualcomm.com>
Signed-off-by: Utkarsh Saxena <usaxena@codeaurora.org>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
sockaddr structure is filled with required information only which
results in few memory locations of structure with uninitialized data.
Memset complete structure before using it to remove uninitialized data.
CRs-Fixed: 2274853
Change-Id: I181710bde100fb1553b925d9fdf227af35ff38b5
Signed-off-by: Arun Kumar Neelakantam <aneela@codeaurora.org>
[haggertk: Backport to 3.4/msm8974]
CVE-2018-12011
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
commit a5f596830e27e15f7a0ecd6be55e433d776986d8 upstream.
This change fixes buffer overflows and silent data corruption with the
usbmon device driver text file read operations.
Signed-off-by: Fredrik Noring <noring@nocrew.org>
Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2019-9456
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: Id947b4ae5a79a4c1bf8d8f394ad1c46cc9d2fd17
Matt Delco
Denis Efremov
Oliver Neukum
Dan Carpenter
Sean Young
Hui Peng
Eric Dumazet
Hannes Frederic Sowa
Jason A. Donenfeld
Ori Nimron
Will Deacon
Ben Hutchings
Alan Stern
Hillf Danton
Andrea Arcangeli
Sachin Grover
Suren Baghdasaryan
Takashi Iwai
Manoj Prabhu B
Zev Weiss
Daniel Jacob Chittoor
prototype74
Francescodario Cuzzocrea
Paul Keith
Kevin F. Haggerty
Ajit Pandey
smanag
Xiaoyu Ye
Praveen Kurapati
Utkarsh Saxena
Arun Kumar Neelakantam
Pete Zaitcev
Julia Lawall
Mao Wenan