Bug 144658 - CAN-2005-0091 4g4g PROT_NONE fix (CAN-2005-0092)
CAN-2005-0091 4g4g PROT_NONE fix (CAN-2005-0092)
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ingo Molnar
Brian Brock
:
Depends On:
Blocks: 144195
  Show dependency treegraph
 
Reported: 2005-01-10 08:58 EST by Tim Burke
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-18 12:21:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Burke 2005-01-10 08:58:42 EST
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)) {
Comment 1 Tim Burke 2005-01-10 09:14:52 EST
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";   \
Comment 2 Josh Bressers 2005-02-18 12:21:06 EST
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

Note You need to log in before you can comment on or make changes to this bug.