On Thu, Dec 11, 2014 at 12:08 PM, Stephen Smalley <[email protected]> wrote: > On 12/11/2014 02:41 PM, Nick Kralevich wrote: >> Has anyone seen this kernel panic before? Known issue? I don't have >> repo steps... > > I have not. Any other dmesg output from the binder driver prior to this > crash? Only way I can see that this could happen would be if one or the > other task arguments to selinux_binder_transaction() were NULL, which > would be a bug in the caller (i.e. the binder driver). The binder > driver calls the hook with proc->tsk and target_proc->tsk, and has just > checked that target_proc is non-NULL (but not necessarily > target_proc->tsk). The proc->tsk field is set upon binder_open(), and a > put_task_struct() of it occurs in binder_deferred_release() just prior > to kfree of the proc itself, so the lifecycle seems to be the same. I'd > ask the binder driver maintainer(s) if NULL proc->tsk or > target_proc->tsk is ever possible there; I don't see how it would > happen. If the specific kernel branch/tag is public and can be > identified, that might help.
according to the binder driver maintainer, target_proc->tsk should never be null. He suspects kernel memory corruption is causing this... -- Nick Kralevich | Android Security | [email protected] | 650.214.4037 _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
