23 Mar, 2009

7 commits

  • Ingo Molnar
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fixes:
    kconfig: improve seed in randconfig
    kconfig: fix randconfig for choice blocks

    Linus Torvalds
     
  • * 'fix-includes' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
    m68k: merge the non-MMU and MMU versions of siginfo.h
    m68k: use the MMU version of unistd.h for all m68k platforms
    m68k: merge the non-MMU and MMU versions of signal.h
    m68k: merge the non-MMU and MMU versions of ptrace.h
    m68k: use MMU version of setup.h for both MMU and non-MMU
    m68k: merge the non-MMU and MMU versions of sigcontext.h
    m68k: merge the non-MMU and MMU versions of swab.h
    m68k: merge the non-MMU and MMU versions of param.h

    Linus Torvalds
     
  • Update all previous incarnations of my email address to the correct one.

    Signed-off-by: Gertjan van Wingerde
    Signed-off-by: Linus Torvalds

    Gertjan van Wingerde
     
  • If ecryptfs_encrypted_view or ecryptfs_xattr_metadata were being
    specified as mount options, a NULL pointer dereference of crypt_stat
    was possible during lookup.

    This patch moves the crypt_stat assignment into
    ecryptfs_lookup_and_interpose_lower(), ensuring that crypt_stat
    will not be NULL before we attempt to dereference it.

    Thanks to Dan Carpenter and his static analysis tool, smatch, for
    finding this bug.

    Signed-off-by: Tyler Hicks
    Acked-by: Dustin Kirkland
    Cc: Dan Carpenter
    Cc: Serge Hallyn
    Signed-off-by: Linus Torvalds

    Tyler Hicks
     
  • When allocating the memory used to store the eCryptfs header contents, a
    single, zeroed page was being allocated with get_zeroed_page().
    However, the size of an eCryptfs header is either PAGE_CACHE_SIZE or
    ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE (8192), whichever is larger, and is
    stored in the file's private_data->crypt_stat->num_header_bytes_at_front
    field.

    ecryptfs_write_metadata_to_contents() was using
    num_header_bytes_at_front to decide how many bytes should be written to
    the lower filesystem for the file header. Unfortunately, at least 8K
    was being written from the page, despite the chance of the single,
    zeroed page being smaller than 8K. This resulted in random areas of
    kernel memory being written between the 0x1000 and 0x1FFF bytes offsets
    in the eCryptfs file headers if PAGE_SIZE was 4K.

    This patch allocates a variable number of pages, calculated with
    num_header_bytes_at_front, and passes the number of allocated pages
    along to ecryptfs_write_metadata_to_contents().

    Thanks to Florian Streibelt for reporting the data leak and working with
    me to find the problem. 2.6.28 is the only kernel release with this
    vulnerability. Corresponds to CVE-2009-0787

    Signed-off-by: Tyler Hicks
    Acked-by: Dustin Kirkland
    Reviewed-by: Eric Sandeen
    Reviewed-by: Eugene Teo
    Cc: Greg KH
    Cc: dann frazier
    Cc: Serge E. Hallyn
    Cc: Florian Streibelt
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds

    Tyler Hicks
     
  • This fixes a regression introduced when we switched to using the core
    pci_set_power_state(). The chip seems to need the state to be written
    over and over again until it sticks, so we do that.

    Note that the code is a bit blunt, without timeout, etc... but that's
    pretty much because I put back in there the code exactly as it used to
    be before the regression. I still add a call to pci_set_power_state()
    at the end so that ACPI gets called appropriately on x86.

    Signed-off-by: Benjamin Herrenschmidt
    Tested-by: Raymond Wooninck
    Acked-by: Rafael J. Wysocki
    Cc: Jesse Barnes
    Cc: Andrew Morton
    Signed-off-by: Linus Torvalds

    Benjamin Herrenschmidt
     

20 Mar, 2009

8 commits

  • The libaio test harness turned up a problem whereby lookup_ioctx on a
    bogus io context was returning the 1 valid io context from the list
    (harness/cases/3.p).

    Because of that, an extra put_iocontext was done, and when the process
    exited, it hit a BUG_ON in the put_iocontext macro called from exit_aio
    (since we expect a users count of 1 and instead get 0).

    The problem was introduced by "aio: make the lookup_ioctx() lockless"
    (commit abf137dd7712132ee56d5b3143c2ff61a72a5faa).

    Thanks to Zach for pointing out that hlist_for_each_entry_rcu will not
    return with a NULL tpos at the end of the loop, even if the entry was
    not found.

    Signed-off-by: Jeff Moyer
    Acked-by: Zach Brown
    Acked-by: Jens Axboe
    Cc: Benjamin LaHaise
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Moyer
     
  • Remove a source of fput() call from inside IRQ context. Myself, like Eric,
    wasn't able to reproduce an fput() call from IRQ context, but Jeff said he was
    able to, with the attached test program. Independently from this, the bug is
    conceptually there, so we might be better off fixing it. This patch adds an
    optimization similar to the one we already do on ->ki_filp, on ->ki_eventfd.
    Playing with ->f_count directly is not pretty in general, but the alternative
    here would be to add a brand new delayed fput() infrastructure, that I'm not
    sure is worth it.

    Signed-off-by: Davide Libenzi
    Cc: Benjamin LaHaise
    Cc: Trond Myklebust
    Cc: Eric Dumazet
    Signed-off-by: Jeff Moyer
    Cc: Zach Brown
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Davide Libenzi
     
  • Sam Ravnborg says:
    "We have several architectures that plays strange games with $(CC) and
    $(CROSS_COMPILE).

    So we need to postpone any use of $(call cc-option..) until we have
    included the arch specific Makefile so we try with the correct $(CC)
    version."

    Requested-by: Sam Ravnborg
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • * 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6:
    [S390] make page table upgrade work again
    [S390] make page table walking more robust
    [S390] Dont check for pfn_valid() in uaccess_pt.c
    [S390] ftrace/mcount: fix kernel stack backchain
    [S390] topology: define SD_MC_INIT to fix performance regression
    [S390] __div64_31 broken for CONFIG_MARCH_G5

    Linus Torvalds
     
  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
    HID: fix waitqueue usage in hiddev
    HID: fix incorrect free in hiddev

    Linus Torvalds
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable:
    Btrfs: Clear space_info full when adding new devices
    Btrfs: Fix locking around adding new space_info

    Linus Torvalds
     
  • Nick Piggin noticed this (very unlikely) race between setting a page
    dirty and creating the buffers for it - we need to hold the mapping
    private_lock until we've set the page dirty bit in order to make sure
    that create_empty_buffers() might not build up a set of buffers without
    the dirty bits set when the page is dirty.

    I doubt anybody has ever hit this race (and it didn't solve the issue
    Nick was looking at), but as Nick says: "Still, it does appear to solve
    a real race, which we should close."

    Acked-by: Nick Piggin
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     
  • This makes sure that gcc doesn't try to optimize away wrapping
    arithmetic, which the kernel occasionally uses for overflow testing, ie
    things like

    if (ptr + offset < ptr)

    which technically is undefined for non-unsigned types. See

    http://bugzilla.kernel.org/show_bug.cgi?id=12597

    for details.

    Not all versions of gcc support it, so we need to make it conditional
    (it looks like it was introduced in gcc-3.4).

    Reminded-by: Alan Cox
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

19 Mar, 2009

6 commits


18 Mar, 2009

19 commits