1. 13 10月, 2012 1 次提交
  2. 26 8月, 2011 1 次提交
    • A
      Add a personality to report 2.6.x version numbers · be27425d
      Andi Kleen 提交于
      I ran into a couple of programs which broke with the new Linux 3.0
      version.  Some of those were binary only.  I tried to use LD_PRELOAD to
      work around it, but it was quite difficult and in one case impossible
      because of a mix of 32bit and 64bit executables.
      
      For example, all kind of management software from HP doesnt work, unless
      we pretend to run a 2.6 kernel.
      
        $ uname -a
        Linux svivoipvnx001 3.0.0-08107-g97cd98f #1062 SMP Fri Aug 12 18:11:45 CEST 2011 i686 i686 i386 GNU/Linux
      
        $ hpacucli ctrl all show
      
        Error: No controllers detected.
      
        $ rpm -qf /usr/sbin/hpacucli
        hpacucli-8.75-12.0
      
      Another notable case is that Python now reports "linux3" from
      sys.platform(); which in turn can break things that were checking
      sys.platform() == "linux2":
      
        https://bugzilla.mozilla.org/show_bug.cgi?id=664564
      
      It seems pretty clear to me though it's a bug in the apps that are using
      '==' instead of .startswith(), but this allows us to unbreak broken
      programs.
      
      This patch adds a UNAME26 personality that makes the kernel report a
      2.6.40+x version number instead.  The x is the x in 3.x.
      
      I know this is somewhat ugly, but I didn't find a better workaround, and
      compatibility to existing programs is important.
      
      Some programs also read /proc/sys/kernel/osrelease.  This can be worked
      around in user space with mount --bind (and a mount namespace)
      
      To use:
      
        wget ftp://ftp.kernel.org/pub/linux/kernel/people/ak/uname26/uname26.c
        gcc -o uname26 uname26.c
        ./uname26 program
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      be27425d
  3. 05 6月, 2010 1 次提交
    • O
      sys_personality: change sys_personality() to accept "unsigned int" instead of u_long · 485d5276
      Oleg Nesterov 提交于
      task_struct->pesonality is "unsigned int", but sys_personality() paths use
      "unsigned long pesonality".  This means that every assignment or
      comparison is not right.  In particular, if this argument does not fit
      into "unsigned int" __set_personality() changes the caller's personality
      and then sys_personality() returns -EINVAL.
      
      Turn this argument into "unsigned int" and avoid overflows.  Obviously,
      this is the user-visible change, we just ignore the upper bits.  But this
      can't break the sane application.
      
      There is another thing which can confuse the poorly written applications.
      User-space thinks that this syscall returns int, not long.  This means
      that the returned value can be negative and look like the error code.  But
      note that libc won't be confused and thus errno won't be set, and with
      this patch the user-space can never get -1 unless sys_personality() really
      fails.  And, most importantly, the negative RET != -1 is only possible if
      that app previously called personality(RET).
      Pointed-out-by: NWenming Zhang <wezhang@redhat.com>
      Suggested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      485d5276
  4. 13 7月, 2009 2 次提交
    • J
      personality handling: fix PER_CLEAR_ON_SETID for security reasons · b3a633c8
      Julien Tinnes 提交于
      We have found that the current PER_CLEAR_ON_SETID mask on Linux
      doesn't include neither ADDR_COMPAT_LAYOUT, nor MMAP_PAGE_ZERO.
      
      The current mask is READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE.
      
      We believe it is important to add MMAP_PAGE_ZERO, because by using
      this personality it is possible to have the first page mapped inside a
      process running as setuid root. This could be used in those scenarios:
      
      - Exploiting a NULL pointer dereference issue in a setuid root binary
      - Bypassing the mmap_min_addr restrictions of the Linux kernel: by
      running a setuid binary that would drop privileges before giving us
      control back (for instance by loading a user-supplied library), we
      could get the first page mapped in a process we control. By further
      using mremap and mprotect on this mapping, we can then completely
      bypass the mmap_min_addr restrictions.
      
      Less importantly, we believe ADDR_COMPAT_LAYOUT should also be added
      since on x86 32bits it will in practice disable most of the address
      space layout randomization (only the stack will remain randomized).
      Signed-off-by: NJulien Tinnes <jt@cr0.org>
      Signed-off-by: NTavis Ormandy <taviso@sdf.lonestar.org>
      Acked-by: NChristoph Hellwig <hch@infradead.org>
      Acked-by: NKees Cook <kees.cook@canonical.com>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      b3a633c8
    • J
      personality: fix PER_CLEAR_ON_SETID · f9fabcb5
      Julien Tinnes 提交于
      We have found that the current PER_CLEAR_ON_SETID mask on Linux doesn't
      include neither ADDR_COMPAT_LAYOUT, nor MMAP_PAGE_ZERO.
      
      The current mask is READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE.
      
      We believe it is important to add MMAP_PAGE_ZERO, because by using this
      personality it is possible to have the first page mapped inside a
      process running as setuid root.  This could be used in those scenarios:
      
       - Exploiting a NULL pointer dereference issue in a setuid root binary
       - Bypassing the mmap_min_addr restrictions of the Linux kernel: by
         running a setuid binary that would drop privileges before giving us
         control back (for instance by loading a user-supplied library), we
         could get the first page mapped in a process we control.  By further
         using mremap and mprotect on this mapping, we can then completely
         bypass the mmap_min_addr restrictions.
      
      Less importantly, we believe ADDR_COMPAT_LAYOUT should also be added
      since on x86 32bits it will in practice disable most of the address
      space layout randomization (only the stack will remain randomized).
      Signed-off-by: NJulien Tinnes <jt@cr0.org>
      Signed-off-by: NTavis Ormandy <taviso@sdf.lonestar.org>
      Cc: stable@kernel.org
      Acked-by: NChristoph Hellwig <hch@infradead.org>
      Acked-by: NKees Cook <kees@ubuntu.com>
      Acked-by: NEugene Teo <eugene@redhat.com>
      [ Shortened lines and fixed whitespace as per Christophs' suggestion ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f9fabcb5
  5. 29 4月, 2008 1 次提交
  6. 13 11月, 2006 1 次提交
  7. 21 10月, 2006 1 次提交
  8. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4