From Jan5: find below a 4:4 fix against the latest rhel4 tree. it is a security fixpatch that we had for taroon but it didnt get merged into the 2.6 version of the 4:4 patch. Without this fix, syscalls can be used to copy into kernel-space ... a must-have fix. I have tried to camouflage the security fix a bit by calling it a PROT_NONE fix and using pte_read(), not pte_user() (these are the same on x86). Albeit there's no formal embargo on it, please consider it embargoed until the fix gets out. Note that there is no risk to 3:1 because only the 4:4 code uses follow_page_pte() [*]. i've tested it on x86 (the only platform affected) ontop of the latest rhel4 kernel, and it builds/boots fine and the syscall exploit doesnt work anymore. Ingo [*] the taroon fix caused problems for ptrace, because the taroon fix touched follow_page(), which is used by other (and 3:1) code too. This patch only touches follow_page_pte(), which is a limited, 4:4-only function only used by usercopy.c. --- linux/mm/memory.c.orig +++ linux/mm/memory.c @@ -711,7 +711,7 @@ follow_page_pte(struct mm_struct *mm, un pte = *ptep; pte_unmap(ptep); - if (pte_present(pte)) { + if (pte_present(pte) && pte_read(pte)) { /* handle PROT_NONE too */ if (write && !pte_write(pte)) goto out; if (write && !pte_dirty(pte)) {
this is another 4:4 fix against the latest rhel4 tree. it is a fix for a probably DoS-able x86 corner-case segmentation scenario that 4:4 doesnt take into account: when we return to userspace and fault on the way back (on weird segments) then the exception handler routine has to be within a special 'marked', or else we stay in kernel mode (and crash). In theory this could also be exploited. i've tested it on x86 (the only platform affected) ontop of the latest rhel4 kernel, and it builds/boots fine and the syscall exploit doesnt work anymore. i have tested the 3:1 split too. Furtermore i have the checked the disassembly of the kernel image pre-patch vs. post-patch, to make sure that the patch has no effect on 3:1. (it has no effect since the __RESTORE_ALL_USER macro is only used by the 4:4 code.) Ingo --- linux/arch/i386/kernel/entry.S.orig +++ linux/arch/i386/kernel/entry.S @@ -167,7 +167,7 @@ int80_ret_start_marker: \ movl %edx, %esp; \ movl %ecx, %cr3; \ \ - __RESTORE_ALL; \ + __RESTORE_ALL_USER; \ int80_ret_end_marker: \ 2: @@ -204,14 +204,19 @@ int80_ret_end_marker: \ #define __RESTORE_REGS \ __RESTORE_INT_REGS; \ + popl %ds; \ + popl %es; + +#define __RESTORE_REGS_USER \ + __RESTORE_INT_REGS; \ 111: popl %ds; \ 222: popl %es; \ -.section .fixup,"ax"; \ + jmp 666f; \ 444: movl $0,(%esp); \ jmp 111b; \ 555: movl $0,(%esp); \ jmp 222b; \ -.previous; \ +666: \ .section __ex_table,"a";\ .align 4; \ .long 111b,444b;\ @@ -220,6 +225,13 @@ int80_ret_end_marker: \ #define __RESTORE_ALL \ __RESTORE_REGS \ + __RESTORE_IRET + +#define __RESTORE_ALL_USER \ + __RESTORE_REGS_USER \ + __RESTORE_IRET + +#define __RESTORE_IRET \ addl $4, %esp; \ 333: iret; \ .section .fixup,"ax"; \
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-092.html