From b339a18b81a1f6ca1455559594f5df872b9e59f4 Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Fri, 22 Jul 2005 15:23:47 -0400 Subject: Fix up incorrect "unlikely()" on %gs reload in x86 __switch_to These days %gs is normally the TLS segment, so it's no longer zero. As a result, we shouldn't just assume that %fs/%gs tend to be zero together, but test them independently instead. Also, fix setting of debug registers to use the "next" pointer instead of "current". It so happens that the scheduler will have set the new current pointer before calling __switch_to(), but that's just an implementation detail. --- arch/i386/kernel/process.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) (limited to 'arch/i386/kernel/process.c') diff --git a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c index ba243a4cc119..d9492058aaf3 100644 --- a/arch/i386/kernel/process.c +++ b/arch/i386/kernel/process.c @@ -700,23 +700,27 @@ struct task_struct fastcall * __switch_to(struct task_struct *prev_p, struct tas /* * Restore %fs and %gs if needed. + * + * Glibc normally makes %fs be zero, and %gs is one of + * the TLS segments. */ - if (unlikely(prev->fs | prev->gs | next->fs | next->gs)) { + if (unlikely(prev->fs | next->fs)) loadsegment(fs, next->fs); + + if (prev->gs | next->gs) loadsegment(gs, next->gs); - } /* * Now maybe reload the debug registers */ if (unlikely(next->debugreg[7])) { - set_debugreg(current->thread.debugreg[0], 0); - set_debugreg(current->thread.debugreg[1], 1); - set_debugreg(current->thread.debugreg[2], 2); - set_debugreg(current->thread.debugreg[3], 3); + set_debugreg(next->debugreg[0], 0); + set_debugreg(next->debugreg[1], 1); + set_debugreg(next->debugreg[2], 2); + set_debugreg(next->debugreg[3], 3); /* no 4 and 5 */ - set_debugreg(current->thread.debugreg[6], 6); - set_debugreg(current->thread.debugreg[7], 7); + set_debugreg(next->debugreg[6], 6); + set_debugreg(next->debugreg[7], 7); } if (unlikely(prev->io_bitmap_ptr || next->io_bitmap_ptr)) -- cgit v1.2.3-59-g8ed1b From 71ae18ec690953e9ba7107c7cc44589c2cc0d9f1 Mon Sep 17 00:00:00 2001 From: Blaisorblade Date: Wed, 27 Jul 2005 11:45:18 -0700 Subject: [PATCH] sys_get_thread_area does not clear the returned argument sys_get_thread_area does not memset to 0 its struct user_desc info before copying it to user space... since sizeof(struct user_desc) is 16 while the actual datas which are filled are only 12 bytes + 9 bits (across the bitfields), there is a (small) information leak. Signed-off-by: Paolo 'Blaisorblade' Giarrusso Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- arch/i386/kernel/process.c | 2 ++ 1 file changed, 2 insertions(+) (limited to 'arch/i386/kernel/process.c') diff --git a/arch/i386/kernel/process.c b/arch/i386/kernel/process.c index d9492058aaf3..e3f362e8af5b 100644 --- a/arch/i386/kernel/process.c +++ b/arch/i386/kernel/process.c @@ -917,6 +917,8 @@ asmlinkage int sys_get_thread_area(struct user_desc __user *u_info) if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX) return -EINVAL; + memset(&info, 0, sizeof(info)); + desc = current->thread.tls_array + idx - GDT_ENTRY_TLS_MIN; info.entry_number = idx; -- cgit v1.2.3-59-g8ed1b