Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Apr 27, 2017
  3. Apr 24, 2017
    • Zhang Wei's avatar
      [PATCH] trace: resolve stack corruption due to string copy · 9a01e6bb
      Zhang Wei authored 
      
CVE-2017-0605

Strcpy has no limit on string being copied which causes
stack corruption leading to kernel panic. Use strlcpy to
resolve the issue by providing length of string to be copied.

CRs-fixed: 1048480
Change-Id: Ib290b25f7e0ff96927b8530e5c078869441d409f
Signed-off-by: default avatarAmey Telawane <ameyt@codeaurora.org>
      android-wear-7.1.1_r0.25
      9a01e6bb
    • Zhang Wei's avatar
      spcom: check size before calling copy_to_user() · c0b927d3
      Zhang Wei authored 
      
CVE-2016-5854

Calling copy_to_user(to, from, size) with negative value
might cause heap overflow since size is unsigned parameter
and negative value is cast to big unsigned value.

CRs-Fixed: 1092683
Change-Id: I9b4a0710aa33942de2976f7ee158a8025dd6a20e
Signed-off-by: default avatarAmir Samuelov <amirs@codeaurora.org>
      c0b927d3
    • Zhang Wei's avatar
      tracing: do not leak kernel addresses · 99e3ecc6
      Zhang Wei authored 
      
CVE-2017-0630

This likely breaks tracing tools like trace-cmd.  It logs in the same
format but now addresses are all 0x0.

Bug: 34277115

Change-Id: Iffd01e5002dd342c4435ef932c231183b0ce3c80
Signed-off-by: default avatarc00187401 <c00187401@notesmail.huawei.com>
      99e3ecc6
    • Zhang Wei's avatar
      xfrm_user: validate XFRM_MSG_NEWAE XFRMA_REPLAY_ESN_VAL replay_window · 670915b6
      Zhang Wei authored 
      
CVE-2017-7184

When a new xfrm state is created during an XFRM_MSG_NEWSA call we
validate the user supplied replay_esn to ensure that the size is valid
and to ensure that the replay_window size is within the allocated
buffer.  However later it is possible to update this replay_esn via a
XFRM_MSG_NEWAE call.  There we again validate the size of the supplied
buffer matches the existing state and if so inject the contents.  We do
not at this point check that the replay_window is within the allocated
memory.  This leads to out-of-bounds reads and writes triggered by
netlink packets.  This leads to memory corruption and the potential for
priviledge escalation.

We already attempt to validate the incoming replay information in
xfrm_new_ae() via xfrm_replay_verify_len().  This confirms that the user
is not trying to change the size of the replay state buffer which
includes the replay_esn.  It however does not check the replay_window
remains within that buffer.  Add validation of the contained
replay_window.

Signed-off-by: default avatarAndy Whitcroft <apw@canonical.com>
Acked-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>

Change-Id: Ia235af1f43f7385d3c0ee68789ea49ef082863d7
      670915b6
    • Zhang Wei's avatar
      slim-msm: Synchronize SSR callbacks · b6171883
      Zhang Wei authored 
      
CVE-2016-10291

Subsystem will restart within short timeframe.
Synchronise subsytem up/down callback notifications
to avoid functionality failures.
Use mutex locks to achieve synchronization.

Change-Id: I5881c7d468507bb8402a2e9f8178b9c31e57e8a5
Signed-off-by: default avatarDilip Kota <dkota@codeaurora.org>
      b6171883
    • Zhang Wei's avatar
      ALSA: pcm : Call kill_fasync() in stream lock · 83403d71
      Zhang Wei authored 
      
CVE-2016-9794

commit 3aa02cb6 upstream.

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.

Change-Id: Id8eac74639477d1c283eabf4f7ff82916674474f
Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarWilly Tarreau <w@1wt.eu>
      83403d71
  5. Apr 20, 2017
  7. Mar 22, 2017
  9. Mar 20, 2017
  11. Mar 02, 2017
  13. Feb 25, 2017