This is a note to let you know that I've just added the patch titled
x86-64, modify_ldt: Make support for 16-bit segments a runtime option
to the 3.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86-64-modify_ldt-make-support-for-16-bit-segments-a-runtime-option.patch
and it can be found in the queue-3.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From fa81511bb0bbb2b1aace3695ce869da9762624ff Mon Sep 17 00:00:00 2001
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Wed, 14 May 2014 16:33:54 -0700
Subject: x86-64, modify_ldt: Make support for 16-bit segments a runtime option
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
commit fa81511bb0bbb2b1aace3695ce869da9762624ff upstream.
Checkin:
b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
disabled 16-bit segments on 64-bit kernels due to an information
leak. However, it does seem that people are genuinely using Wine to
run old 16-bit Windows programs on Linux.
A proper fix for this ("espfix64") is coming in the upcoming merge
window, but as a temporary fix, create a sysctl to allow the
administrator to re-enable support for 16-bit segments.
It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
you hit this issue and care about your old Windows program more than
you care about a kernel stack address information leak, you can do
echo 1 > /proc/sys/abi/ldt16
as root (add it to your startup scripts), and you should be ok.
The sysctl table is only added if you have COMPAT support enabled on
x86-64, but I assume anybody who runs old windows binaries very much
does that ;)
Signed-off-by: H. Peter Anvin <hpa@xxxxxxxxxxxxxxx>
Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@xxxxxxxxxxxxxx
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
arch/x86/kernel/ldt.c | 4 +++-
arch/x86/vdso/vdso32-setup.c | 8 ++++++++
2 files changed, 11 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -20,6 +20,8 @@
#include <asm/mmu_context.h>
#include <asm/syscalls.h>
+int sysctl_ldt16 = 0;
+
#ifdef CONFIG_SMP
static void flush_ldt(void *current_mm)
{
@@ -234,7 +236,7 @@ static int write_ldt(void __user *ptr, u
* IRET leaking the high bits of the kernel stack address.
*/
#ifdef CONFIG_X86_64
- if (!ldt_info.seg_32bit) {
+ if (!ldt_info.seg_32bit && !sysctl_ldt16) {
error = -EINVAL;
goto out_unlock;
}
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -41,6 +41,7 @@ enum {
#ifdef CONFIG_X86_64
#define vdso_enabled sysctl_vsyscall32
#define arch_setup_additional_pages syscall32_setup_pages
+extern int sysctl_ldt16;
#endif
/*
@@ -379,6 +380,13 @@ static ctl_table abi_table2[] = {
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec
+ },
+ {
+ .procname = "ldt16",
+ .data = &sysctl_ldt16,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
},
{}
};
Patches currently in stable-queue which might be from torvalds@xxxxxxxxxxxxxxxxxxxx are
queue-3.4/futex-add-another-early-deadlock-detection-check.patch
queue-3.4/futex-prevent-attaching-to-kernel-threads.patch
queue-3.4/mm-hugetlb.c-add-cond_resched_lock-in-return_unused_surplus_pages.patch
queue-3.4/hwpoison-hugetlb-lock_page-unlock_page-does-not-match-for-handling-a-free-hugepage.patch
queue-3.4/x86-64-modify_ldt-make-support-for-16-bit-segments-a-runtime-option.patch
queue-3.4/list-introduce-list_next_entry-and-list_prev_entry.patch
queue-3.4/ipmi-fix-a-race-restarting-the-timer.patch
queue-3.4/ipmi-reset-the-kcs-timeout-when-starting-error-recovery.patch
queue-3.4/mm-make-fixup_user_fault-check-the-vma-access-rights-too.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html