commit: 49d31c2f389acfe83417083e1208422b4091cd9e upstream.

take_dentry_name_snapshot() takes a safe snapshot of dentry name;
if the name is a short one, it gets copied into caller-supplied
structure, otherwise an extra reference to external name is grabbed
(those are never modified).  In either case the pointer to stable
string is stored into the same structure.

dentry must be held by the caller of take_dentry_name_snapshot(),
but may be freely dropped afterwards - the snapshot will stay
until destroyed by release_dentry_name_snapshot().

Intended use:
	struct name_snapshot s;

	take_dentry_name_snapshot(&s, dentry);
	...
	access s.name
	...
	release_dentry_name_snapshot(&s);

Replaces fsnotify_oldname_...(), gets used in fsnotify to obtain the name
to pass down with event.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bug: 63689921
Change-Id: I2909171089500f607152d6dba2607c5d1d1f64b8

[ Upstream commit: 155e35d4daa804582f75acaa2c74ec797a89c615 ]

Introduce some function for getting the inode (and also the dentry) in an
environment where layered/unioned filesystems are in operation.

The problem is that we have places where we need *both* the union dentry and
the lower source or workspace inode or dentry available, but we can only have
a handle on one of them.  Therefore we need to derive the handle to the other
from that.

The idea is to introduce an extra field in struct dentry that allows the union
dentry to refer to and pin the lower dentry.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

Bug: 63689921
Change-Id: I5cc015a7e3238dcd1b992d7e19a2361a73364bd4

If the user passes in a negative file size in a int64,
this will compare to be smaller than buffer length,
and it will get truncated to form a read length that
is larger than the buffer length.

To fix, return -EINVAL if the count argument is negative,
so the loop will never happen.

Bug: 37429972
Test: Test with PoC
Change-Id: I5d52e38e6fbe2c17eb8c493f9eb81df6cfd780a4
Signed-off-by: Jerry Zhang <zhangjerry@google.com>

When interrupted by EC, we normally wake up and interrupt suspend.
However, when suspending, we should not abort suspend because of sensor
events: EC sensor stack does not know yet we are suspending, and
interrupts are send very often.

We are losing significant motion interrupt, but suspending is a short
window.

BUG=b:25425420
TEST=Check we are entering suspend.

Change-Id: I60fc031a70535ababe28d62e5dffd548752078a0
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>

Merge changes Iad4f1a09,I79e8929c,I81557024,I6962e334,Icbc3b258, ... into android-chromeos-dragon-3.18

* changes:
  ALSA: timer: Call notifier in the same spinlock
  ALSA: timer: Fix race between stop and interrupt
  ALSA: timer: Fix link corruption due to double start or stop
  ALSA: timer: Code cleanup
  ALSA: timer: Fix race between read and ioctl
  ALSA: timer: Fix race at concurrent reads
  ALSA: timer: Handle disconnection more safely
  ALSA: timer: Fix missing queue indices reset at SNDRV_TIMER_IOCTL_SELECT
  ALSA: timer: Fix leak in events via snd_timer_user_ccallback
  ALSA: timer: Fix wrong instance passed to slave callbacks

Check the path_nr before passing it into nvkm_ioctl_path to avoid the
out-of-bound issue.

Bug: 63851980

Change-Id: Ida06ef6218b914df0794a7431b9679c916988f33
Signed-off-by: Kary Jin <karyj@nvidia.com>

[ Upstream commit f65e0d299807d8a11812845c972493c3f9a18e10 ]

snd_timer_notify1() is called outside the spinlock and it retakes the
lock after the unlock.  This is rather racy, and it's safer to move
snd_timer_notify() call inside the main spinlock.

The patch also contains a slight refactoring / cleanup of the code.
Now all start/stop/continue/pause look more symmetric and a bit better
readable.

Change-Id: Iad4f1a096f02cd6fc7411197cc9307c917fc07d8
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

[ Upstream commit ed8b1d6d2c741ab26d60d499d7fbb7ac801f0f51 ]

A slave timer element also unlinks at snd_timer_stop() but it takes
only slave_active_lock.  When a slave is assigned to a master,
however, this may become a race against the master's interrupt
handling, eventually resulting in a list corruption.  The actual bug
could be seen with a syzkaller fuzzer test case in BugLink below.

As a fix, we need to take timeri->timer->lock when timer isn't NULL,
i.e. assigned to a master, while the assignment to a master itself is
protected by slave_active_lock.

Change-Id: I79e8929cb3fe9000b13ee16053fcc0467342deb0
BugLink: http://lkml.kernel.org/r/CACT4Y+Y_Bm+7epAb=8Wi=AaWd+DYS7qawX52qxdCfOfY49vozQ@mail.gmail.com


Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

[ Upstream commit f784beb75ce82f4136f8a0960d3ee872f7109e09 ]

Although ALSA timer code got hardening for races, it still causes
use-after-free error.  This is however rather a corrupted linked list,
not actually the concurrent accesses.  Namely, when timer start is
triggered twice, list_add_tail() is called twice, too.  This ends
up with the link corruption and triggers KASAN error.

The simplest fix would be replacing list_add_tail() with
list_move_tail(), but fundamentally it's the problem that we don't
check the double start/stop correctly.  So, the right fix here is to
add the proper checks to snd_timer_start() and snd_timer_stop() (and
their variants).

Change-Id: I815570244468ced4a7a8b525763b2853412eb1bb
BugLink: http://lkml.kernel.org/r/CACT4Y+ZyPRoMQjmawbvmCEDrkBD2BQuH7R09=eOkf5ESK8kJAw@mail.gmail.com


Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

[ Upstream commit c3b1681375dc6e71d89a3ae00cc3ce9e775a8917 ]

This is a minor code cleanup without any functional changes:
- Kill keep_flag argument from _snd_timer_stop(), as all callers pass
  only it false.
- Remove redundant NULL check in _snd_timer_stop().

Change-Id: I6962e334136372b3dfd909e4f31f24c076459912
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit d11662f4f798b50d8c8743f433842c3e40fe3378 upstream.

The read from ALSA timer device, the function snd_timer_user_tread(),
may access to an uninitialized struct snd_timer_user fields when the
read is concurrently performed while the ioctl like
snd_timer_user_tselect() is invoked.  We have already fixed the races
among ioctls via a mutex, but we seem to have forgotten the race
between read vs ioctl.

This patch simply applies (more exactly extends the already applied
range of) tu->ioctl_lock in snd_timer_user_tread() for closing the
race window.

Change-Id: Icbc3b258525b8662cb19776b70718169e9c09538
Reported-by: Alexander Potapenko <glider@google.com>
Tested-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit 4dff5c7b7093b19c19d3a100f8a3ad87cb7cd9e7 ]

snd_timer_user_read() has a potential race among parallel reads, as
qhead and qused are updated outside the critical section due to
copy_to_user() calls.  Move them into the critical section, and also
sanitize the relevant code a bit.

Change-Id: Id711a0383457550c849eaa9770dd3446309afc6e
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

[ Upstream commit 230323dac060123c340cf75997971145a42661ee ]

Currently ALSA timer device doesn't take the disconnection into
account very well; it merely unlinks the timer device at disconnection
callback but does nothing else.  Because of this, when an application
accessing the timer device is disconnected, it may release the
resource before actually closed.  In most cases, it results in a
warning message indicating a leftover timer instance like:
   ALSA: timer xxxx is busy?
But basically this is an open race.

This patch tries to address it.  The strategy is like other ALSA
devices: namely,
- Manage card's refcount at each open/close
- Wake up the pending tasks at disconnection
- Check the shutdown flag appropriately at each possible call

Note that this patch has one ugly hack to handle the wakeup of pending
tasks.  It'd be cleaner to introduce a new disconnect op to
snd_timer_instance ops.  But since it would lead to internal ABI
breakage and it eventually increase my own work when backporting to
stable kernels, I took a different path to implement locally in
timer.c.  A cleanup patch will follow at next for 4.5 kernel.

Change-Id: I05c7f0e7d28b63fc343091f800ceae9ec2afe4a4
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109431


Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit ba3021b2c79b2fa9114f92790a99deb27a65b728 upstream.

snd_timer_user_tselect() reallocates the queue buffer dynamically, but
it forgot to reset its indices.  Since the read may happen
concurrently with ioctl and snd_timer_user_tselect() allocates the
buffer via kmalloc(), this may lead to the leak of uninitialized
kernel-space data, as spotted via KMSAN:

  BUG: KMSAN: use of unitialized memory in snd_timer_user_read+0x6c4/0xa10
  CPU: 0 PID: 1037 Comm: probe Not tainted 4.11.0-rc5+ #2739
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
   __dump_stack lib/dump_stack.c:16
   dump_stack+0x143/0x1b0 lib/dump_stack.c:52
   kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:1007
   kmsan_check_memory+0xc2/0x140 mm/kmsan/kmsan.c:1086
   copy_to_user ./arch/x86/include/asm/uaccess.h:725
   snd_timer_user_read+0x6c4/0xa10 sound/core/timer.c:2004
   do_loop_readv_writev fs/read_write.c:716
   __do_readv_writev+0x94c/0x1380 fs/read_write.c:864
   do_readv_writev fs/read_write.c:894
   vfs_readv fs/read_write.c:908
   do_readv+0x52a/0x5d0 fs/read_write.c:934
   SYSC_readv+0xb6/0xd0 fs/read_write.c:1021
   SyS_readv+0x87/0xb0 fs/read_write.c:1018

This patch adds the missing reset of queue indices.  Together with the
previous fix for the ioctl/read race, we cover the whole problem.

Change-Id: Ibb66f942d7d8124fe6a6cf03ea53f442eacb9899
Reported-by: Alexander Potapenko <glider@google.com>
Tested-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a47e9cff994f37f7f0dbd9ae23740d0f64f9fe6 upstream.

The stack object “r1” has a total size of 32 bytes. Its field
“event” and “val” both contain 4 bytes padding. These 8 bytes
padding bytes are sent to user without being initialized.

Change-Id: I00887d278f9cab0d18dc05eacb32cdebe16bd93e
Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 117159f0b9d392fb433a7871426fad50317f06f7 upstream.

In snd_timer_notify1(), the wrong timer instance was passed for slave
ccallback function.  This leads to the access to the wrong data when
an incompatible master is handled (e.g. the master is the sequencer
timer and the slave is a user timer), as spotted by syzkaller fuzzer.

This patch fixes that wrong assignment.

Change-Id: I2da6e348cf3b21af377cec3a5b7829861e088940
BugLink: http://lkml.kernel.org/r/CACT4Y+Y_Bm+7epAb=8Wi=AaWd+DYS7qawX52qxdCfOfY49vozQ@mail.gmail.com


Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 37240993

* changes:
  android: binder: Move buffer out of area shared with user space
  android: binder: Refactor prev and next buffer into a helper function
  binder: always allocate/map first BINDER_MIN_ALLOC pages

commit 321027c1fe77f892f4ea07846aeae08cefbbb290 upstream.
commit fe525a280e8b5f04c7666fe22d1a4ef592f7b953 in 3.16.40
bug: 37901413

Di Shen reported a race between two concurrent sys_perf_event_open()
calls where both try and move the same pre-existing software group
into a hardware context.

The problem is exactly that described in commit:

  f63a8daa5812 ("perf: Fix event->ctx locking")

... where, while we wait for a ctx->mutex acquisition, the event->ctx
relation can have changed under us.

That very same commit failed to recognise sys_perf_event_context() as an
external access vector to the events and thereby didn't apply the
established locking rules correctly.

So while one sys_perf_event_open() call is stuck waiting on
mutex_lock_double(), the other (which owns said locks) moves the group
about. So by the time the former sys_perf_event_open() acquires the
locks, the context we've acquired is stale (and possibly dead).

Apply the established locking rules as per perf_event_ctx_lock_nested()
to the mutex_lock_double() for the 'move_group' case. This obviously means
we need to validate state after we acquire the locks.

Reported-by: Di Shen (Keen Lab)
Tested-by: John Dias <joaodias@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Min Chong <mchong@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Fixes: f63a8daa5812 ("perf: Fix event->ctx locking")
Link: http://lkml.kernel.org/r/20170106131444.GZ3174@twins.programming.kicks-ass.net


Signed-off-by: Ingo Molnar <mingo@kernel.org>
[bwh: Backported to 3.16:
 - Use ACCESS_ONCE() instead of READ_ONCE()
 - Test perf_event::group_flags instead of group_caps
 - Add the err_locked cleanup block, which we didn't need before
 - Adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ia2d0cc085ee169a0ea70090054f5e5973fbd3a3e

commit 8f44c9a41386729fea410e688959ddaa9d51be7c upstream.

The lower level nl80211 code in cfg80211 ensures that "len" is between
25 and NL80211_ATTR_FRAME (2304).  We subtract DOT11_MGMT_HDR_LEN (24) from
"len" so thats's max of 2280.  However, the action_frame->data[] buffer is
only BRCMF_FIL_ACTION_FRAME_SIZE (1800) bytes long so this memcpy() can
overflow.

	memcpy(action_frame->data, &buf[DOT11_MGMT_HDR_LEN],
	       le16_to_cpu(action_frame->len));

(cherry picked from commit ae10cf5c80b897b3a46ef1bdf77a52dd84bd336d)

Bug: 64258073
Fixes: 18e2f61d ("brcmfmac: P2P action frame tx.")
Reported-by: "freenerguo(郭大兴)" <freenerguo@tencent.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: Iec2e6c99d113ef95127525a92336b6ccdbd10cb8

This was reported many times, and this was even mentioned in commit
52ee2dfd "pids: refactor vnr/nr_ns helpers to make them safe" but
somehow nobody bothered to fix the obvious problem: task_tgid_nr_ns()
is not safe because task->group_leader points to nowhere after the
exiting task passes exit_notify(), rcu_read_lock() can not help.

We really need to change __unhash_process() to nullify group_leader,
parent, and real_parent, but this needs some cleanups. Until then we
can turn task_tgid_nr_ns() into another user of __task_pid_nr_ns() and
fix the problem.

Reported-by: Troy Kensinger <tkensinger@google.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

(cherry picked from commit dd1c1f2f2028a7b851f701fc6a8ebe39dcb95e7c)
Bug: 31495866

Change-Id: Iad19a77f4f0aa9f3b6b0539ac9c549fa64c18550

nla policy checks for only maximum length of the attribute data
when the attribute type is NLA_BINARY. If userspace sends less
data than specified, the wireless drivers may access illegal
memory. When type is NLA_UNSPEC, nla policy check ensures that
userspace sends minimum specified length number of bytes.

Remove type assignment to NLA_BINARY from nla_policy of
NL80211_ATTR_PMKID to make this NLA_UNSPEC and to make sure minimum
WLAN_PMKID_LEN bytes are received from userspace with
NL80211_ATTR_PMKID.

Fixes: 67fbb16b ("nl80211: PMKSA caching support")
Cc: stable@vger.kernel.org
Bug: 36818836
Signed-off-by: Srinivas Dasari <dasaris@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git


Git-commit: 9361df14d1cbf966409d5d6f48bb334384fbe138
Change-Id: I5feb729a9ef48f67c4ee460e7e133d5fc8cecd4f
CRs-Fixed: 2061676
Signed-off-by: Srinivas Dasari <dasaris@codeaurora.org>

Buffer overread may happen as nl80211_set_station() reads 4 bytes
from the attribute NL80211_ATTR_LOCAL_MESH_POWER_MODE without
validating the size of data received when userspace sends less
than 4 bytes of data with NL80211_ATTR_LOCAL_MESH_POWER_MODE.
Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE to avoid
the buffer overread.

Fixes: 3b1c5a53 ("{cfg,nl}80211: mesh power mode primitives and userspace access")
Cc: stable@vger.kernel.org
Bug: 36819059
Signed-off-by: Srinivas Dasari <dasaris@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git


Git-commit: 8feb69c7bd89513be80eb19198d48f154b254021
Change-Id: Ie20993309501fd242782311b9fe787931f716116
CRs-Fixed: 2055013
Signed-off-by: Srinivas Dasari <dasaris@codeaurora.org>

Binder driver allocates buffer meta data in a region that is mapped
in user space. These meta data contain pointers in the kernel.

This patch allocates buffer meta data on the kernel heap that is
not mapped in user space, and uses a pointer to refer to the data mapped.

Also move alloc->buffers initialization from mmap to init since it's
now used even when mmap failed or was not called.

Bug: 36007193
Change-Id: Id5136048bdb7b796f59de066de7ea7df410498f5
Signed-off-by: Sherry Yang <sherryy@android.com>

Bug: 36007193
Change-Id: I422dce84afde3d2138a6d976593b109a9cc49003
Signed-off-by: Sherry Yang <sherryy@android.com>

Certain usecases like camera are constantly allocating and freeing
binder buffers beyond the first 4k resulting in mmap_sem contention.

If we expand the allocated range from 4k to something higher, we can
reduce the contention. Tests show that 6 pages is enough to cause very
little update_page_range operations and reduces contention.

Bug: 36727951

Change-Id: I28bc3fb9b33c764c257e28487712fce2a3c1078b
Reported-by: Tim Murray <timmurray@google.com>
Signed-off-by: Joel Fernandes <joelaf@google.com>

Pre-allocate 1 instead of 6 pages as in the original patch,
as we use this pre-allocated page to prevent the first page
from getting unpinned after removing the buffer headers,
rather than pinning pages to speedup larger transactions.

Change-Id: I7c3e4884a9538ecfd86601d31c5bcfd6611d37a4
Signed-off-by: Sherry Yang <sherryy@android.com>

Retrieve socket uid from the sk_uid field added to struct sk instead of
read it from sk->socket->file. It prevent the packet been dropped when
the socket file doesn't exist.

Bug: 37524657
Signed-off-by: Chenbo Feng <fengc@google.com>
Change-Id: Ic58239c1f9aa7e0eb1d4d1c09d40b845fd4e8e57

* fix skb->dev vs par->in/out
When there is some forwarding going on, it introduces extra state
around devs associated with xt_action_param->in/out and sk_buff->dev.
E.g.
   par->in and par->out are both set, or
   skb->dev and par->out are both set (and different)
This would lead qtaguid to make the wrong assumption about the
direction and update the wrong device stats.
Now we rely more on par->in/out.

* Fix handling when qtaguid is used as "owner"
When qtaguid is used as an owner module, and sk_socket->file is
not there (happens when tunnels are involved), it would
incorrectly do a tag stats update.

* Correct debug messages.

Bug: 11687690
Change-Id: I2b1ff8bd7131969ce9e25f8291d83a6280b3ba7f
CRs-Fixed: 747810
Signed-off-by: JP Abgrall <jpa@google.com>
Git-commit: 2b71479d6f5fe8f33b335f713380f72037244395
Git-repo: https://www.codeaurora.org/cgit/quic/la/kernel/mediatek


[imaund@codeaurora.org: Resolved trivial context conflicts.]
Signed-off-by: Ian Maund <imaund@codeaurora.org>
[bflowers@codeaurora.org: Resolved merge conflicts]
Signed-off-by: Bryse Flowers <bflowers@codeaurora.org>
Signed-off-by: Chenbo Feng <fengc@google.com>

* changes:
  ANDROID: binder: don't queue async transactions to thread.
  Add BINDER_GET_NODE_DEBUG_INFO ioctl

Signed-off-by: Daniel Rosenberg <drosen@google.com>
Bug: 63245673
Change-Id: I5fc596420301045895e5a9a7e297fd05434babf9

This moves the code to adjust the gid/uid of lower filesystem
files under the mount flag derive_gid.

Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I44eaad4ef67c7fcfda3b6ea3502afab94442610c
Bug: 63245673

Fix double free on error paths

Signed-off-by: Daniel Rosenberg <drosen@google.com>
Change-Id: I1c25a175e87e5dd5cafcdcf9d78bf4c0dc3f88ef
Bug: 65386954
Fixes: c9b3c8159e5c ("mnt: Add filesystem private data to mount points")

This can cause issues with processes using the poll()
interface:

1) client sends two oneway transactions
2) the second one gets queued on async_todo
   (because the server didn't handle the first one
    yet)
3) server returns from poll(), picks up the
   first transaction and does transaction work
4) server is done with the transaction, sends
   BC_FREE_BUFFER, and the second transaction gets
   moved to thread->todo
5) libbinder's handlePolledCommands() only handles
   the commands in the current data buffer, so
   doesn't see the new transaction
6) the server continues running and issues a new
   outgoing transaction. Now, it suddenly finds
   the incoming oneway transaction on its thread
   todo, and returns that to userspace.
7) userspace does not expect this to happen; it
   may be holding a lock while making the outgoing
   transaction, and if handling the incoming
   transaction requires taking the same lock,
   userspace will deadlock.

By queueing the async transaction to the proc
workqueue, we make sure it's only picked up when
a thread is ready for proc work.

Bug: 38201220
Bug: 63075553
Bug: 63079216

Change-Id: I84268cc112f735d7e3173793873dfdb4b268468b
Signed-off-by: Martijn Coenen <maco@android.com>

The BINDER_GET_NODE_DEBUG_INFO ioctl will return debug info on
a node.  Each successive call reusing the previous return value
will return the next node.  The data will be used by
libmemunreachable to mark the pointers with kernel references
as reachable.

Bug: 28275695
Change-Id: Idbbafa648a33822dc023862cd92b51a595cf7c1c
Signed-off-by: Colin Cross <ccross@android.com>

* changes:
  UPSTREAM: arm64: perf: Fix callchain parse error with kernel tracepoint events
  UPSTREAM: arm: perf: Fix callchain parse error with kernel tracepoint events
  UPSTREAM: ARM: 8170/1: Add global named register current_stack_pointer for ARM

For ARM64, when tracing with tracepoint events, the IP and pstate are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
    [ perf record: Captured and wrote 0.146 MB perf.data ]
 ./perf report -f
    Samples: 194  of event 'sched:sched_switch', Event count (approx.): 194
    Children      Self    Command  Shared Object     Symbol
    100.00%       100.00%  ls       [unknown]         [.] 0000000000000000

The fix is to implement perf_arch_fetch_caller_regs for ARM64, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and spsr .

With this patch, callchain can be parsed correctly as follows:

     ......
+    2.63%     0.00%  ls       [kernel.kallsyms]  [k] vfs_symlink
+    2.63%     0.00%  ls       [kernel.kallsyms]  [k] follow_down
+    2.63%     0.00%  ls       [kernel.kallsyms]  [k] pfkey_get
+    2.63%     0.00%  ls       [kernel.kallsyms]  [k] do_execveat_common.isra.33
-    2.63%     0.00%  ls       [kernel.kallsyms]  [k] pfkey_send_policy_notify
     pfkey_send_policy_notify
     pfkey_get
     v9fs_vfs_rename
     page_follow_link_light
     link_path_walk
     el0_svc_naked
    .......

Signed-off-by: Hou Pengyang <houpengyang@huawei.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
(Cherry picked from commit 5b09a094f2fb768c76c8d4a82503df6fc7e1df63)
Bug: 29520177
Signed-off-by: Mohan Srinivasan <srmohan@google.com>
Change-Id: Iae65334c1ae27f8ae81ca2c11ffc8564dc61f51f

For ARM, when tracing with tracepoint events, the IP and cpsr are set
to 0, preventing the perf code parsing the callchain and resolving the
symbols correctly.

 ./perf record -e sched:sched_switch -g --call-graph dwarf ls
    [ perf record: Captured and wrote 0.006 MB perf.data ]
 ./perf report -f
    Samples: 5  of event 'sched:sched_switch', Event count (approx.): 5
    Children      Self    Command  Shared Object     Symbol
    100.00%       100.00%  ls       [unknown]         [.] 00000000

The fix is to implement perf_arch_fetch_caller_regs for ARM, which fills
several necessary registers used for callchain unwinding, including pc,sp,
fp and cpsr.

With this patch, callchain can be parsed correctly as :

   .....
-  100.00%   100.00%  ls       [kernel.kallsyms]  [k] __sched_text_start
   + __sched_text_start
+   20.00%     0.00%  ls       libc-2.18.so       [.] _dl_addr
+   20.00%     0.00%  ls       libc-2.18.so       [.] write
   .....

Jean Pihet found this in ARM and come up with a patch:
http://thread.gmane.org/gmane.linux.kernel/1734283/focus=1734280



This patch rewrite Jean's patch in C.

Signed-off-by: Hou Pengyang <houpengyang@huawei.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
(cherry picked from commit b3eac0265bf6258f08dcd4ac7fa7f87cc050defc)
Bug: 29520177
Signed-off-by: Mohan Srinivasan <srmohan@google.com>
Change-Id: Ia87ea58982acdf3bcdfa43bdeed92539f46e8b0c

Define a global named register for current_stack_pointer. The use of this new
variable guarantees that both gcc and clang can access this register in C code.

Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit 0abc08baf2ddf61a37d375a9fb832be612f9c5a5)
Bug: 29520177
Signed-off-by: Mohan Srinivasan <srmohan@google.com>
Change-Id: I35d828dc5787d5ec698ec4fba5cbc352805f92e8

(cherry picked from commit 096f41d3a8fcbb8dde7f71379b1ca85fe213eded)

The parsing of sadb_x_ipsecrequest is broken in a number of ways.
First of all we're not verifying sadb_x_ipsecrequest_len.  This
is needed when the structure carries addresses at the end.  Worse
we don't even look at the length when we parse those optional
addresses.

The migration code had similar parsing code that's better but
it also has some deficiencies.  The length is overcounted first
of all as it includes the header itself.  It also fails to check
the length before dereferencing the sa_family field.

This patch fixes those problems in parse_sockaddr_pair and then
uses it in parse_ipsecrequest.

Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Bug: 63963140
Change-Id: Ie8854131293bc8153bfb8cb255161ec8f03667f9

"sd_devreg" IOVAR can cause out of bounds access when user input
manipulated. Proposed fix is removing debug oriented IOVARs completely.

Signed-off-by: Insun Song <insun.song@broadcom.com>
Bug: 37622847
Change-Id: I8fc5111fe9d8d2c5d7ae5b1c24ae8e531113beae

When the device descriptor is closed, the `substream->runtime` pointer
is freed. But another thread may be in the ioctl handler, case
SNDRV_CTL_IOCTL_PCM_INFO. This case calls snd_pcm_info_user() which
calls snd_pcm_info() which accesses the now freed `substream->runtime`.

Bug: 36006981
Signed-off-by: Robb Glasser <rglasser@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Change-Id: I445d24bc21dc0af6d9522a8daabe64969042236a