Age | Commit message (Collapse) | Author |
|
We had for some reason overlooked the AIO interface, and it didn't use
the proper rw_verify_area() helper function that checks (for example)
mandatory locking on the file, and that the size of the access doesn't
cause us to overflow the provided offset limits etc.
Instead, AIO did just the security_file_permission() thing (that
rw_verify_area() also does) directly.
This fixes it to do all the proper helper functions, which not only
means that now mandatory file locking works with AIO too, we can
actually remove lines of code.
Reported-by: Manish Honap <manish_honap_vit@yahoo.co.in>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit a70b52ec1aaeaf60f4739edb1b422827cb6f3893)
Conflicts:
fs/aio.c
Issue: KIONE-3528
Change-Id: I16f425d86e886a50b20fd397ce6f4f8cf1d60dd7
|
|
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.
Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit e4ec8cc8039a7063e24204299b462bd1383184a5)
Issue: KIONE-3528
Change-Id: I87461ee61c53faadffdce885c409efad723ce54d
|
|
The stack object “tread” 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.
Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit cec8f96e49d9be372fdb0c3836dcf31ec71e457e)
Issue: KIONE-3528
Change-Id: I20cefac7063b2bcaf36bd900f9416b165793ed62
|
|
The stack object “map” has a total size of 32 bytes. Its last 4
bytes are padding generated by compiler. These padding bytes are
not initialized and sent out via “nla_put”
Based on commit: 5f8e44741f9f216e33736ea4ec65ca9ac03036e6
Issue: KIONE-3528
Change-Id: I9aa63aea0f4ea32345c2533e8bc15650c11a7c8e
|
|
The stack object “ci” has a total size of 8 bytes. Its last 3 bytes
are padding bytes which are not initialized and leaked to userland
via “copy_to_user”.
Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 681fef8380eb818c0b845fca5d2ab1dcbab114ee)
Issue: KIONE-3528
Change-Id: I2bd78852468208787451ce7f4d0a8d7c04f8ea00
|
|
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".
Signed-off-by: Hector Marco-Gisbert <hecmargi@upv.es>
Acked-by: Ismael Ripoll Ripoll <iripoll@upv.es>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Arjan 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: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 8b8addf891de8a00e4d39fc32f93f7c5eb8feceb)
Conflicts:
arch/x86/mm/mmap.c
Issue: KIONE-3528
Change-Id: I46db1d3741ce062694bc501833dbabec495f9448
|
|
The issue is that the stack for processes is not properly randomized on
64 bit architectures due to an integer overflow.
The affected function is randomize_stack_top() in file
"fs/binfmt_elf.c":
static unsigned long randomize_stack_top(unsigned long stack_top)
{
unsigned int random_variable = 0;
if ((current->flags & PF_RANDOMIZE) &&
!(current->personality & ADDR_NO_RANDOMIZE)) {
random_variable = get_random_int() & STACK_RND_MASK;
random_variable <<= PAGE_SHIFT;
}
return PAGE_ALIGN(stack_top) + random_variable;
return PAGE_ALIGN(stack_top) - random_variable;
}
Note that, it declares the "random_variable" variable as "unsigned int".
Since the result of the shifting operation between STACK_RND_MASK (which
is 0x3fffff on x86_64, 22 bits) and PAGE_SHIFT (which is 12 on x86_64):
random_variable <<= PAGE_SHIFT;
then the two leftmost bits are dropped when storing the result in the
"random_variable". This variable shall be at least 34 bits long to hold
the (22+12) result.
These two dropped bits have an impact on the entropy of process stack.
Concretely, the total stack entropy is reduced by four: from 2^28 to
2^30 (One fourth of expected entropy).
This patch restores back the entropy by correcting the types involved
in the operations in the functions randomize_stack_top() and
stack_maxrandom_size().
The successful fix can be tested with:
$ for i in `seq 1 10`; do cat /proc/self/maps | grep stack; done
7ffeda566000-7ffeda587000 rw-p 00000000 00:00 0 [stack]
7fff5a332000-7fff5a353000 rw-p 00000000 00:00 0 [stack]
7ffcdb7a1000-7ffcdb7c2000 rw-p 00000000 00:00 0 [stack]
7ffd5e2c4000-7ffd5e2e5000 rw-p 00000000 00:00 0 [stack]
...
Once corrected, the leading bytes should be between 7ffc and 7fff,
rather than always being 7fff.
Signed-off-by: Hector Marco-Gisbert <hecmargi@upv.es>
Signed-off-by: Ismael Ripoll <iripoll@upv.es>
[ Rebased, fixed 80 char bugs, cleaned up commit message, added test example and CVE ]
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: <stable@vger.kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Fixes: CVE-2015-1593
Link: http://lkml.kernel.org/r/20150214173350.GA18393@www.outflux.net
Signed-off-by: Borislav Petkov <bp@suse.de>
(cherry picked from commit 4e7c22d447bb6d7e37bfe39ff658486ae78e8d77)
Issue: KIONE-3528
Change-Id: Ie4649e67be928a8920e9a5c071ca4b0aed9cefbb
|
|
I previously added an integer overflow check here but looking at it now,
it's still buggy.
The bug happens in snd_compr_allocate_buffer(). We multiply
".fragments" and ".fragment_size" and that doesn't overflow but then we
save it in an unsigned int so it truncates the high bits away and we
allocate a smaller than expected size.
Fixes: b35cc8225845 ('ALSA: compress_core: integer overflow in snd_compr_allocate_buffer()')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 6217e5ede23285ddfee10d2e4ba0cc2d4c046205)
Issue: KIONE-3528
Change-Id: I05e99c9f6db7fca6599a254c33d8e628f31cedf0
|
|
ALSA timer ioctls have an open race and this may lead to a
use-after-free of timer instance object. A simplistic fix is to make
each ioctl exclusive. We have already tread_sem for controlling the
tread, and extend this as a global mutex to be applied to each ioctl.
The downside is, of course, the worse concurrency. But these ioctls
aren't to be parallel accessible, in anyway, so it should be fine to
serialize there.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit af368027a49a751d6ff4ee9e3f9961f35bb4fede)
Issue: KIONE-3528
Change-Id: I28ca5908bebb9c406ec3e74fa6605e10da4d42ef
|
|
ALSA sequencer code has an open race between the timer setup ioctl and
the close of the client. This was triggered by syzkaller fuzzer, and
a use-after-free was caught there as a result.
This patch papers over it by adding a proper queue->timer_mutex lock
around the timer-related calls in the relevant code path.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 3567eb6af614dac436c4b16a8d426f9faed639b3)
Issue: KIONE-3528
Change-Id: I54954d60085bc3a0bce9c006958cef456d7a7ef2
|
|
This patch addresses multiple problems :
UDP/RAW sendmsg() need to get a stable struct ipv6_txoptions
while socket is not locked : Other threads can change np->opt
concurrently. Dmitry posted a syzkaller
(http://github.com/google/syzkaller) program desmonstrating
use-after-free.
Starting with TCP/DCCP lockless listeners, tcp_v6_syn_recv_sock()
and dccp_v6_request_recv_sock() also need to use RCU protection
to dereference np->opt once (before calling ipv6_dup_options())
This patch adds full RCU protection to np->opt
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 45f6fad84cc305103b28d73482b344d7f5b76f39)
Conflicts:
include/net/ipv6.h
net/dccp/ipv6.c
net/ipv6/af_inet6.c
net/ipv6/inet6_connection_sock.c
net/ipv6/ipv6_sockglue.c
net/ipv6/raw.c
net/ipv6/syncookies.c
net/ipv6/tcp_ipv6.c
net/ipv6/udp.c
Issue: KIONE-3528
Change-Id: Idffaa1517f5ba1b0313443c6e70f6f3b2e74bb62
|
|
Cc: stable@vger.kernel.org # v3.19
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 4de930efc23b92ddf88ce91c405ee645fe6e27ea)
Issue: KIONE-3528
Change-Id: I50f0f9c5721f65a1111e5817aa7cf253ee4ce3f4
|
|
Commit 8520f38099cc ("USB: change hub initialization sleeps to
delayed_work") changed the hub_activate() routine to make part of it
run in a workqueue. However, the commit failed to take a reference to
the usb_hub structure or to lock the hub interface while doing so. As
a result, if a hub is plugged in and quickly unplugged before the work
routine can run, the routine will try to access memory that has been
deallocated. Or, if the hub is unplugged while the routine is
running, the memory may be deallocated while it is in active use.
This patch fixes the problem by taking a reference to the usb_hub at
the start of hub_activate() and releasing it at the end (when the work
is finished), and by locking the hub interface while the work routine
is running. It also adds a check at the start of the routine to see
if the hub has already been disconnected, in which nothing should be
done.
Change-Id: I18e8a5a5fa8f352ca445d47b1a953f87978f0c1e
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Alexandru Cornea <alexandru.cornea@intel.com>
Tested-by: Alexandru Cornea <alexandru.cornea@intel.com>
Fixes: 8520f38099cc ("USB: change hub initialization sleeps to delayed_work")
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
BUG: ANDROID-28447556
Issue: KIONE-3524
Change-Id: I229da259b7265d8d4cc39b56e3b529123a8c6c7b
|
|
drivers/usb/core/hub.c: In function 'hub_activate':
drivers/usb/core/hub.c:1001:25: error: 'hub_release' undeclared (first use in this function)
kref_put(&hub->kref, hub_release);
Change-Id: I94e829a7ac7c53027638b8093883dad02ac353c1
|
|
(cherry pick from commit 179448bfe4cd201e98e728391c6b01b25c849fe8)
This patch adds a max block check for get_data_block_bmap.
Trinity test program will send a block number as parameter into
ioctl_fibmap, which will be used in get_node_path(), when the block
number large than f2fs max blocks, it will trigger kernel bug.
Signed-off-by: Yunlei He <heyunlei@huawei.com>
Signed-off-by: Xue Liu <liuxueliu.liu@huawei.com>
[Jaegeuk Kim: fix missing condition, pointed by Chao Yu]
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Bug: 28271368
Change-Id: Ia5acae04522993d5b60a0bcb5ccc184c66532be8
|
|
ioctl(TIOCGETD) retrieves the line discipline id directly from the
ldisc because the line discipline id (c_line) in termios is untrustworthy;
userspace may have set termios via ioctl(TCSETS*) without actually
changing the line discipline via ioctl(TIOCSETD).
However, directly accessing the current ldisc via tty->ldisc is
unsafe; the ldisc ptr dereferenced may be stale if the line discipline
is changing via ioctl(TIOCSETD) or hangup.
Wait for the line discipline reference (just like read() or write())
to retrieve the "current" line discipline id.
Change-Id: I72eeab3c4b3ff72717e4a22bbb774047b137ac6d
Cc: <stable@vger.kernel.org>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
BUG: ANDROID-27532522
Issue: KIONE-3524
Change-Id: Icd3ea308ecc730de97839007d200b3d49bbcb37a
|
|
In Linus's tree, the iovec code has been reworked massively, but in
older kernels the AIO layer should be checking this before passing the
request on to other layers.
Many thanks to Ben Hawkes of Google Project Zero for pointing out the
issue.
Reported-by: Ben Hawkes <hawkes@google.com>
Acked-by: Benjamin LaHaise <bcrl@kvack.org>
Tested-by: Willy Tarreau <w@1wt.eu>
[backported to 3.10 - willy]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I3a96630128dacafbc364062c6d2c4477d2d6ffe9
|
|
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.
Issue: KIONE-3501
Change-Id: I988802f38acf40c7671fa0978880928b02d29b56
References: https://rhn.redhat.com/errata/RHSA-2016-0103.html
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit feae3ca2e5e1a8f44aa6290255d3d9709985d0b2)
|
|
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.
Issue: KIONE-3500
Change-Id: Iace1180f8a0d7a38369364965fc066418f97c657
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
While disabling of clocks there's been check of g_display_enabled. In
some scenarios this variable may have been unset even though clocks had
been enabled before, causing disabling of the clocks to be impossible.
Add additional flag in order to properly track the clocks being enabled
or disabled.
Issue: KIONE-3436
Change-Id: I68408fc7321536d1d5834048852b9fa52d85b600
|
|
After clearing ram, floor of power consumption goes ~10mA down in active mode.
Issue: KIONE-3436
Change-Id: I2953f7b858e8f38fb946114edb9e1a7b192d4abb
|
|
This reverts commit e44c6a5e5333eb20c7c58fc7f3d8e4f09b64067f.
Issue: KIONE-3436
Change-Id: I6f1797fb533055b4a461e36c6d3e56bee60e2692
|
|
prctl_set_vma_anon_name could attempt to set the name across
two vmas at the same time due to a typo, which might corrupt
the vma list. Fix it to use tmp instead of end to limit
the name setting to a single vma at a time.
Issue: KIONE-3481
Change-Id: Ie32d8ddb0fd547efbeedd6528acdab5ca5b308b4
Reported-by: Jed Davis <jld@mozilla.com>
Signed-off-by: Colin Cross <ccross@android.com>
|
|
These two checks prevent exploitable buffer overflows in two scenarios.
1. Long WPS_ID_DEVICE_NAME in WPS info elements
2. Invalid SSID determined in certain scan results
Issue: KIONE-3482
Bug: 25662233
Change-Id: Ifb2887737aa6218079745f27d59b5f1364b3892e
|
|
Check the datalen field is less than the size of
packet received from the network.
Bug: 25306181
Issue: KIONE-3483
Signed-off-by: Patrick Tjin <pattjin@google.com>
Change-Id: I3b021d88a95bd7d4e6e0d745d2527d73487bcadc
(cherry picked from commit 10b850b7e82873a14068d24dac4fc2080d46ff76)
|
|
(cherry pick from commit 23567fd052a9abb6d67fe8e7a9ccdd9800a540f2)
This fixes CVE-2016-0728.
If a thread is asked to join as a session keyring the keyring that's already
set as its session, we leak a keyring reference.
This can be tested with the following program:
#include <stddef.h>
#include <stdio.h>
#include <sys/types.h>
#include <keyutils.h>
int main(int argc, const char *argv[])
{
int i = 0;
key_serial_t serial;
serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
"leaked-keyring");
if (serial < 0) {
perror("keyctl");
return -1;
}
if (keyctl(KEYCTL_SETPERM, serial,
KEY_POS_ALL | KEY_USR_ALL) < 0) {
perror("keyctl");
return -1;
}
for (i = 0; i < 100; i++) {
serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
"leaked-keyring");
if (serial < 0) {
perror("keyctl");
return -1;
}
}
return 0;
}
If, after the program has run, there something like the following line in
/proc/keys:
3f3d898f I--Q--- 100 perm 3f3f0000 0 0 keyring leaked-keyring: empty
with a usage count of 100 * the number of times the program has been run,
then the kernel is malfunctioning. If leaked-keyring has zero usages or
has been garbage collected, then the problem is fixed.
Issue: KIONE-3484
Reported-by: Yevgeny Pats <yevgeny@perception-point.io>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Acked-by: Prarit Bhargava <prarit@redhat.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Change-Id: I10177a58a7b3178eda95017557edaa7298594d06
|
|
Poison pointer values should be small enough to find a room in
non-mmap'able/hardly-mmap'able space. E.g. on x86 "poison pointer space"
is located starting from 0x0. Given unprivileged users cannot mmap
anything below mmap_min_addr, it should be safe to use poison pointers
lower than mmap_min_addr.
The current poison pointer values of LIST_POISON{1,2} might be too big for
mmap_min_addr values equal or less than 1 MB (common case, e.g. Ubuntu
uses only 0x10000). There is little point to use such a big value given
the "poison pointer space" below 1 MB is not yet exhausted. Changing it
to a smaller value solves the problem for small mmap_min_addr setups.
The values are suggested by Solar Designer:
http://www.openwall.com/lists/oss-security/2015/05/02/6
Issue: KIONE-3485
Change-Id: Id8d8a1b27978ea6e04a477af910d53694805fb8e
Signed-off-by: Vasily Kulikov <segoon@openwall.com>
Cc: Solar Designer <solar@openwall.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
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 f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("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
Issue: KIONE-3486
Bug: 27275324
Change-Id: I459adb9076fcd50ff1f1c557089c4e421b036ec4
References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 85c34d007116f8a8aafb173966a605fb03532f45)
|
|
CPU1 tends to have less load than CPU0 and we would like to prevent this
thread from preempting other threads as much as possible.
Issue: KIONE-3413
Change-Id: I415ee85b6451a8abd72583cbb2f202af2407864e
|
|
Correction was made in the FG code to avoid zero seconds
tapping
Issue: KIONE-3425
BCM Case: CSP-1021166
Change-Id: I692d16f8b18e7d5803db2cab0604faaca54a1e6c
Signed-off-by: Siva Pothireddy <sivapr@mps-clkwork-03.sj.broadcom.com>
|
|
We need to compile our kernel for Usermode Linux in order to run
net_test test suite. We did have some kernel changes in the past that
were not tested on architectures/configurations different than the one
we use. This commit fixes those errors.
Issue: KIONE-3394
Change-Id: I722f0fe6e107d018431097351e5205d158951e34
|
|
As suggested by Julian:
Simply, flowi4_iif must not contain 0, it does not
look logical to ignore all ip rules with specified iif.
because in fib_rule_match() we do:
if (rule->iifindex && (rule->iifindex != fl->flowi_iif))
goto out;
flowi4_iif should be LOOPBACK_IFINDEX by default.
We need to move LOOPBACK_IFINDEX to include/net/flow.h:
1) It is mostly used by flowi_iif
2) Fix the following compile error if we use it in flow.h
by the patches latter:
In file included from include/linux/netfilter.h:277:0,
from include/net/netns/netfilter.h:5,
from include/net/net_namespace.h:21,
from include/linux/netdevice.h:43,
from include/linux/icmpv6.h:12,
from include/linux/ipv6.h:61,
from include/net/ipv6.h:16,
from include/linux/sunrpc/clnt.h:27,
from include/linux/nfs_fs.h:30,
from init/do_mounts.c:32:
include/net/flow.h: In function ‘flowi4_init_output’:
include/net/flow.h:84:32: error: ‘LOOPBACK_IFINDEX’ undeclared (first use in this function)
[Backport of net-next 6a662719c9868b3d6c7d26b3a085f0cd3cc15e64]
Issue: KIONE-3394
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Julian Anastasov <ja@ssi.bg>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
(cherry picked from commit 9c086b4cf266e9ac1afabb86ff9ef54407b344e2)
Change-Id: Ib7a0a08d78c03800488afa1b2c170cb70e34cfd9
|
|
ping_lookup() may return a wrong sock if sk_buff's and sock's protocols
dont' match. For example, sk_buff's protocol is ETH_P_IPV6, but sock's
sk_family is AF_INET, in that case, if sk->sk_bound_dev_if is zero, a wrong
sock will be returned.
the fix is to "continue" the searching, if no matching, return NULL.
[cherry-pick of net 91a0b603469069cdcce4d572b7525ffc9fd352a6]
Bug: 18512516
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Jane Zhou <a17711@motorola.com>
Signed-off-by: Yiwei Zhao <gbjc64@motorola.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Issue: KIONE-3394
Change-Id: I08ee19e7bf38f6b56e4bea52f8eb77a6f8e846fe
|
|
Issue: KIONE-3014
Change-Id: I9353f04259998896bb7f286f293013f66e056491
|
|
Ignore entry with broadcast SSID instead of returning error when setting
up PNO. This entry is useless but there is no reason we should fail
entirely. Google claims PNO works for all other devices even when they
pass broadcast SSID so we shouldn't be different.
Issue: KIONE-3014
Change-Id: I6b009b4ee047568256d8fef0d674f6c749e480cf
|
|
(cherry pick from commit a9ac1262ce80c287562e604f3bb24f232fcb686e)
With Android M, Android environments use a separate execution
domain for 32bit processes.
See:
https://android-review.googlesource.com/#/c/122131/
This results in systems that use kernel modules to see selinux
audit noise like:
type=1400 audit(28.989:15): avc: denied { module_request } for
pid=1622 comm="app_process32" kmod="personality-8"
scontext=u:r:zygote:s0 tcontext=u:r:kernel:s0 tclass=system
While using kernel modules is unadvised, some systems do require
them.
Thus to avoid developers adding sepolicy exceptions to allow for
request_module calls, this patch disables the logic which tries
to call request_module for the 32bit personality (ie:
personality-8), which doesn't actually exist.
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: I32774083340e0f928d0e3bb4295517218e23c66c
|
|
Those dumps are useless when modem isn't used.
Issue: KIONE-3264
Change-Id: I03c94c8f78dbfa267d0a8e3c163199310f7f042e
|
|
and after ivalidating all track IDs.
We also report BTN_TOUCH-UP and palm removal if user space
sets touch to doze mode before palm was actually
removed, since after entring doze mode palm removal will
not be detected by touch FW
Issue: KIONE-3308
Bug=25960206
Change-Id: Ic30c031c82c1a4b2baca8123dad1489b0e277360
Signed-off-by: Aleksej Makarov <aleksej.makarov@sonymobile.com>
|
|
This reverts commit 5b1f3c5019b7e84879285413685919d0a4d55890
and fix increased power consumption in ambient mode.
Issue: KIONE-3273
Issue: KIONE-3310
Change-Id: Iaf89f2e53d9869ae43eade42b66d8d7ceec80b6f
|
|
The period sizes were too large and it affected the
recording timing which caused
android.media.cts.AudioRecordTest#testAudioRecordLocalMono16Bit
android.media.cts.AudioRecordTest#testAudioRecordStereo16Bit
to fail.
Issue: KIONE-3226
Depends-On: Ie98edbffef0519d5831641c7e865395d33567a0e
Change-Id: I48e333d7ebec6c9a595cd13bab3428996f43d7a7
|
|
Changed the PON key T3 action from Reset to shutdown
Change-Id: I1763c3e74dd00b771869e068a4ead685ad683b94
Signed-off-by: Siva Pothireddy <sivapr@mps-clkwork-02.sj.broadcom.com>
|
|
1. For an IPv4 ping socket, ping_check_bind_addr does not check
the family of the socket address that's passed in. Instead,
make it behave like inet_bind, which enforces either that the
address family is AF_INET, or that the family is AF_UNSPEC and
the address is 0.0.0.0.
2. For an IPv6 ping socket, ping_check_bind_addr returns EINVAL
if the socket family is not AF_INET6. Return EAFNOSUPPORT
instead, for consistency with inet6_bind.
3. Make ping_v4_sendmsg and ping_v6_sendmsg return EAFNOSUPPORT
instead of EINVAL if an incorrect socket address structure is
passed in.
4. Make IPv6 ping sockets be IPv6-only. The code does not support
IPv4, and it cannot easily be made to support IPv4 because
the protocol numbers for ICMP and ICMPv6 are different. This
makes connect(::ffff:192.0.2.1) fail with EAFNOSUPPORT instead
of making the socket unusable.
Among other things, this fixes an oops that can be triggered by:
int s = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP);
struct sockaddr_in6 sin6 = {
.sin6_family = AF_INET6,
.sin6_addr = in6addr_any,
};
bind(s, (struct sockaddr *) &sin6, sizeof(sin6));
[backport of net 9145736d4862145684009d6a72a6e61324a9439e]
Issue: KIONE-3227
Change-Id: If06ca86d9f1e4593c0d6df174caca3487c57a241
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Assembler optimizations for AES crypto were not enabled in
kernel config. They significantly reduce CPU load when using
encrypted file system.
Issue: KIONE-3252
Change-Id: I074584eb8fcdf6c5cdfaff60aae21808326dc91e
|
|
[1] When entering NUD_PROBE state via neigh_update(), perhaps received
from userspace, correctly (re)initialize the probes count to zero.
This is useful for forcing revalidation of a neighbor (for example
if the host is attempting to do DNA [IPv4 4436, IPv6 6059]).
[2] Notify listeners when a neighbor goes into NUD_PROBE state.
By sending notifications on entry to NUD_PROBE state listeners get
more timely warnings of imminent connectivity issues.
The current notifications on entry to NUD_STALE have somewhat
limited usefulness: NUD_STALE is a perfectly normal state, as is
NUD_DELAY, whereas notifications on entry to NUD_FAILURE come after
a neighbor reachability problem has been confirmed (typically after
three probes).
Issue: KIONE-3018
Change-Id: I1d01d40ef3bc4753b0eaa79da2b27235425b1934
Signed-off-by: Erik Kline <ek@google.com>
Acked-By: Lorenzo Colitti <lorenzo@google.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This reverts commit e3111a6e71769f26505b9b7d38c62c6288997edd.
Issue: KIONE-2642
Change-Id: Ic87fe2af8a7662dc42ba5af3c232ec2e3d470a10
|
|
Issue: KIONE-2589
Bug=24688136
Change-Id: If15364c3b2691a1446b8996c047891bfc558bfcb
|
|
Only lowmemkiller should have access to them.
Issue: KIONE-3229
Bug=25565105
Change-Id: Ifb20e82095d9dc905338c0ffd0e7ced3ba9c3dc7
|
|
This fixes android.os.cts.SeccompTest#testKernelBasicTests
Issue: KIONE-3225
Bug=25562902
Change-Id: I1f3f5c1314923ffc10b3472950cd2fffc11af0a0
|