arch/ia64/include/asm/compat.h    |    2 +-
 arch/mips/include/asm/compat.h    |    2 +-
 arch/parisc/include/asm/compat.h  |    2 +-
 arch/powerpc/include/asm/compat.h |    2 +-
 arch/s390/include/asm/compat.h    |    2 +-
 arch/sparc/include/asm/compat.h   |    2 +-
 arch/x86/ia32/ia32entry.S         |    8 +++++++-
 arch/x86/include/asm/compat.h     |    2 +-
 debian/changelog                  |   12 ++++++++++++
 include/linux/compat.h            |    2 ++
 kernel/compat.c                   |   22 ++++++++++++++++++++++
 11 files changed, 50 insertions(+), 8 deletions(-)

New commits:
commit bacb67b5b9bd1172562f501a6837617c838179ce
Author: Stephen Hemminger <[email protected]>
Date:   Thu Sep 23 12:12:48 2010 -0700

    2.6.32-1+vyatta+42+larkspur11

commit a9c413b65f0584183517b6d491da1a4024eafcad
Author: H. Peter Anvin <[email protected]>
Date:   Tue Sep 7 16:16:18 2010 -0700

    compat: Make compat_alloc_user_space() incorporate the access_ok()
    
    commit c41d68a513c71e35a14f66d71782d27a79a81ea6 upstream.
    
    compat_alloc_user_space() expects the caller to independently call
    access_ok() to verify the returned area.  A missing call could
    introduce problems on some architectures.
    
    This patch incorporates the access_ok() check into
    compat_alloc_user_space() and also adds a sanity check on the length.
    The existing compat_alloc_user_space() implementations are renamed
    arch_compat_alloc_user_space() and are used as part of the
    implementation of the new global function.
    
    This patch assumes NULL will cause __get_user()/__put_user() to either
    fail or access userspace on all architectures.  This should be
    followed by checking the return value of compat_access_user_space()
    for NULL in the callers, at which time the access_ok() in the callers
    can also be removed.
    
    Reported-by: Ben Hawkes <[email protected]>
    Signed-off-by: H. Peter Anvin <[email protected]>
    Acked-by: Benjamin Herrenschmidt <[email protected]>
    Acked-by: Chris Metcalf <[email protected]>
    Acked-by: David S. Miller <[email protected]>
    Acked-by: Ingo Molnar <[email protected]>
    Acked-by: Thomas Gleixner <[email protected]>
    Acked-by: Tony Luck <[email protected]>
    Cc: Andrew Morton <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Fenghua Yu <[email protected]>
    Cc: H. Peter Anvin <[email protected]>
    Cc: Heiko Carstens <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: James Bottomley <[email protected]>
    Cc: Kyle McMartin <[email protected]>
    Cc: Martin Schwidefsky <[email protected]>
    Cc: Paul Mackerras <[email protected]>
    Cc: Ralf Baechle <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit be199cdcf850f0509c88fbd3fd2595ed9593f6aa
Author: Roland McGrath <[email protected]>
Date:   Tue Sep 14 12:22:58 2010 -0700

    x86-64, compat: Retruncate rax after ia32 syscall entry tracing
    
    commit eefdca043e8391dcd719711716492063030b55ac upstream.
    
    In commit d4d6715, we reopened an old hole for a 64-bit ptracer touching a
    32-bit tracee in system call entry.  A %rax value set via ptrace at the
    entry tracing stop gets used whole as a 32-bit syscall number, while we
    only check the low 32 bits for validity.
    
    Fix it by truncating %rax back to 32 bits after syscall_trace_enter,
    in addition to testing the full 64 bits as has already been added.
    
    Reported-by: Ben Hawkes <[email protected]>
    Signed-off-by: Roland McGrath <[email protected]>
    Signed-off-by: H. Peter Anvin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=bacb67b5b9bd1172562f501a6837617c838179ce
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=a9c413b65f0584183517b6d491da1a4024eafcad
http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=be199cdcf850f0509c88fbd3fd2595ed9593f6aa
_______________________________________________
svn mailing list
[email protected]
http://mailman.vyatta.com/mailman/listinfo/svn

Reply via email to