Comment 3 for bug 562343

The interesting parts of the log are:

[ 26.668640] Kernel panic - not syncing: Attempted to kill init!
[ 26.674804] [<c0039664>] (unwind_backtrace+0x0/0xe8) from [<c0422b24>] (panic+0x44/0x120)
[ 26.683166] [<c0422b24>] (panic+0x44/0x120) from [<c00633b0>] (forget_original_parent+0x27c/0x294)
[ 26.692230] [<c00633b0>] (forget_original_parent+0x27c/0x294) from [<c00633dc>] (exit_notify+0x14/0x158)
[ 26.701812] [<c00633dc>] (exit_notify+0x14/0x158) from [<c006366c>] (do_exit+0x14c/0x2f8)
[ 26.710083] [<c006366c>] (do_exit+0x14c/0x2f8) from [<c0063854>] (do_group_exit+0x3c/0xac)
[ 26.718414] [<c0063854>] (do_group_exit+0x3c/0xac) from [<c00638d4>] (sys_exit_group+0x10/0x18)
[ 26.727203] [<c00638d4>] (sys_exit_group+0x10/0x18) from [<c0032a00>] (ret_fast_syscall+0x0/0x2c)

Tracing through forget_original_parent, we call find_new_reaper() which eventually calls panic() as we see above.

 if (unlikely(pid_ns->child_reaper == father)) {
  write_unlock_irq(&tasklist_lock);
  if (unlikely(pid_ns == &init_pid_ns))
   panic("Attempted to kill init!");

  zap_pid_ns_processes(pid_ns);
  write_lock_irq(&tasklist_lock);
  /*
   * We can not clear ->child_reaper or leave it alone.
   * There may by stealth EXIT_DEAD tasks on ->children,
   * forget_original_parent() must move them somewhere.
   */
  pid_ns->child_reaper = init_pid_ns.child_reaper;
 }

So the suspicion is that /sbin/init exits.