Enable kexec-hardboot in cyanogenmod_hammerhead_defconfig #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Change-Id: I9e65ce10feaf30138acce2de8b5ac623c3ec994d
Change-Id: I9e65ce10feaf30138acce2de8b5ac623c3ec994d
Zipsnet
pushed a commit
that referenced
this pull request
Jul 8, 2014
last commit: CyanogenMod/android_kernel_lge_hammerhead@86fd2cf Change-Id: I6fb42b295bb0ee1687407a0496b2dab2601596b7
Zipsnet
pushed a commit
that referenced
this pull request
Jul 12, 2014
This reverts commit 49a7e52. Change-Id: If46b900f41187ea24127653c6405e91b708e2519
Zipsnet
pushed a commit
that referenced
this pull request
Jul 12, 2014
Zipsnet
pushed a commit
that referenced
this pull request
Nov 16, 2014
…ssion() While running stress tests on adding and deleting ftrace instances I hit this bug: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: selinux_inode_permission+0x85/0x160 PGD 63681067 PUD 7ddbe067 PMD 0 Oops: 0000 [#1] PREEMPT CPU: 0 PID: 5634 Comm: ftrace-test-mki Not tainted 3.13.0-rc4-test-00033-gd2a6dde-dirty #20 Hardware name: /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006 task: ffff880078375800 ti: ffff88007ddb0000 task.ti: ffff88007ddb0000 RIP: 0010:[<ffffffff812d8bc5>] [<ffffffff812d8bc5>] selinux_inode_permission+0x85/0x160 RSP: 0018:ffff88007ddb1c48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000800000 RCX: ffff88006dd43840 RDX: 0000000000000001 RSI: 0000000000000081 RDI: ffff88006ee46000 RBP: ffff88007ddb1c88 R08: 0000000000000000 R09: ffff88007ddb1c54 R10: 6e6576652f6f6f66 R11: 0000000000000003 R12: 0000000000000000 R13: 0000000000000081 R14: ffff88006ee46000 R15: 0000000000000000 FS: 00007f217b5b6700(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M CR2: 0000000000000020 CR3: 000000006a0fe000 CR4: 00000000000007f0 Call Trace: security_inode_permission+0x1c/0x30 __inode_permission+0x41/0xa0 inode_permission+0x18/0x50 link_path_walk+0x66/0x920 path_openat+0xa6/0x6c0 do_filp_open+0x43/0xa0 do_sys_open+0x146/0x240 SyS_open+0x1e/0x20 system_call_fastpath+0x16/0x1b Code: 84 a1 00 00 00 81 e3 00 20 00 00 89 d8 83 c8 02 40 f6 c6 04 0f 45 d8 40 f6 c6 08 74 71 80 cf 02 49 8b 46 38 4c 8d 4d cc 45 31 c0 <0f> b7 50 20 8b 70 1c 48 8b 41 70 89 d9 8b 78 04 e8 36 cf ff ff RIP selinux_inode_permission+0x85/0x160 CR2: 0000000000000020 Investigating, I found that the inode->i_security was NULL, and the dereference of it caused the oops. in selinux_inode_permission(): isec = inode->i_security; rc = avc_has_perm_noaudit(sid, isec->sid, isec->sclass, perms, 0, &avd); Note, the crash came from stressing the deletion and reading of debugfs files. I was not able to recreate this via normal files. But I'm not sure they are safe. It may just be that the race window is much harder to hit. What seems to have happened (and what I have traced), is the file is being opened at the same time the file or directory is being deleted. As the dentry and inode locks are not held during the path walk, nor is the inodes ref counts being incremented, there is nothing saving these structures from being discarded except for an rcu_read_lock(). The rcu_read_lock() protects against freeing of the inode, but it does not protect freeing of the inode_security_struct. Now if the freeing of the i_security happens with a call_rcu(), and the i_security field of the inode is not changed (it gets freed as the inode gets freed) then there will be no issue here. (Linus Torvalds suggested not setting the field to NULL such that we do not need to check if it is NULL in the permission check). Note, this is a hack, but it fixes the problem at hand. A real fix is to restructure the destroy_inode() to call all the destructor handlers from the RCU callback. But that is a major job to do, and requires a lot of work. For now, we just band-aid this bug with this fix (it works), and work on a more maintainable solution in the future. Link: http://lkml.kernel.org/r/20140109101932.0508dec7@gandalf.local.home Link: http://lkml.kernel.org/r/20140109182756.17abaaa8@gandalf.local.home Cc: stable@vger.kernel.org Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Zipsnet
pushed a commit
that referenced
this pull request
Nov 16, 2014
Setting an empty security context (length=0) on a file will lead to incorrectly dereferencing the type and other fields of the security context structure, yielding a kernel BUG. As a zero-length security context is never valid, just reject all such security contexts whether coming from userspace via setxattr or coming from the filesystem upon a getxattr request by SELinux. Setting a security context value (empty or otherwise) unknown to SELinux in the first place is only possible for a root process (CAP_MAC_ADMIN), and, if running SELinux in enforcing mode, only if the corresponding SELinux mac_admin permission is also granted to the domain by policy. In Fedora policies, this is only allowed for specific domains such as livecd for setting down security contexts that are not defined in the build host policy. [On Android, this can only be set by root/CAP_MAC_ADMIN processes, and if running SELinux in enforcing mode, only if mac_admin permission is granted in policy. In Android 4.4, this would only be allowed for root/CAP_MAC_ADMIN processes that are also in unconfined domains. In current AOSP master, mac_admin is not allowed for any domains except the recovery console which has a legitimate need for it. The other potential vector is mounting a maliciously crafted filesystem for which SELinux fetches xattrs (e.g. an ext4 filesystem on a SDcard). However, the end result is only a local denial-of-service (DOS) due to kernel BUG. This fix is queued for 3.14.] Reproducer: su setenforce 0 touch foo setfattr -n security.selinux foo Caveat: Relabeling or removing foo after doing the above may not be possible without booting with SELinux disabled. Any subsequent access to foo after doing the above will also trigger the BUG. BUG output from Matthew Thode: [ 473.893141] ------------[ cut here ]------------ [ 473.962110] kernel BUG at security/selinux/ss/services.c:654! [ 473.995314] invalid opcode: 0000 [#6] SMP [ 474.027196] Modules linked in: [ 474.058118] CPU: 0 PID: 8138 Comm: ls Tainted: G D I 3.13.0-grsec #1 [ 474.116637] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0 07/29/10 [ 474.149768] task: ffff8805f50cd010 ti: ffff8805f50cd488 task.ti: ffff8805f50cd488 [ 474.183707] RIP: 0010:[<ffffffff814681c7>] [<ffffffff814681c7>] context_struct_compute_av+0xce/0x308 [ 474.219954] RSP: 0018:ffff8805c0ac3c38 EFLAGS: 00010246 [ 474.252253] RAX: 0000000000000000 RBX: ffff8805c0ac3d94 RCX: 0000000000000100 [ 474.287018] RDX: ffff8805e8aac000 RSI: 00000000ffffffff RDI: ffff8805e8aaa000 [ 474.321199] RBP: ffff8805c0ac3cb8 R08: 0000000000000010 R09: 0000000000000006 [ 474.357446] R10: 0000000000000000 R11: ffff8805c567a000 R12: 0000000000000006 [ 474.419191] R13: ffff8805c2b74e88 R14: 00000000000001da R15: 0000000000000000 [ 474.453816] FS: 00007f2e75220800(0000) GS:ffff88061fc00000(0000) knlGS:0000000000000000 [ 474.489254] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 474.522215] CR2: 00007f2e74716090 CR3: 00000005c085e000 CR4: 00000000000207f0 [ 474.556058] Stack: [ 474.584325] ffff8805c0ac3c98 ffffffff811b549b ffff8805c0ac3c98 ffff8805f1190a40 [ 474.618913] ffff8805a6202f08 ffff8805c2b74e88 00068800d0464990 ffff8805e8aac860 [ 474.653955] ffff8805c0ac3cb8 000700068113833a ffff880606c75060 ffff8805c0ac3d94 [ 474.690461] Call Trace: [ 474.723779] [<ffffffff811b549b>] ? lookup_fast+0x1cd/0x22a [ 474.778049] [<ffffffff81468824>] security_compute_av+0xf4/0x20b [ 474.811398] [<ffffffff8196f419>] avc_compute_av+0x2a/0x179 [ 474.843813] [<ffffffff8145727b>] avc_has_perm+0x45/0xf4 [ 474.875694] [<ffffffff81457d0e>] inode_has_perm+0x2a/0x31 [ 474.907370] [<ffffffff81457e76>] selinux_inode_getattr+0x3c/0x3e [ 474.938726] [<ffffffff81455cf6>] security_inode_getattr+0x1b/0x22 [ 474.970036] [<ffffffff811b057d>] vfs_getattr+0x19/0x2d [ 475.000618] [<ffffffff811b05e5>] vfs_fstatat+0x54/0x91 [ 475.030402] [<ffffffff811b063b>] vfs_lstat+0x19/0x1b [ 475.061097] [<ffffffff811b077e>] SyS_newlstat+0x15/0x30 [ 475.094595] [<ffffffff8113c5c1>] ? __audit_syscall_entry+0xa1/0xc3 [ 475.148405] [<ffffffff8197791e>] system_call_fastpath+0x16/0x1b [ 475.179201] Code: 00 48 85 c0 48 89 45 b8 75 02 0f 0b 48 8b 45 a0 48 8b 3d 45 d0 b6 00 8b 40 08 89 c6 ff ce e8 d1 b0 06 00 48 85 c0 49 89 c7 75 02 <0f> 0b 48 8b 45 b8 4c 8b 28 eb 1e 49 8d 7d 08 be 80 01 00 00 e8 [ 475.255884] RIP [<ffffffff814681c7>] context_struct_compute_av+0xce/0x308 [ 475.296120] RSP <ffff8805c0ac3c38> [ 475.328734] ---[ end trace f076482e9d754adc ]--- [sds: commit message edited to note Android implications and to generate a unique Change-Id for gerrit] Change-Id: I4d5389f0cfa72b5f59dada45081fa47e03805413 Reported-by: Matthew Thode <mthode@mthode.org> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> Cc: stable@vger.kernel.org Signed-off-by: Paul Moore <pmoore@redhat.com>
Zipsnet
pushed a commit
that referenced
this pull request
Nov 16, 2014
ARM has some private syscalls (for example, set_tls(2)) which lie
outside the range of NR_syscalls. If any of these are called while
syscall tracing is being performed, out-of-bounds array access will
occur in the ftrace and perf sys_{enter,exit} handlers.
# trace-cmd record -e raw_syscalls:* true && trace-cmd report
...
true-653 [000] 384.675777: sys_enter: NR 192 (0, 1000, 3, 4000022, ffffffff, 0)
true-653 [000] 384.675812: sys_exit: NR 192 = 1995915264
true-653 [000] 384.675971: sys_enter: NR 983045 (76f74480, 76f74000, 76f74b28, 76f74480, 76f76f74, 1)
true-653 [000] 384.675988: sys_exit: NR 983045 = 0
...
# trace-cmd record -e syscalls:* true
[ 17.289329] Unable to handle kernel paging request at virtual address aaaaaace
[ 17.289590] pgd = 9e71c000
[ 17.289696] [aaaaaace] *pgd=00000000
[ 17.289985] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 17.290169] Modules linked in:
[ 17.290391] CPU: 0 PID: 704 Comm: true Not tainted 3.18.0-rc2+ #21
[ 17.290585] task: 9f4dab00 ti: 9e710000 task.ti: 9e710000
[ 17.290747] PC is at ftrace_syscall_enter+0x48/0x1f8
[ 17.290866] LR is at syscall_trace_enter+0x124/0x184
Fix this by ignoring out-of-NR_syscalls-bounds syscall numbers.
Commit cd0980f "tracing: Check invalid syscall nr while tracing syscalls"
added the check for less than zero, but it should have also checked
for greater than NR_syscalls.
Link: http://lkml.kernel.org/p/1414620418-29472-1-git-send-email-rabin@rab.in
Fixes: cd0980f "tracing: Check invalid syscall nr while tracing syscalls"
Cc: stable@vger.kernel.org # 2.6.33+
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Conflicts:
kernel/trace/trace_syscalls.c
Change-Id: I512142f8f1e1b2a8dc063209666dbce9737377e7
Zipsnet
pushed a commit
that referenced
this pull request
Nov 16, 2014
…ernor For the sync_freq feature currently we check pcpu->policy->cur frequency for each online cpu. But for a CPU that isn't using interactive governor or for an offline CPU, pcpu->policy can be null or an invalid value. This patch tries to avoid that scenario by using pcpu->target_freq instead of policy->cur to get the frequency of an online CPU. Kernel crash without this patch: [ 20.132373] Unable to handle kernel NULL pointer dereference at virtual address 00000028 [ 20.132375] pgd = c34f34c0 [ 20.132377] pgd = ef6f2440 [ 20.132383] [00000028] *pgd=00000000 [ 20.132385] [ 20.132388] [00000028] *pgd=2e98f003, *pmd=00000000 [ 20.132390] Internal error: Oops: 205 [#1] PREEMPT SMP ARM [ 20.132394] Modules linked in: [ 20.132398] CPU: 0 PID: 1560 Comm: chown Tainted: G W 3.10.0-perf-gb12057b-00001-ga2c6c16-dirty #7 [ 20.132401] task: ef9af300 ti: ee49c000 task.ti: ee49c000 [ 20.132411] PC is at cpufreq_interactive_timer+0x10c/0x650 [ 20.132415] LR is at cpufreq_interactive_timer+0x128/0x650 <snip> [ 20.133002] [<c07eb204>] (cpufreq_interactive_timer+0x10c/0x650) from [<c02804d8>] (call_timer_fn+0x80/0x198) [ 20.133012] [<c02804d8>] (call_timer_fn+0x80/0x198) from [<c0280acc>] (run_timer_softirq+0x1f8/0x270) [ 20.133019] [<c0280acc>] (run_timer_softirq+0x1f8/0x270) from [<c0279e20>] (__do_softirq+0x12c/0x2d4) [ 20.133025] [<c0279e20>] (__do_softirq+0x12c/0x2d4) from [<c027a2d4>] (irq_exit+0x74/0xc8) [ 20.133034] [<c027a2d4>] (irq_exit+0x74/0xc8) from [<c0206a00>] (handle_IRQ+0x68/0x8c) [ 20.133041] [<c0206a00>] (handle_IRQ+0x68/0x8c) from [<c02004b8>] (gic_handle_irq+0x3c/0x60) [ 20.133051] [<c02004b8>] (gic_handle_irq+0x3c/0x60) from [<c0ac6900>] (__irq_svc+0x40/0x70) <snip> Change-Id: Ie834f5d383de4d41e0fe6fbd40c8b0a0c05d82f5 Signed-off-by: Vijay Ganti <viganti@codeaurora.org>
LorDClockaN
pushed a commit
that referenced
this pull request
Nov 17, 2014
Below Kernel panic is observed due to race condition, where
sock_has_perm called in a thread and is trying to access sksec->sid
without checking sksec. Just before that, sk->sk_security was set
to NULL by selinux_sk_free_security through sk_free in other thread.
31704.949269: <3> IPv4: Attempt to release alive inet socket dd81b200
31704.959049: <1> Unable to handle kernel NULL pointer dereference at \
virtual address 00000000
31704.983562: <1> pgd = c6b74000
31704.985248: <1> [00000000] *pgd=00000000
31704.996591: <0> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
31705.001016: <6> Modules linked in: adsprpc [last unloaded: wlan]
31705.006659: <6> CPU: 1 Tainted: G O \
(3.4.0-g837ab9b-00003-g6bcd9c6 #1)
31705.014042: <6> PC is at sock_has_perm+0x58/0xd4
31705.018292: <6> LR is at sock_has_perm+0x58/0xd4
31705.022546: <6> pc : [<c0341e8c>] lr : [<c0341e8c>] \
psr: 60000013
31705.022549: <6> sp : dda27f00 ip : 00000000 fp : 5f36fc84
31705.034002: <6> r10: 00004000 r9 : 0000009d r8 : e8c2b700
31705.039211: <6> r7 : dda27f24 r6 : dd81b200 r5 : 00000000 \
r4 : 00000000
31705.045721: <6> r3 : 00000000 r2 : dda27ef8 r1 : 00000000 \
r0 : dda27f54
31705.052232: <6> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM \
Segment user
31705.059349: <6> Control: 10c5787d Table: 10d7406a DAC: 00000015
.
.
.
.
31705.697816: <6> [<c0341e8c>] (sock_has_perm+0x58/0xd4) from \
[<c033ed10>] (security_socket_getsockopt+0x14/0x1c)
31705.707534: <6> [<c033ed10>] (security_socket_getsockopt+0x14/0x1c) \
from [<c0745c18>] (sys_getsockopt+0x34/0xa8)
31705.717343: <6> [<c0745c18>] (sys_getsockopt+0x34/0xa8) from \
[<c0106140>] (ret_fast_syscall+0x0/0x30)
31705.726193: <0> Code: e59832e8 e5933058 e5939004 ebfac736 (e5953000)
31705.732635: <4> ---[ end trace 22889004dafd87bd ]---
Change-Id: I79c3fb525f35ea2494d53788788cd71a38a32d6b
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
Signed-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>
Zipsnet
pushed a commit
that referenced
this pull request
Feb 1, 2015
Below Kernel panic is observed due to race condition, where
sock_has_perm called in a thread and is trying to access sksec->sid
without checking sksec. Just before that, sk->sk_security was set
to NULL by selinux_sk_free_security through sk_free in other thread.
31704.949269: <3> IPv4: Attempt to release alive inet socket dd81b200
31704.959049: <1> Unable to handle kernel NULL pointer dereference at \
virtual address 00000000
31704.983562: <1> pgd = c6b74000
31704.985248: <1> [00000000] *pgd=00000000
31704.996591: <0> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
31705.001016: <6> Modules linked in: adsprpc [last unloaded: wlan]
31705.006659: <6> CPU: 1 Tainted: G O \
(3.4.0-g837ab9b-00003-g6bcd9c6 #1)
31705.014042: <6> PC is at sock_has_perm+0x58/0xd4
31705.018292: <6> LR is at sock_has_perm+0x58/0xd4
31705.022546: <6> pc : [<c0341e8c>] lr : [<c0341e8c>] \
psr: 60000013
31705.022549: <6> sp : dda27f00 ip : 00000000 fp : 5f36fc84
31705.034002: <6> r10: 00004000 r9 : 0000009d r8 : e8c2b700
31705.039211: <6> r7 : dda27f24 r6 : dd81b200 r5 : 00000000 \
r4 : 00000000
31705.045721: <6> r3 : 00000000 r2 : dda27ef8 r1 : 00000000 \
r0 : dda27f54
31705.052232: <6> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM \
Segment user
31705.059349: <6> Control: 10c5787d Table: 10d7406a DAC: 00000015
.
.
.
.
31705.697816: <6> [<c0341e8c>] (sock_has_perm+0x58/0xd4) from \
[<c033ed10>] (security_socket_getsockopt+0x14/0x1c)
31705.707534: <6> [<c033ed10>] (security_socket_getsockopt+0x14/0x1c) \
from [<c0745c18>] (sys_getsockopt+0x34/0xa8)
31705.717343: <6> [<c0745c18>] (sys_getsockopt+0x34/0xa8) from \
[<c0106140>] (ret_fast_syscall+0x0/0x30)
31705.726193: <0> Code: e59832e8 e5933058 e5939004 ebfac736 (e5953000)
31705.732635: <4> ---[ end trace 22889004dafd87bd ]---
Change-Id: I79c3fb525f35ea2494d53788788cd71a38a32d6b
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
Signed-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>
AICP-Gerrit
pushed a commit
that referenced
this pull request
Oct 30, 2016
There are a couple of seq_files which use the single_open() interface. This interface requires that the whole output must fit into a single buffer. E.g. for /proc/stat allocation failures have been observed because an order-4 memory allocation failed due to memory fragmentation. In such situations reading /proc/stat is not possible anymore. Therefore change the seq_file code to fallback to vmalloc allocations which will usually result in a couple of order-0 allocations and hence also work if memory is fragmented. For reference a call trace where reading from /proc/stat failed: sadc: page allocation failure: order:4, mode:0x1040d0 CPU: 1 PID: 192063 Comm: sadc Not tainted 3.10.0-123.el7.s390x #1 [...] Call Trace: show_stack+0x6c/0xe8 warn_alloc_failed+0xd6/0x138 __alloc_pages_nodemask+0x9da/0xb68 __get_free_pages+0x2e/0x58 kmalloc_order_trace+0x44/0xc0 stat_open+0x5a/0xd8 proc_reg_open+0x8a/0x140 do_dentry_open+0x1bc/0x2c8 finish_open+0x46/0x60 do_last+0x382/0x10d0 path_openat+0xc8/0x4f8 do_filp_open+0x46/0xa8 do_sys_open+0x114/0x1f0 sysc_tracego+0x14/0x1a Conflicts: fs/seq_file.c Bug: 17871993 Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Tested-by: David Rientjes <rientjes@google.com> Cc: Ian Kent <raven@themaw.net> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Cc: Thorsten Diehl <thorsten.diehl@de.ibm.com> Cc: Andrea Righi <andrea@betterlinux.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Stefan Bader <stefan.bader@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Git-commit: 058504edd02667eef8fac9be27ab3ea74332e9b4 Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Change-Id: Iad795a92fee1983c300568429a6283c48625bd9a Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org> Signed-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Change-Id: I9e65ce10feaf30138acce2de8b5ac623c3ec994d