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
SSM driver is not enabled and hence needs deprecation.
Remove all the SSM driver references.
CRs-Fixed: 2268386
Change-Id: I02f82817023d2fcc6d05a2f0d7eb3aec8f60a7d5
Signed-off-by: Manoj Prabhu B <bmanoj@codeaurora.org>
CVE-2018-12010
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
TX and RX FIFOs of Microcontroller are used to exchange commands
and messages between Micro FW and CPP driver. TX FIFO depth is
16 32-bit words, incase of errors there is a chance of overflow.
To prevent possible out of bound access, TX FIFO depth or
level is checked for MAX depth before accessing the FIFO.
Change-Id: I5adf39b46ff10e358c4a2c03a2de07d44b99cedb
Signed-off-by: Pratap Nirujogi <pratapn@codeaurora.org>
[haggertk: Backport to 3.4/msm8974. Note that this includes patching
the non-standard camera_ll implementation as well on this kernel.]
CVE-2018-11986
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
To avoid access of variable after being freed, using
list_first_entry_safe function to iterate over list
of given type, safe against removal of list entry.
Change-Id: I70611fddf3e9b80b1affa3e5235be24eac0d0a58
Signed-off-by: Monika Singh <monising@codeaurora.org>
CVE-2018-11988
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
"bssid" is only initialized out of the while loop, in case of two
events with same type: EVENT_CONNECT_RESULT, but one has zero
ether addr, the other is non-zero, the bssid pointer will be
referenced twice, which lead to use-after-free issue.
Change-Id: Ie8a24275f7ec5c2f936ef0a802a42e5f63be9c71
CRs-Fixed: 2254305
Signed-off-by: Zhu Jianmin <jianminz@codeaurora.org>
CVE-2018-11939
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
commit 9824dfae5741275473a23a7ed5756c7b6efacc9d upstream.
Fields ->dev and ->next of struct ipddp_route may be copied to
userspace on the SIOCFINDIPDDPRT ioctl. This is only accessible
to CAP_NET_ADMIN though. Let's manually copy the relevant fields
instead of using memcpy().
BugLink: http://blog.infosectcbr.com.au/2018/09/linux-kernel-infoleaks.html
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2018-20511
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I74f1982a5c0a14514348aaecbc351bc3249c52da
commit 5146f95df782b0ac61abde36567e718692725c89 upstream.
The function hso_probe reads if_num from the USB device (as an u8) and uses
it without a length check to index an array, resulting in an OOB memory read
in hso_probe or hso_get_config_data.
Add a length check for both locations and updated hso_probe to bail on
error.
This issue has been assigned CVE-2018-19985.
Change-Id: I592d0f50b24abe5b8d270fab303c9cb78fbd546f
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: Mathias Payer <mathias.payer@nebelwelt.net>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
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>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
commit 07f2c7ab6f8d0a7e7c5764c4e6cc9c52951b9d9c upstream.
When SCTP makes INIT or INIT_ACK packet the total chunk length
can exceed SCTP_MAX_CHUNK_LEN which leads to kernel panic when
transmitting these packets, e.g. the crash on sending INIT_ACK:
[ 597.804948] skbuff: skb_over_panic: text:00000000ffae06e4 len:120168
put:120156 head:000000007aa47635 data:00000000d991c2de
tail:0x1d640 end:0xfec0 dev:<NULL>
...
[ 597.976970] ------------[ cut here ]------------
[ 598.033408] kernel BUG at net/core/skbuff.c:104!
[ 600.314841] Call Trace:
[ 600.345829] <IRQ>
[ 600.371639] ? sctp_packet_transmit+0x2095/0x26d0 [sctp]
[ 600.436934] skb_put+0x16c/0x200
[ 600.477295] sctp_packet_transmit+0x2095/0x26d0 [sctp]
[ 600.540630] ? sctp_packet_config+0x890/0x890 [sctp]
[ 600.601781] ? __sctp_packet_append_chunk+0x3b4/0xd00 [sctp]
[ 600.671356] ? sctp_cmp_addr_exact+0x3f/0x90 [sctp]
[ 600.731482] sctp_outq_flush+0x663/0x30d0 [sctp]
[ 600.788565] ? sctp_make_init+0xbf0/0xbf0 [sctp]
[ 600.845555] ? sctp_check_transmitted+0x18f0/0x18f0 [sctp]
[ 600.912945] ? sctp_outq_tail+0x631/0x9d0 [sctp]
[ 600.969936] sctp_cmd_interpreter.isra.22+0x3be1/0x5cb0 [sctp]
[ 601.041593] ? sctp_sf_do_5_1B_init+0x85f/0xc30 [sctp]
[ 601.104837] ? sctp_generate_t1_cookie_event+0x20/0x20 [sctp]
[ 601.175436] ? sctp_eat_data+0x1710/0x1710 [sctp]
[ 601.233575] sctp_do_sm+0x182/0x560 [sctp]
[ 601.284328] ? sctp_has_association+0x70/0x70 [sctp]
[ 601.345586] ? sctp_rcv+0xef4/0x32f0 [sctp]
[ 601.397478] ? sctp6_rcv+0xa/0x20 [sctp]
...
Here the chunk size for INIT_ACK packet becomes too big, mostly
because of the state cookie (INIT packet has large size with
many address parameters), plus additional server parameters.
Later this chunk causes the panic in skb_put_data():
skb_packet_transmit()
sctp_packet_pack()
skb_put_data(nskb, chunk->skb->data, chunk->skb->len);
'nskb' (head skb) was previously allocated with packet->size
from u16 'chunk->chunk_hdr->length'.
As suggested by Marcelo we should check the chunk's length in
_sctp_make_chunk() before trying to allocate skb for it and
discard a chunk if its size bigger than SCTP_MAX_CHUNK_LEN.
Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leinter@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2:
- Keep using WORD_ROUND() instead of SCTP_PAD4()
- Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2018-5803
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I68b9b08d0e57ebb4e9f4c93d0e10b4ea20b6b269
commit 500ad2d8b01390c98bc6dce068bccfa9534b8212 upstream.
While debugging a warning message on PowerPC while using hardware
breakpoints, it was discovered that when perf_event_disable is invoked
through hw_breakpoint_handler function with interrupts disabled, a
subsequent IPI in the code path would trigger a WARN_ON_ONCE message in
smp_call_function_single function.
This patch calls __perf_event_disable() when interrupts are already
disabled, instead of perf_event_disable().
Reported-by: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Signed-off-by: K.Prasad <Prasad.Krishnan@gmail.com>
[naveen.n.rao@linux.vnet.ibm.com: v3: Check to make sure we target current task]
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20120802081635.5811.17737.stgit@localhost.localdomain
[ Fixed build error on MIPS. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Change-Id: I4ed3bb0ff5c41d633868d488aaff14897e56e973
Jason A. Donenfeld
Eric Dumazet
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
Pratap Nirujogi
Monika Singh
Zhu Jianmin
Willy Tarreau
Hui Peng
Mathias Payer
Alexey Kodanev
Linus Torvalds
K.Prasad
Chao Yu