diff options
author | Alexey Kuznetsov <alexey@openvz.org> | 2007-05-08 00:31:57 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-05-08 11:15:15 -0700 |
commit | b140f25108a8b11aa4903014814988549838b324 (patch) | |
tree | 466b0c1a8056a2307c8219d1dfc5c059c043f07d /kernel | |
parent | ce0be1273d1473a5a7b57bf0b4995b40c22d6b54 (diff) | |
download | linux-b140f25108a8b11aa4903014814988549838b324.tar.gz linux-b140f25108a8b11aa4903014814988549838b324.tar.bz2 linux-b140f25108a8b11aa4903014814988549838b324.zip |
Invalid return value of execve() resulting in oopses
When elf loader fails to map executable (due to memory shortage or because
binary is malformed), it can return 0. Normally, this is invisible because
process is killed with SIGKILL and it never returns to user space.
But if exec() is called from kernel thread (hotplug, whatever)
consequences are more interesting and vary depending on architecture.
i386. Nothing especially interesting, execve() just returns
with "success" :-)
x86_64. Fake zero frame is used on way to caller, RSP/RIP are loaded
with zeros, ergo... double fault.
ia64. Similar to i386, but r32...r95 are corrupted. Sometimes it
oopses due to return to zero PC, sometimes it sees NaT in
rXX and oopses due to NaT consumption.
Signed-off-by: Alexey Kuznetsov <alexey@openvz.org>
Signed-off-by: Kirill Korotaev <dev@openvz.org>
Signed-off-by: Pavel Emelianov <xemul@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions