<feed xmlns='http://www.w3.org/2005/Atom'>
<title>xavi/android_kernel_m2note, branch mm-6.0</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<id>https://gitea.privatedns.org/xavi/android_kernel_m2note/atom?h=mm-6.0</id>
<link rel='self' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/atom?h=mm-6.0'/>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/'/>
<updated>2016-11-24T20:16:50+00:00</updated>
<entry>
<title>Revert "proc: Remove verifiedbootstate flag from /proc/cmdline"</title>
<updated>2016-11-24T20:16:50+00:00</updated>
<author>
<name>Moyster</name>
<email>oysterized@gmail.com</email>
</author>
<published>2016-11-24T20:16:50+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=c15ea3464b6d7bf47e400485a66184adf4171aa2'/>
<id>urn:sha1:c15ea3464b6d7bf47e400485a66184adf4171aa2</id>
<content type='text'>
This commit breaks Offline Charging mode on Mediatek platforms (at least mt6753 and mt6795)

This reverts commit 81cd48af4ce91983fa556039f52bdede850c4e52.
</content>
</entry>
<entry>
<title>regen defconfig</title>
<updated>2016-11-18T17:37:38+00:00</updated>
<author>
<name>Moyster</name>
<email>oysterized@gmail.com</email>
</author>
<published>2016-11-18T17:37:38+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=fd2a0da6b07a394f0fe83d1187f668004651305e'/>
<id>urn:sha1:fd2a0da6b07a394f0fe83d1187f668004651305e</id>
<content type='text'>
</content>
</entry>
<entry>
<title>add CC_STACK_PROTECTOR_STRONG to android-recommended.cfg so regening defconf doesn't unset it</title>
<updated>2016-11-18T17:34:21+00:00</updated>
<author>
<name>Moyster</name>
<email>oysterized@gmail.com</email>
</author>
<published>2016-11-18T17:34:21+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=40437bbdefb3a6d1c6c075f5d2fe9a7febfde581'/>
<id>urn:sha1:40437bbdefb3a6d1c6c075f5d2fe9a7febfde581</id>
<content type='text'>
</content>
</entry>
<entry>
<title>UPSTREAM: capabilities: ambient capabilities</title>
<updated>2016-11-18T12:30:33+00:00</updated>
<author>
<name>Andy Lutomirski</name>
<email>luto@kernel.org</email>
</author>
<published>2015-09-04T22:42:45+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=153f11f36a7ef0d73fa77592fc1b2c7f200ddabf'/>
<id>urn:sha1:153f11f36a7ef0d73fa77592fc1b2c7f200ddabf</id>
<content type='text'>
Credit where credit is due: this idea comes from Christoph Lameter with
a lot of valuable input from Serge Hallyn.  This patch is heavily based
on Christoph's patch.

===== The status quo =====

On Linux, there are a number of capabilities defined by the kernel.  To
perform various privileged tasks, processes can wield capabilities that
they hold.

Each task has four capability masks: effective (pE), permitted (pP),
inheritable (pI), and a bounding set (X).  When the kernel checks for a
capability, it checks pE.  The other capability masks serve to modify
what capabilities can be in pE.

Any task can remove capabilities from pE, pP, or pI at any time.  If a
task has a capability in pP, it can add that capability to pE and/or pI.
If a task has CAP_SETPCAP, then it can add any capability to pI, and it
can remove capabilities from X.

Tasks are not the only things that can have capabilities; files can also
have capabilities.  A file can have no capabilty information at all [1].
If a file has capability information, then it has a permitted mask (fP)
and an inheritable mask (fI) as well as a single effective bit (fE) [2].
File capabilities modify the capabilities of tasks that execve(2) them.

A task that successfully calls execve has its capabilities modified for
the file ultimately being excecuted (i.e.  the binary itself if that
binary is ELF or for the interpreter if the binary is a script.) [3] In
the capability evolution rules, for each mask Z, pZ represents the old
value and pZ' represents the new value.  The rules are:

  pP' = (X &amp; fP) | (pI &amp; fI)
  pI' = pI
  pE' = (fE ? pP' : 0)
  X is unchanged

For setuid binaries, fP, fI, and fE are modified by a moderately
complicated set of rules that emulate POSIX behavior.  Similarly, if
euid == 0 or ruid == 0, then fP, fI, and fE are modified differently
(primary, fP and fI usually end up being the full set).  For nonroot
users executing binaries with neither setuid nor file caps, fI and fP
are empty and fE is false.

As an extra complication, if you execute a process as nonroot and fE is
set, then the "secure exec" rules are in effect: AT_SECURE gets set,
LD_PRELOAD doesn't work, etc.

This is rather messy.  We've learned that making any changes is
dangerous, though: if a new kernel version allows an unprivileged
program to change its security state in a way that persists cross
execution of a setuid program or a program with file caps, this
persistent state is surprisingly likely to allow setuid or file-capped
programs to be exploited for privilege escalation.

===== The problem =====

Capability inheritance is basically useless.

If you aren't root and you execute an ordinary binary, fI is zero, so
your capabilities have no effect whatsoever on pP'.  This means that you
can't usefully execute a helper process or a shell command with elevated
capabilities if you aren't root.

On current kernels, you can sort of work around this by setting fI to
the full set for most or all non-setuid executable files.  This causes
pP' = pI for nonroot, and inheritance works.  No one does this because
it's a PITA and it isn't even supported on most filesystems.

If you try this, you'll discover that every nonroot program ends up with
secure exec rules, breaking many things.

This is a problem that has bitten many people who have tried to use
capabilities for anything useful.

===== The proposed change =====

This patch adds a fifth capability mask called the ambient mask (pA).
pA does what most people expect pI to do.

pA obeys the invariant that no bit can ever be set in pA if it is not
set in both pP and pI.  Dropping a bit from pP or pI drops that bit from
pA.  This ensures that existing programs that try to drop capabilities
still do so, with a complication.  Because capability inheritance is so
broken, setting KEEPCAPS, using setresuid to switch to nonroot uids, and
then calling execve effectively drops capabilities.  Therefore,
setresuid from root to nonroot conditionally clears pA unless
SECBIT_NO_SETUID_FIXUP is set.  Processes that don't like this can
re-add bits to pA afterwards.

The capability evolution rules are changed:

  pA' = (file caps or setuid or setgid ? 0 : pA)
  pP' = (X &amp; fP) | (pI &amp; fI) | pA'
  pI' = pI
  pE' = (fE ? pP' : pA')
  X is unchanged

If you are nonroot but you have a capability, you can add it to pA.  If
you do so, your children get that capability in pA, pP, and pE.  For
example, you can set pA = CAP_NET_BIND_SERVICE, and your children can
automatically bind low-numbered ports.  Hallelujah!

Unprivileged users can create user namespaces, map themselves to a
nonzero uid, and create both privileged (relative to their namespace)
and unprivileged process trees.  This is currently more or less
impossible.  Hallelujah!

You cannot use pA to try to subvert a setuid, setgid, or file-capped
program: if you execute any such program, pA gets cleared and the
resulting evolution rules are unchanged by this patch.

Users with nonzero pA are unlikely to unintentionally leak that
capability.  If they run programs that try to drop privileges, dropping
privileges will still work.

It's worth noting that the degree of paranoia in this patch could
possibly be reduced without causing serious problems.  Specifically, if
we allowed pA to persist across executing non-pA-aware setuid binaries
and across setresuid, then, naively, the only capabilities that could
leak as a result would be the capabilities in pA, and any attacker
*already* has those capabilities.  This would make me nervous, though --
setuid binaries that tried to privilege-separate might fail to do so,
and putting CAP_DAC_READ_SEARCH or CAP_DAC_OVERRIDE into pA could have
unexpected side effects.  (Whether these unexpected side effects would
be exploitable is an open question.) I've therefore taken the more
paranoid route.  We can revisit this later.

An alternative would be to require PR_SET_NO_NEW_PRIVS before setting
ambient capabilities.  I think that this would be annoying and would
make granting otherwise unprivileged users minor ambient capabilities
(CAP_NET_BIND_SERVICE or CAP_NET_RAW for example) much less useful than
it is with this patch.

===== Footnotes =====

[1] Files that are missing the "security.capability" xattr or that have
unrecognized values for that xattr end up with has_cap set to false.
The code that does that appears to be complicated for no good reason.

[2] The libcap capability mask parsers and formatters are dangerously
misleading and the documentation is flat-out wrong.  fE is *not* a mask;
it's a single bit.  This has probably confused every single person who
has tried to use file capabilities.

[3] Linux very confusingly processes both the script and the interpreter
if applicable, for reasons that elude me.  The results from thinking
about a script's file capabilities and/or setuid bits are mostly
discarded.

Preliminary userspace code is here, but it needs updating:
https://git.kernel.org/cgit/linux/kernel/git/luto/util-linux-playground.git/commit/?h=cap_ambient&amp;id=7f5afbd175d2

Here is a test program that can be used to verify the functionality
(from Christoph):

/*
 * Test program for the ambient capabilities. This program spawns a shell
 * that allows running processes with a defined set of capabilities.
 *
 * (C) 2015 Christoph Lameter &lt;cl@linux.com&gt;
 * Released under: GPL v3 or later.
 *
 *
 * Compile using:
 *
 *	gcc -o ambient_test ambient_test.o -lcap-ng
 *
 * This program must have the following capabilities to run properly:
 * Permissions for CAP_NET_RAW, CAP_NET_ADMIN, CAP_SYS_NICE
 *
 * A command to equip the binary with the right caps is:
 *
 *	setcap cap_net_raw,cap_net_admin,cap_sys_nice+p ambient_test
 *
 *
 * To get a shell with additional caps that can be inherited by other processes:
 *
 *	./ambient_test /bin/bash
 *
 *
 * Verifying that it works:
 *
 * From the bash spawed by ambient_test run
 *
 *	cat /proc/$$/status
 *
 * and have a look at the capabilities.
 */

/*
 * Definitions from the kernel header files. These are going to be removed
 * when the /usr/include files have these defined.
 */

static void set_ambient_cap(int cap)
{
	int rc;

	capng_get_caps_process();
	rc = capng_update(CAPNG_ADD, CAPNG_INHERITABLE, cap);
	if (rc) {
		printf("Cannot add inheritable cap\n");
		exit(2);
	}
	capng_apply(CAPNG_SELECT_CAPS);

	/* Note the two 0s at the end. Kernel checks for these */
	if (prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, cap, 0, 0)) {
		perror("Cannot set cap");
		exit(1);
	}
}

int main(int argc, char **argv)
{
	int rc;

	set_ambient_cap(CAP_NET_RAW);
	set_ambient_cap(CAP_NET_ADMIN);
	set_ambient_cap(CAP_SYS_NICE);

	printf("Ambient_test forking shell\n");
	if (execv(argv[1], argv + 1))
		perror("Cannot exec");

	return 0;
}

Signed-off-by: Christoph Lameter &lt;cl@linux.com&gt; # Original author
Signed-off-by: Andy Lutomirski &lt;luto@kernel.org&gt;
Acked-by: Serge E. Hallyn &lt;serge.hallyn@ubuntu.com&gt;
Acked-by: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Cc: Aaron Jones &lt;aaronmdjones@gmail.com&gt;
Cc: Ted Ts'o &lt;tytso@mit.edu&gt;
Cc: Andrew G. Morgan &lt;morgan@kernel.org&gt;
Cc: Mimi Zohar &lt;zohar@linux.vnet.ibm.com&gt;
Cc: Austin S Hemmelgarn &lt;ahferroin7@gmail.com&gt;
Cc: Markku Savela &lt;msa@moth.iki.fi&gt;
Cc: Jarkko Sakkinen &lt;jarkko.sakkinen@linux.intel.com&gt;
Cc: Michael Kerrisk &lt;mtk.manpages@gmail.com&gt;
Cc: James Morris &lt;james.l.morris@oracle.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
(cherry picked from commit 58319057b7847667f0c9585b9de0e8932b0fdb08)

Bug: 31038224
Change-Id: I88bc5caa782dc6be23dc7e839ff8e11b9a903f8c
Signed-off-by: Jorge Lucangeli Obes &lt;jorgelo@google.com&gt;
</content>
</entry>
<entry>
<title>cleanup defconfigs</title>
<updated>2016-11-17T11:30:17+00:00</updated>
<author>
<name>Moyster</name>
<email>oysterized@gmail.com</email>
</author>
<published>2016-11-17T11:30:17+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=a74002c2580bdc23c8861e5fdaa0d06720b10cdb'/>
<id>urn:sha1:a74002c2580bdc23c8861e5fdaa0d06720b10cdb</id>
<content type='text'>
</content>
</entry>
<entry>
<title>defconfig: Add IPv6 rpfilter support</title>
<updated>2016-11-17T11:20:20+00:00</updated>
<author>
<name>Moyster</name>
<email>oysterized@gmail.com</email>
</author>
<published>2016-11-13T18:10:23+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=32e468a7d0ef0ec6f042e9c00da31efc0aae9849'/>
<id>urn:sha1:32e468a7d0ef0ec6f042e9c00da31efc0aae9849</id>
<content type='text'>
</content>
</entry>
<entry>
<title>UPSTREAM: perf: Fix race in swevent hash</title>
<updated>2016-11-17T11:20:19+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>peterz@infradead.org</email>
</author>
<published>2015-12-15T12:49:05+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=96a612f38b438df9216adaf4ac5d3850d77806f9'/>
<id>urn:sha1:96a612f38b438df9216adaf4ac5d3850d77806f9</id>
<content type='text'>
(cherry picked from commit 12ca6ad2e3a896256f086497a7c7406a547ee373)

There's a race on CPU unplug where we free the swevent hash array
while it can still have events on. This will result in a
use-after-free which is BAD.

Simply do not free the hash array on unplug. This leaves the thing
around and no use-after-free takes place.

When the last swevent dies, we do a for_each_possible_cpu() iteration
anyway to clean these up, at which time we'll free it, so no leakage
will occur.

Reported-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Tested-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Cc: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Stephane Eranian &lt;eranian@google.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Vince Weaver &lt;vincent.weaver@maine.edu&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Change-Id: I14c0679a2934dccdbb052805e6430fe54b5978f0
Bug: 30952077
</content>
</entry>
<entry>
<title>ipv6: fix endianness error in icmpv6_err</title>
<updated>2016-11-17T11:20:19+00:00</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2016-06-11T18:32:06+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=f2805e15d3944d77a01db2044b0bc7b1f13d16f6'/>
<id>urn:sha1:f2805e15d3944d77a01db2044b0bc7b1f13d16f6</id>
<content type='text'>
IPv6 ping socket error handler doesn't correctly convert the new 32 bit
mtu to host endianness before using.

[Cherry-pick of net dcb94b88c09ce82a80e188d49bcffdc83ba215a6]

Bug: 29370996
Change-Id: Idf475e2555252d91e1d3fa92071a661242780074
Cc: Lorenzo Colitti &lt;lorenzo@google.com&gt;
Fixes: 6d0bfe22611602f ("net: ipv6: Add IPv6 support to the ping socket.")
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Acked-by: Lorenzo Colitti &lt;lorenzo@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: ipv6: Fix ping to link-local addresses.</title>
<updated>2016-11-17T11:20:19+00:00</updated>
<author>
<name>Lorenzo Colitti</name>
<email>lorenzo@google.com</email>
</author>
<published>2016-08-12T16:13:38+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=e3cb9f56ec3124355d5f817f1b7d892d2b9ead32'/>
<id>urn:sha1:e3cb9f56ec3124355d5f817f1b7d892d2b9ead32</id>
<content type='text'>
ping_v6_sendmsg does not set flowi6_oif in response to
sin6_scope_id or sk_bound_dev_if, so it is not possible to use
these APIs to ping an IPv6 address on a different interface.
Instead, it sets flowi6_iif, which is incorrect but harmless.

Stop setting flowi6_iif, and support various ways of setting oif
in the same priority order used by udpv6_sendmsg.

[Backport of net 5e457896986e16c440c97bb94b9ccd95dd157292]

Bug: 29370996
Change-Id: I2c8bc213c417a4427f64439e0954138cb30416c2
Tested: https://android-review.googlesource.com/#/c/254470/
Signed-off-by: Lorenzo Colitti &lt;lorenzo@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>cgroup: prefer %pK to %p</title>
<updated>2016-11-17T11:20:03+00:00</updated>
<author>
<name>Nick Desaulniers</name>
<email>ndesaulniers@google.com</email>
</author>
<published>2016-09-13T18:11:03+00:00</published>
<link rel='alternate' type='text/html' href='https://gitea.privatedns.org/xavi/android_kernel_m2note/commit/?id=2c81b0d8b41b0fbeb974589eec5ed76d405106e0'/>
<id>urn:sha1:2c81b0d8b41b0fbeb974589eec5ed76d405106e0</id>
<content type='text'>
Prevents leaking kernel pointers when using kptr_restrict.

Bug: 30149174
Change-Id: I76d4132a0f47f4b0a9f042b8269e0f24edd111ed
</content>
</entry>
</feed>
