Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
5807813...
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>
f176e6c...
by
Stephen Hemminger <email address hidden>
The Hyper-V netvsc driver was looking at the incorrect status bits
in the checksum info. It was setting the receive checksum unnecessary
flag based on the IP header checksum being correct. The checksum
flag is skb is about TCP and UDP checksum status. Because of this
bug, any packet received with bad TCP checksum would be passed
up the stack and to the application causing data corruption.
The problem is reproducible via netcat and netem.
This had a side effect of not doing receive checksum offload
on IPv6. The driver was also also always doing checksum offload
independent of the checksum setting done via ethtool.
Signed-off-by: Stephen Hemminger <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit e52fed7177f74382f742c27de2cc5314790aebb6)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Stefan Bader <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>
c83e888...
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>
Signed-off-by: Luis Henriques <email address hidden>
bd4fe51...
by
Mathias Krause <email address hidden>
proc: prevent accessing /proc/<PID>/environ until it's ready
If /proc/<PID>/environ gets read before the envp[] array is fully set up
in create_{aout,elf,elf_fdpic,flat}_tables(), we might end up trying to
read more bytes than are actually written, as env_start will already be
set but env_end will still be zero, making the range calculation
underflow, allowing to read beyond the end of what has been written.
Fix this as it is done for /proc/<PID>/cmdline by testing env_end for
zero. It is, apparently, intentionally set last in create_*_tables().
This bug was found by the PaX size_overflow plugin that detected the
arithmetic underflow of 'this_len = env_end - (env_start + src)' when
env_end is still zero.
The expected consequence is that userland trying to access
/proc/<PID>/environ of a not yet fully set up process may get
inconsistent data as we're in the middle of copying in the environment
variables.
Fixes: https://forums.grsecurity.net/viewtopic.php?f=3&t=4363
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=116461
Signed-off-by: Mathias Krause <email address hidden>
Cc: Emese Revfy <email address hidden>
Cc: Pax Team <email address hidden>
Cc: Al Viro <email address hidden>
Cc: Mateusz Guzik <email address hidden>
Cc: Alexey Dobriyan <email address hidden>
Cc: Cyrill Gorcunov <email address hidden>
Cc: Jarod Wilson <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
CVE-2016-7916
(cherry picked from commit 8148a73c9901a8794a50f950083c00ccf97d43b3)
Signed-off-by: Luis Henriques <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Colin Ian King <email address hidden>
