Skip to content
Snippets Groups Projects
Select Git revision
20 results
Search by author
  • Any Author
0 authors
  1. Sep 13, 2016
  3. Sep 12, 2016
    • Hector Marco-Gisbert's avatar
      x86/mm/32: Enable full randomization on i386 and X86_32 · 00d17294
      Hector Marco-Gisbert authored 
      Currently on i386 and on X86_64 when emulating X86_32 in legacy mode, only
the stack and the executable are randomized but not other mmapped files
(libraries, vDSO, etc.). This patch enables randomization for the
libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode.

By default on i386 there are 8 bits for the randomization of the libraries,
vDSO and mmaps which only uses 1MB of VA.

This patch preserves the original randomness, using 1MB of VA out of 3GB or
4GB. We think that 1MB out of 3GB is not a big cost for having the ASLR.

The first obvious security benefit is that all objects are randomized (not
only the stack and the executable) in legacy mode which highly increases
the ASLR effectiveness, otherwise the attackers may use these
non-randomized areas. But also sensitive setuid/setgid applications are
more secure because currently, attackers can disable the randomization of
these applications by setting the ulimit stack to "unlimited". This is a
very old and widely known trick to disable the ASLR in i386 which has been
allowed for too long.

Another trick used to disable the ASLR was to set the ADDR_NO_RANDOMIZE
personality flag, but fortunately this doesn't work on setuid/setgid
applications because there is security checks which clear Security-relevant
flags.

This patch always randomizes the mmap_legacy_base address, removing the
possibility to disable the ASLR by setting the stack to "unlimited".

Bug: 30609570

Change-Id: Idbea7473e2f0713b8ae126c9de6de38ab0dac3f4
Tracked-On: https://jira01.devtools.intel.com/browse/AW-1818


Signed-off-by: default avatarHector Marco-Gisbert <hecmargi@upv.es>
Acked-by: default avatarIsmael Ripoll Ripoll <iripoll@upv.es>
Acked-by: default avatarKees Cook <keescook@chromium.org>
Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: akpm@linux-foundation.org
Cc: kees Cook <keescook@chromium.org>
Link: http://lkml.kernel.org/r/1457639460-5242-1-git-send-email-hecmargi@upv.es


Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
Signed-off-by: default avatarErwan Mahe <erwan.mahe@intel.com>
      00d17294
  5. Aug 16, 2016
  7. Jul 21, 2016
  9. Jun 08, 2016
  11. May 03, 2016
  13. Apr 21, 2016
  15. Apr 15, 2016
    • Ben Hutchings's avatar
      pipe: Fix buffer offset after partially failed read · 6c6f3230
      Ben Hutchings authored 
      Quoting the RHEL advisory:

> It was found that the fix for CVE-2015-1805 incorrectly kept buffer
> offset and buffer length in sync on a failed atomic read, potentially
> resulting in a pipe buffer state corruption. A local, unprivileged user
> could use this flaw to crash the system or leak kernel memory to user
> space. (CVE-2016-0774, Moderate)

The same flawed fix was applied to stable branches from 2.6.32.y to
3.14.y inclusive, and I was able to reproduce the issue on 3.2.y.
We need to give pipe_iov_copy_to_user() a separate offset variable
and only update the buffer offset if it succeeds.

Bug: 28054181
Change-Id: I988802f38acf40c7671fa0978880928b02d29b56
References: https://rhn.redhat.com/errata/RHSA-2016-0103.html


Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
(cherry picked from commit feae3ca2e5e1a8f44aa6290255d3d9709985d0b2)
Tracked-On: https://jira.ndg.intel.com/browse/MARVIN-1660


Signed-off-by: default avatarVictor Tasayco Loarte <victorx.tasayco.loarte@intel.com>
      6c6f3230
    • Ben Hutchings's avatar
      pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic · bdd4f0a7
      Ben Hutchings authored 
      pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not.  The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset.  This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.

This was fixed upstream by commits f0d1bec9 ("new helper:
copy_page_from_iter()") and 637b58c2 ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable.  This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.

CVE-2015-1805

Bug: 27275324
Bug: 28054181
Change-Id: I459adb9076fcd50ff1f1c557089c4e421b036ec4
References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855


Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 85c34d007116f8a8aafb173966a605fb03532f45)
Tracked-On: https://jira.ndg.intel.com/browse/MARVIN-1660


Signed-off-by: default avatarVictor Tasayco Loarte <victorx.tasayco.loarte@intel.com>
      bdd4f0a7
    • Takashi Iwai's avatar
      UPSTREAM: ALSA: timer: Harden slave timer list handling · be8bad63
      Takashi Iwai authored 
      
(cherry pick from commit b5a663aa426f4884c71cd8580adae73f33570f0d)

A slave timer instance might be still accessible in a racy way while
operating the master instance as it lacks of locking.  Since the
master operation is mostly protected with timer->lock, we should cope
with it while changing the slave instance, too.  Also, some linked
lists (active_list and ack_list) of slave instances aren't unlinked
immediately at stopping or closing, and this may lead to unexpected
accesses.

This patch tries to address these issues.  It adds spin lock of
timer->lock (either from master or slave, which is equivalent) in a
few places.  For avoiding a deadlock, we ensure that the global
slave_active_lock is always locked at first before each timer lock.

Also, ack and active_list of slave instances are properly unlinked at
snd_timer_stop() and snd_timer_close().

Last but not least, remove the superfluous call of _snd_timer_stop()
at removing slave links.  This is a noop, and calling it may confuse
readers wrt locking.  Further cleanup will follow in a later patch.

Actually we've got reports of use-after-free by syzkaller fuzzer, and
this hopefully fixes these issues.

Change-Id: I62e7f671a298e70fe6e6e64ddc3ff92106d2adf8
Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Bug: 26636060
Bug: 28054181
Tracked-On: https://jira.ndg.intel.com/browse/MARVIN-1660


Signed-off-by: default avatarVictor Tasayco Loarte <victorx.tasayco.loarte@intel.com>
      be8bad63
  17. Apr 01, 2016
  19. Mar 25, 2016