Signed-off-by: John Donnelly <email address hidden>
fa1b1d9...
by
Marcelo Ricardo Leitner <email address hidden>
sctp: validate chunk len before actually using it
Andrey Konovalov reported that KASAN detected that SCTP was using a slab
beyond the boundaries. It was caused because when handling out of the
blue packets in function sctp_sf_ootb() it was checking the chunk len
only after already processing the first chunk, validating only for the
2nd and subsequent ones.
The fix is to just move the check upwards so it's also validated for the
1st chunk.
Reported-by: Andrey Konovalov <email address hidden>
Tested-by: Andrey Konovalov <email address hidden>
Signed-off-by: Marcelo Ricardo Leitner <email address hidden>
Reviewed-by: Xin Long <email address hidden>
Acked-by: Neil Horman <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(backported from commit bf911e985d6bbaa328c20c3e05f4eb03de11fdd6)
CVE-2016-9555
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>
667a3da...
by
=?utf-8?b?UmFkaW0gS3LEjW3DocWZ?= <email address hidden>
KVM: x86: drop error recovery in em_jmp_far and em_ret_far
em_jmp_far and em_ret_far assumed that setting IP can only fail in 64
bit mode, but syzkaller proved otherwise (and SDM agrees).
Code segment was restored upon failure, but it was left uninitialized
outside of long mode, which could lead to a leak of host kernel stack.
We could have fixed that by always saving and restoring the CS, but we
take a simpler approach and just break any guest that manages to fail
as the error recovery is error-prone and modern CPUs don't need emulator
for this.
Found by syzkaller:
WARNING: CPU: 2 PID: 3668 at arch/x86/kvm/emulate.c:2217 em_ret_far+0x428/0x480
Kernel panic - not syncing: panic_on_warn set ...
When we free cb->skb after a dump, we do it after releasing the
lock. This means that a new dump could have started in the time
being and we'll end up freeing their skb instead of ours.
This patch saves the skb and module before we unlock so we free
the right memory.
Fixes: 16b304f3404f ("netlink: Eliminate kmalloc in netlink dump operation.")
Reported-by: Baozeng Ding <email address hidden>
Signed-off-by: Herbert Xu <email address hidden>
Acked-by: Cong Wang <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 92964c79b357efd980812c4de5c1fd2ec8bb5520)
CVE-2016-9806
Signed-off-by: Luis Henriques <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Currently kill_fasync() is called outside the stream lock in
snd_pcm_period_elapsed(). This is potentially racy, since the stream
may get released even during the irq handler is running. Although
snd_pcm_release_substream() calls snd_pcm_drop(), this doesn't
guarantee that the irq handler finishes, thus the kill_fasync() call
outside the stream spin lock may be invoked after the substream is
detached, as recently reported by KASAN.
As a quick workaround, move kill_fasync() call inside the stream
lock. The fasync is rarely used interface, so this shouldn't have a
big impact from the performance POV.
Ideally, we should implement some sync mechanism for the proper finish
of stream and irq handler. But this oneliner should suffice for most
cases, so far.
Reported-by: Baozeng Ding <email address hidden>
Signed-off-by: Takashi Iwai <email address hidden>
CVE-2016-9794
(backported from commit 3aa02cb664c5fb1042958c8d1aa8c35055a2ebc4)
[ luis: used Takashi's backport for upstream stable 3.12 ]
Signed-off-by: Luis Henriques <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Adds all controller information to attribute list exposed to sysfs, and
appends the reset_controller attribute to it. The nvme device is created
with this attribute list, so driver no long manages its attributes.
Backport note:
This backport required changes to how the attributes are exported, due
to the large number of changes between this kernel and the upstream
kernel where this functionality is added. Specifically, in the upstream
commit, the driver already has been changed over to use device_create()
to manage the device's attributes, which included creating a new device
class for nvme devices; the upstream commit also had already added a sysfs
interface to reset the controller. Those changes are too large to
backport just to provide three string attributes via sysfs, so instead
this directly uses device_create_file() for the drive's attribute strings,
and does not export the interface to reset the controller. That allows
this patch to stay as simple as possible.
Reported-by: Sujith Pandel <email address hidden>
Cc: Sujith Pandel <sujithpshankar@ gmail.com>
Cc: David Milburn <email address hidden>
Signed-off-by: Keith Busch <email address hidden>
Signed-off-by: Jens Axboe <email address hidden>
(backported from upstream commit 779ff75617099f4defe14e20443b95019a4c5ae8)
Signed-off-by: Dan Streetman <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>
net: avoid signed overflows for SO_{SND|RCV}BUFFORCE
CAP_NET_ADMIN users should not be allowed to set negative
sk_sndbuf or sk_rcvbuf values, as it can lead to various memory
corruptions, crashes, OOM...
Note that before commit 82981930125a ("net: cleanups in
sock_setsockopt()"), the bug was even more serious, since SO_SNDBUF
and SO_RCVBUF were vulnerable.
This needs to be backported to all known linux kernels.
Again, many thanks to syzkaller team for discovering this gem.
Signed-off-by: Eric Dumazet <email address hidden>
Reported-by: Andrey Konovalov <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit b98b0bc8c431e3ceb4b26b0dfc8db509518fb290)
CVE-2016-9793
Signed-off-by: Luis Henriques <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: John Donnelly <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Steve Beattie <email address hidden>
93ab694...
by
Gabriel Krisman Bertazi <email address hidden>
serial: 8250_pci: Detach low-level driver during PCI error recovery
During a PCI error recovery, like the ones provoked by EEH in the ppc64
platform, all IO to the device must be blocked while the recovery is
completed. Current 8250_pci implementation only suspends the port
instead of detaching it, which doesn't prevent incoming accesses like
TIOCMGET and TIOCMSET calls from reaching the device. Those end up
racing with the EEH recovery, crashing it. Similar races were also
observed when opening the device and when shutting it down during
recovery.
This patch implements a more robust IO blockage for the 8250_pci
recovery by unregistering the port at the beginning of the procedure and
re-adding it afterwards. Since the port is detached from the uart
layer, we can be sure that no request will make through to the device
during recovery. This is similar to the solution used by the JSM serial
driver.
I thank Peter Hurley <email address hidden> for valuable input on
this one over one year ago.
Signed-off-by: Gabriel Krisman Bertazi <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
(cherry picked from linux-next commit f209fa03fc9d131b3108c2e4936181eabab87416)
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>
