lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 19 Oct 2013 21:04:57 -0700 From: ebiederm@...ssion.com (Eric W. Biederman) To: Fengguang Wu <fengguang.wu@...el.com> Cc: linux-kernel@...r.kernel.org Subject: Re: [userns-always-map-user-v136] BUG: unable to handle kernel NULL pointer dereference at (null) Fengguang Wu <fengguang.wu@...el.com> writes: > Hi Eric, > > It's beyond me why this trivial patch will lead to kernel panic. But > the NULL pointer dereference bug is 100% reproducible since this > commit. My mistake apparently I failed to boot test that patch. The problem crash is because kthreadd_task == NULL. kthreadd_task is NULL because this little sequence sets kthreadd_task to NULL pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES); rcu_read_lock(); kthreadd_task = find_task_by_pid_ns(pid, &init_pid_ns); rcu_read_unlock(); The lookup for kthreadd_task fails because when spawning kthread_task with kernel_thread the is_idle_task(p) test in fork is reporting true, so the pid is never placed into the pid hash table. is_idle_task(p) is true because it is testing task_pid(p) two lines before task_pid(p) is set. So task_pid(p) is still it's parents value and the parent of the kthreadd_task is the initial idle task. So I should have just tested (pid != &init_struct_pid) sigh. Silly me. Fixed and pushed out. That you for reporting this to me. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists