Thanks for the info & link. I have similar proposal for the issue. I'm still trying to find the root cause for the issue.
Thanks & Regards, Satya Employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by Linux Foundation -----Original Message----- From: Stephen Smalley [mailto:stephen.smal...@gmail.com] Sent: Thursday, October 03, 2013 7:42 AM To: Satya Durga Srinivasu Prabhala Cc: seandroid-list@tycho.nsa.gov Subject: Re: Observing multiple issues after enabling SELinux on JB_MR2 release While I believe that this reflects an underlying bug in your network stack and not SELinux, it does appear that Samsung did encounter something similar and added the following to security/selinux/hooks.c:sock_has_perm() in their kernel: if (unlikely(!sksec)){ printk(KERN_CRIT "[SELinux] sksec is NULL, socket is already freed. \n"); return -EINVAL; } You can see it in their trees, available from opensource.samsung.com or from CyanogenMod trees like: https://github.com/CyanogenMod/android_kernel_samsung_jf/blob/cm-10.2/securi ty/selinux/hooks.c But note that this is just papering over the underlying bug; you are still freeing the socket while it is still in use and thus you may still encounter crashes elsewhere. On Wed, Oct 2, 2013 at 2:56 PM, Satya Durga Srinivasu Prabhala <sat...@codeaurora.org> wrote: > > Hi, > > We are observing multiple issues after enabling SELinux on Android > JB_MR2 release with 3.4 Kernel on different SOCs. Are there any known > issue/s and needs to pull some changes from upstream Kernel? > Can you please advise on how to get these addressed? > > Issue 1: Kernel panic due to NULL pointer dereference > > <3>[ 130.940912] Attempt to release alive inet socket dc030000 > <1>[ 131.050907] Unable to handle kernel NULL pointer dereference > at virtual address 00000000 > <1>[ 131.050969] >>> l2esr = 0x0 > <1>[ 131.050999] >>> l2esynr0 = 0x8112 > <1>[ 131.051030] >>> l2esynr1 = 0x235084 > <1>[ 131.051060] >>> l2ear0 = 0x50412204 > <1>[ 131.051091] >>> l2ear1 = 0x3 > <1>[ 131.051121] pgd = e0850000 > <1>[ 131.051121] [00000000] *pgd=00000000 > <0>[ 131.051182] [0:IntentService[M: 4416] Internal error: Oops: > 5 [#1] PREEMPT SMP > <4>[ 131.051243] [0:IntentService[M: 4416] Modules linked in: dhd > vpnclient > <4>[ 131.051304] [0:IntentService[M: 4416] CPU: 0 Tainted: G > W (3.0.31-1726116 #1) > <4>[ 131.051396] [0:IntentService[M: 4416] PC is at > sock_has_perm+0x38/0xac > <4>[ 131.051426] [0:IntentService[M: 4416] LR is at > sock_has_perm+0x38/0xac > <4>[ 131.051487] [0:IntentService[M: 4416] pc : [<c0330998>] lr : > [<c0330998>] psr: 60000013 > <4>[ 131.051548] [0:IntentService[M: 4416] sp : dac55ef0 ip : > 00000002 fp : 5e75cc84 > <4>[ 131.051609] [0:IntentService[M: 4416] r10: 00000000 r9 : > dac54000 > r8 : 00000115 > <4>[ 131.051670] [0:IntentService[M: 4416] r7 : 00004000 r6 : > dffda080 > r5 : dc030000 r4 : 00000000 > <4>[ 131.051732] [0:IntentService[M: 4416] r3 : 00000000 r2 : > dac55ee8 > r1 : dc030000 r0 : dffda080 > <4>[ 131.051793] [0:IntentService[M: 4416] Flags: nZCv IRQs on > FIQs on Mode SVC_32 ISA ARM Segment user > <4>[ 131.051854] [0:IntentService[M: 4416] Control: 10c5787d Table: > a7b5006a DAC: 00000015 > . > . > <4>[ 131.061040] [0:IntentService[M: 4416] [<c0330998>] > (sock_has_perm+0x38/0xac) from [<c032d148>] > (security_socket_getsockopt+0x14/0x1c) > <4>[ 131.061162] [0:IntentService[M: 4416] [<c032d148>] > (security_socket_getsockopt+0x14/0x1c) from [<c061abe0>] > (sys_getsockopt+0x34/0xa8) > <4>[ 131.061254] [0:IntentService[M: 4416] [<c061abe0>] > (sys_getsockopt+0x34/0xa8) from [<c0105a40>] (ret_fast_syscall+0x0/0x30) > <0>[ 131.061345] [0:IntentService[M: 4416] Code: e59631f0 > e5933058 > e5938004 ebf9ee24 (e5943000) > <4>[ 131.521501] [1:IntentService[M: 4416] ---[ end trace > da227214a82491bb ]--- > <0>[ 131.521562] [1:IntentService[M: 4416] Kernel panic - not syncing: > Fatal exception > > This seem to be 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. > > Issue 2: Kernel panic due to memory scribbling > > 15.530394: <7> SELinux: initialized (dev fuse, type fuse), uses > genfs_contexts > 15.622083: <6> alarm_set_rtc: Failed to set RTC, time will be lost on > reboot > 16.177727: <3> pagealloc: single bit error > 16.180582: <3> ec55402e: 5d > ] > 16.187528: <6> [<c010c09c>] (unwind_backtrace+0x0/0x11c) from > [<c024a030>] (kernel_map_pages+0xfc/0x17c) > 16.187622: <6> [<c024a030>] (kernel_map_pages+0xfc/0x17c) from > [<c021e210>] (get_page_from_freelist+0x404/0x4c8) > 16.188024: <6> [<c021e210>] (get_page_from_freelist+0x404/0x4c8) from > [<c021ee84>] (__alloc_pages_nodemask+0x208/0x8f4) > 16.188106: <6> [<c021ee84>] (__alloc_pages_nodemask+0x208/0x8f4) from > [<c0222238>] (__do_page_cache_readahead+0xd8/0x1f0) > 16.188237: <6> [<c0222238>] (__do_page_cache_readahead+0xd8/0x1f0) > from [<c0222574>] (ra_submit+0x20/0x24) > 16.188400: <6> [<c0222574>] (ra_submit+0x20/0x24) from [<c0222848>] > (page_cache_sync_readahead+0x58/0x60) > 16.188497: <6> [<c0222848>] (page_cache_sync_readahead+0x58/0x60) from > [<c02cbcd0>] (ext4_readdir+0x650/0x670) > 16.188585: <6> [<c02cbcd0>] (ext4_readdir+0x650/0x670) from > [<c0263580>] (vfs_readdir+0x7c/0xb0) > 16.188704: <6> [<c0263580>] (vfs_readdir+0x7c/0xb0) from [<c02636d0>] > (sys_getdents64+0x58/0xb8) > 16.188801: <6> [<c02636d0>] (sys_getdents64+0x58/0xb8) from > [<c0106140>] (ret_fast_syscall+0x0/0x30) > > This issue is observed just after SELinux initialization done for the fuse. > > Issue 3: Kernel panic due to stack corruption > > 10047.154074: <1> Unable to handle kernel paging request at virtual > address c0a4bc44 > 10047.160300: <1> pgd = d9d44000 > 10047.162991: <1> [c0a4bc44] *pgd=00a1941e(bad) > 10047.166994: <0> Internal error: Oops: 8000000d [#1] PREEMPT SMP ARM > 10047.172884: <6> Modules linked in: adsprpc > 10047.176625: <6> CPU: 0 Not tainted (3.4.0-g67fed0b-00018-g19ea2b0 > #1) > 10047.183056: <6> PC is at iw_priv_type_size+0xb22e4/0x283a88 > 10047.188262: <6> LR is at security_file_permission+0x94/0x9c > 10047.193472: <6> pc : [<c0a4bc44>] lr : [<c0335ba4>] psr: 60000013 > 10047.193491: <6> sp : e97cbf20 ip : 00000000 fp : 00001400 > 10047.204921: <6> r10: ea6be780 r9 : e97ca000 r8 : 00001400 > 10047.210130: <6> r7 : e97cbf88 r6 : b8bbd4f0 r5 : 00000000 r4 : > 00000000 > 10047.216638: <6> r3 : 00000000 r2 : 00000000 r1 : 00020000 r0 : > 00000000 > 10047.223153: <6> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM > Segment user > 10047.230271: <6> Control: 10c5387d Table: 1dd4406a DAC: 00000015 > . > . > 11285.714555: <4> ---[ end trace 508eef886fcd4369 ]--- > 11285.719840: <0> Kernel panic - not syncing: Fatal exception > > security_file_permission seem be called and when returned stack is > being corrupted. > > > > Thanks & Regards, > Satya > > Employee of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora > Forum, hosted by Linux Foundation > > > -- > This message was distributed to subscribers of the seandroid-list mailing list. > If you no longer wish to subscribe, send mail to > majord...@tycho.nsa.gov with the words "unsubscribe seandroid-list" without quotes as the message. -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to majord...@tycho.nsa.gov with the words "unsubscribe seandroid-list" without quotes as the message.
