01 Apr, 2006

1 commit

  • This patch extends current iptables compatibility layer in order to get
    32bit iptables to work on 64bit kernel. Current layer is insufficient due
    to alignment checks both in kernel and user space tools.

    Patch is for current net-2.6.17 with addition of move of ipt_entry_{match|
    target} definitions to xt_entry_{match|target}.

    Signed-off-by: Dmitry Mishin
    Acked-off-by: Kirill Korotaev
    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Dmitry Mishin
     

22 Mar, 2006

1 commit


21 Mar, 2006

1 commit


08 Sep, 2005

1 commit

  • When we copy 32bit ->msg_control contents to kernel, we walk the same
    userland data twice without sanity checks on the second pass.

    Second version of this patch: the original broke with 64-bit arches
    running 32-bit-compat-mode executables doing sendmsg() syscalls with
    unaligned CMSG data areas

    Another thing is that we use kmalloc() to allocate and sock_kfree_s()
    to free afterwards; less serious, but also needs fixing.

    Signed-off-by: Al Viro
    Signed-off-by: David Woodhouse
    Signed-off-by: Chris Wright
    Signed-off-by: Linus Torvalds

    Al Viro
     

10 Aug, 2005

1 commit

  • From: Dave Johnson

    sendmsg()/recvmsg() syscalls from o32/n32 apps to a 64bit kernel will
    cause a kernel memory leak if iov_len > UIO_FASTIOV for each syscall!

    This is because both sys_sendmsg() and verify_compat_iovec() kmalloc a
    new iovec structure. Only the one from sys_sendmsg() is free'ed.

    I wrote a simple test program to confirm this after identifying the
    problem:

    http://davej.org/programs/testsendmsg.c

    Note that the below fix will break solaris_sendmsg()/solaris_recvmsg() as
    it also calls verify_compat_iovec() but expects it to malloc internally.

    [ I fixed that. -DaveM ]

    Signed-off-by: Andrew Morton
    Signed-off-by: David S. Miller

    Andrew Morton
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds