Skip to content
Snippets Groups Projects
Select Git revision
20 results
Search by author
  • Any Author
0 authors
  1. Sep 21, 2016
    • Rainer Weikusat's avatar
      BACKPORT: unix: avoid use-after-free in ep_remove_wait_queue · 3a30fced
      Rainer Weikusat authored 
      
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
An AF_UNIX datagram socket being the client in an n:1 association with
some server socket is only allowed to send messages to the server if the
receive queue of this socket contains at most sk_max_ack_backlog
datagrams. This implies that prospective writers might be forced to go
to sleep despite none of the message presently enqueued on the server
receive queue were sent by them. In order to ensure that these will be
woken up once space becomes again available, the present unix_dgram_poll
routine does a second sock_poll_wait call with the peer_wait wait queue
of the server socket as queue argument (unix_dgram_recvmsg does a wake
up on this queue after a datagram was received). This is inherently
problematic because the server socket is only guaranteed to remain alive
for as long as the client still holds a reference to it. In case the
connection is dissolved via connect or by the dead peer detection logic
in unix_dgram_sendmsg, the server socket may be freed despite "the
polling mechanism" (in particular, epoll) still has a pointer to the
corresponding peer_wait queue. There's no way to forcibly deregister a
wait queue with epoll.

Based on an idea by Jason Baron, the patch below changes the code such
that a wait_queue_t belonging to the client socket is enqueued on the
peer_wait queue of the server whenever the peer receive queue full
condition is detected by either a sendmsg or a poll. A wake up on the
peer queue is then relayed to the ordinary wait queue of the client
socket via wake function. The connection to the peer wait queue is again
dissolved if either a wake up is about to be relayed or the client
socket reconnects or a dead peer is detected or the client socket is
itself closed. This enables removing the second sock_poll_wait from
unix_dgram_poll, thus avoiding the use-after-free, while still ensuring
that no blocked writer sleeps forever.

Signed-off-by: default avatarRainer Weikusat <rweikusat@mobileactivedefense.com>
Fixes: ec0d215f ("af_unix: fix 'poll for write'/connected DGRAM sockets")
Reviewed-by: default avatarJason Baron <jbaron@akamai.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>

Bug: 29119002
(cherry picked from commit 7d267278)
Signed-off-by: default avatarAarthi Thiruvengadam <athiru@google.com>

Bug: 31554728
Change-Id: Ia374ee061195088f8c777940baa75cedbe897f4e
Tracked-On: https://jira01.devtools.intel.com/browse/AW-1795


Signed-off-by: default avatarVictor Tasayco Loarte <victorx.tasayco.loarte@intel.com>
      3a30fced
    • Yueyao (Nathan) Zhu's avatar
      BACKPORT: KEYS: potential uninitialized variable · 2f0779f8
      Yueyao (Nathan) Zhu authored 
      
Bug: 29823941

If __key_link_begin() failed then "edit" would be uninitialized.  I've
added a check to fix that.

This allows a random user to crash the kernel, though it's quite
difficult to achieve.  There are three ways it can be done as the user
would have to cause an error to occur in __key_link():

 (1) Cause the kernel to run out of memory.  In practice, this is difficult
     to achieve without ENOMEM cropping up elsewhere and aborting the
     attempt.

 (2) Revoke the destination keyring between the keyring ID being looked up
     and it being tested for revocation.  In practice, this is difficult to
     time correctly because the KEYCTL_REJECT function can only be used
     from the request-key upcall process.  Further, users can only make use
     of what's in /sbin/request-key.conf, though this does including a
     rejection debugging test - which means that the destination keyring
     has to be the caller's session keyring in practice.

 (3) Have just enough key quota available to create a key, a new session
     keyring for the upcall and a link in the session keyring, but not then
     sufficient quota to create a link in the nominated destination keyring
     so that it fails with EDQUOT.

The bug can be triggered using option (3) above using something like the
following:

	echo 80 >/proc/sys/kernel/keys/root_maxbytes
	keyctl request2 user debug:fred negate @t

The above sets the quota to something much lower (80) to make the bug
easier to trigger, but this is dependent on the system.  Note also that
the name of the keyring created contains a random number that may be
between 1 and 10 characters in size, so may throw the test off by
changing the amount of quota used.

Assuming the failure occurs, something like the following will be seen:

	kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h
	------------[ cut here ]------------
	kernel BUG at ../mm/slab.c:2821!
	...
	RIP: 0010:[<ffffffff811600f9>] kfree_debugcheck+0x20/0x25
	RSP: 0018:ffff8804014a7de8  EFLAGS: 00010092
	RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000
	RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300
	RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000
	R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202
	R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001
	...
	Call Trace:
	  kfree+0xde/0x1bc
	  assoc_array_cancel_edit+0x1f/0x36
	  __key_link_end+0x55/0x63
	  key_reject_and_link+0x124/0x155
	  keyctl_reject_key+0xb6/0xe0
	  keyctl_negate_key+0x10/0x12
	  SyS_keyctl+0x9f/0xe7
	  do_syscall_64+0x63/0x13a
	  entry_SYSCALL64_slow_path+0x25/0x25

Fixes: f70e2e06 ('KEYS: Do preallocation for __key_link()')
Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
cc: stable@vger.kernel.org
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>

(cherry picked from commit 38327424b40bcebe2de92d07312c89360ac9229a)

Bug: 31554728
Change-Id: Ia9616cce142a616beea0ef20bde49129939d2d2d
Tracked-On: https://jira01.devtools.intel.com/browse/AW-1795


Signed-off-by: default avatarVictor Tasayco Loarte <victorx.tasayco.loarte@intel.com>
      2f0779f8
  3. Sep 13, 2016
  5. 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
  7. Aug 16, 2016
  9. Jul 21, 2016
  11. Jun 08, 2016
  13. May 03, 2016
  15. Apr 21, 2016
  17. 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
  19. Apr 01, 2016
  21. Mar 25, 2016