This plugs 2 trivial leaks in xfs_attr_shortform_list and
xfs_attr3_leaf_list_int.
Signed-off-by: Mateusz Guzik <email address hidden>
Reviewed-by: Eric Sandeen <email address hidden>
Signed-off-by: Dave Chinner <email address hidden>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <email address hidden>
CVE-2016-9685
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>
Signed-off-by: Luis Henriques <email address hidden>
60345e1...
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: Thadeu Lima de Souza Cascardo <email address hidden>
1cf289c...
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 ...
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>
Signed-off-by: Luis Henriques <email address hidden>
3ebd7f5...
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
(backported from commit 8148a73c9901a8794a50f950083c00ccf97d43b3)
[ luis: adjusted context ]
Signed-off-by: Luis Henriques <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Acked-by: Colin Ian King <email address hidden>
