[tip:x86/urgent] x86-64: Clear a 64-bit FS/GS base on fork if selector is nonzero
in [Kernel]
|
Prev: x86/PCI: never allocate PCI MMIO resources below BIOS_END
Next: [tip:x86/urgent] x86-64: Clear a 64-bit FS/GS base on fork if selector is nonzero
From: tip-bot for H. Peter Anvin on 23 Apr 2010 19:50 Commit-ID: 3e72c448927da6117007d402637b4dbd6b55998d Gitweb: http://git.kernel.org/tip/3e72c448927da6117007d402637b4dbd6b55998d Author: H. Peter Anvin <hpa(a)zytor.com> AuthorDate: Fri, 23 Apr 2010 16:17:40 -0700 Committer: H. Peter Anvin <hpa(a)zytor.com> CommitDate: Fri, 23 Apr 2010 16:36:09 -0700 x86-64: Clear a 64-bit FS/GS base on fork if selector is nonzero When we do a thread switch, we clear the outgoing FS/GS base if the corresponding selector is nonzero. This is taken by __switch_to() as an entry invariant; it does not verify that it is true on entry. However, copy_thread() doesn't enforce this constraint, which can result in inconsistent results after fork(). Make copy_thread() match the behavior of __switch_to(). Reported-and-tested-by: Samuel Thibault <samuel.thibault(a)inria.fr> Signed-off-by: H. Peter Anvin <hpa(a)zytor.com> LKML-Reference: <4BD1E061.8030605(a)zytor.com> --- arch/x86/kernel/process_64.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index dc9690b..17cb329 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -276,12 +276,12 @@ int copy_thread(unsigned long clone_flags, unsigned long sp, set_tsk_thread_flag(p, TIF_FORK); - p->thread.fs = me->thread.fs; - p->thread.gs = me->thread.gs; p->thread.io_bitmap_ptr = NULL; savesegment(gs, p->thread.gsindex); + p->thread.gs = p->thread.gsindex ? 0 : me->thread.gs; savesegment(fs, p->thread.fsindex); + p->thread.fs = p->thread.fsindex ? 0 : me->thread.fs; savesegment(es, p->thread.es); savesegment(ds, p->thread.ds); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |