Commits on Aug 10, 2010
  1. Linux

    gregkh committed Aug 10, 2010
  2. GFS2: rename causes kernel Oops

    commit 728a756 upstream.
    This patch fixes a kernel Oops in the GFS2 rename code.
    The problem was in the way the gfs2 directory code was trying
    to re-use sentinel directory entries.
    In the failing case, gfs2's rename function was renaming a
    file to another name that had the same non-trivial length.
    The file being renamed happened to be the first directory
    entry on the leaf block.
    First, the rename code (gfs2_rename in ops_inode.c) found the
    original directory entry and decided it could do its job by
    simply replacing the directory entry with another.  Therefore
    it determined correctly that no block allocations were needed.
    Next, the rename code deleted the old directory entry prior to
    replacing it with the new name.  Therefore, the soon-to-be
    replaced directory entry was temporarily made into a directory
    entry "sentinel" or a place holder at the start of a leaf block.
    Lastly, it went to re-add the replacement directory entry in
    that leaf block.  However, when gfs2_dirent_find_space was
    looking for space in the leaf block, it used the wrong value
    for the sentinel.  That threw off its calculations so later
    it decides it can't really re-use the sentinel and therefore
    must allocate a new leaf block.  But because it previously decided
    to re-use the directory entry, it didn't waste the time to
    grab a new block allocation for the inode.  Therefore, the
    inode's i_alloc pointer was still NULL and it crashes trying to
    reference it.
    In the case of sentinel directory entries, the entire dirent is
    reused, not just the "free space" portion of it, and therefore
    the function gfs2_dirent_find_space should use the value 0
    rather than GFS2_DIRENT_SIZE(0) for the actual dirent size.
    Fixing this calculation enables the reproducer programs to work
    Signed-off-by: Bob Peterson <>
    Signed-off-by: Steven Whitehouse <>
    Signed-off-by: Greg Kroah-Hartman <>
    Bob Peterson committed with gregkh Jul 14, 2010
  3. SCSI: enclosure: fix error path - actually return ERR_PTR() on error

    commit a91c1be upstream.
    we also need to clean up and free the cdev.
    Reported-by: Jani Nikula <>
    Signed-off-by: James Bottomley <>
    Signed-off-by: Greg Kroah-Hartman <>
    James Bottomley committed with gregkh Mar 12, 2010
  4. xfs: prevent swapext from operating on write-only files

    commit 1817176 upstream.
    This patch prevents user "foo" from using the SWAPEXT ioctl to swap
    a write-only file owned by user "bar" into a file owned by "foo" and
    subsequently reading it.  It does so by checking that the file
    descriptors passed to the ioctl are also opened for reading.
    Signed-off-by: Dan Rosenberg <>
    Reviewed-by: Christoph Hellwig <>
    Signed-off-by: Greg Kroah-Hartman <>
    djrbliss committed with gregkh Jun 24, 2010
  5. PARISC: led.c - fix potential stack overflow in led_proc_write()

    commit 4b4fd27 upstream.
    avoid potential stack overflow by correctly checking count parameter
    Reported-by: Ilja <>
    Signed-off-by: Helge Deller <>
    Acked-by: Kyle McMartin <>
    Cc: James E.J. Bottomley <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Helge Deller committed with gregkh Aug 2, 2010
Commits on Aug 6, 2010
  1. .gitignore updates

    commit c17dad6 upstream.
    Signed-off-by: Alexey Dobriyan <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Alexey Dobriyan committed with gregkh Oct 29, 2008
Commits on Aug 2, 2010
  1. Linux

    gregkh committed Aug 2, 2010
  2. ecryptfs: Bugfix for error related to ecryptfs_hash_buckets

    commit a6f80fb upstream.
    The function ecryptfs_uid_hash wrongly assumes that the
    second parameter to hash_long() is the number of hash
    buckets instead of the number of hash bits.
    This patch fixes that and renames the variable
    ecryptfs_hash_buckets to ecryptfs_hash_bits to make it
    Fixes: CVE-2010-2492
    Signed-off-by: Andre Osterhues <>
    Signed-off-by: Tyler Hicks <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
    Andre Osterhues committed with gregkh Jul 13, 2010
  3. kbuild: Fix modpost segfault

    commit 1c93866 upstream.
    Alan <> writes:
    > program: /home/alan/GitTrees/linux-2.6-mid-ref/scripts/mod/modpost -o
    > Module.symvers -S vmlinux.o
    > Program received signal SIGSEGV, Segmentation fault.
    It just hit me.
    It's the offset calculation in reloc_location() which overflows:
            return (void *)elf->hdr + sechdrs[section].sh_offset +
                   (r->r_offset - sechdrs[section].sh_addr);
    E.g. for the first rodata r entry:
    r->r_offset < sechdrs[section].sh_addr
    and the expression in the parenthesis produces 0xFFFFFFE0 or something
    equally wise.
    Reported-by: Alan <>
    Signed-off-by: Krzysztof Hałasa <>
    Tested-by: Alan <>
    Signed-off-by: Michal Marek <>
    Signed-off-by: Greg Kroah-Hartman <>
    Krzysztof Halasa committed with gregkh Jun 10, 2010
  4. bonding: select current active slave when enslaving device for mode t…

    …lb and alb
    commit 5a29f78 upstream.
    I've hit an issue on my system when I've been using RealTek RTL8139D cards in
    bonding interface in mode balancing-alb. When I enslave a card, the current
    active slave (bond->curr_active_slave) is not set and the link is therefore
    not functional.
    # cat /proc/net/bonding/bond0
    Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
    Bonding Mode: adaptive load balancing
    Primary Slave: None
    Currently Active Slave: None
    MII Status: up
    MII Polling Interval (ms): 100
    Up Delay (ms): 0
    Down Delay (ms): 0
    Slave Interface: eth1
    MII Status: up
    Link Failure Count: 0
    Permanent HW addr: 00:1f:1f:01:2f:22
    The thing that gets it right is when I unplug the cable and then I put it back
    into the NIC. Then the current active slave is set to eth1 and link is working
    just fine. Here is dmesg log with bonding DEBUG messages turned on:
    ADDRCONF(NETDEV_UP): bond0: link is not ready
    event_dev: bond0, event: 1
    event_dev: bond0, event: 8
    bond_ioctl: master=bond0, cmd=35216
    event_dev: eth1, event: 8
    eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1
    event_dev: eth1, event: 1
    event_dev: eth1, event: 8
    Initial state of slave_dev is BOND_LINK_UP
    bonding: bond0: enslaving eth1 as an active interface with an up link.
    ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
    event_dev: bond0, event: 4
    bond0: no IPv6 routers present
    <<<<cable unplug>>>>
    eth1: link down
    event_dev: eth1, event: 4
    bonding: bond0: link status definitely down for interface eth1, disabling it
    event_dev: bond0, event: 4
    <<<<cable plug>>>>
    eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1
    event_dev: eth1, event: 4
    bonding: bond0: link status definitely up for interface eth1.
    bonding: bond0: making interface eth1 the new active one.
    event_dev: eth1, event: 8
    event_dev: eth1, event: 8
    bonding: bond0: first active interface up!
    event_dev: bond0, event: 4
    The current active slave is set by calling bond_select_active_slave() function
    from bond_miimon_commit() function when the slave (eth1) link goes to state up.
    I also tested this on other machine with Broadcom NetXtreme II BCM5708
    1000Base-T NIC and there all works fine. The thing is that this adapter is down
    and goes up after few seconds after it is enslaved.
    This patch calls bond_select_active_slave() in bond_enslave() function for modes
    alb and tlb and makes sure that the current active slave is set up properly even
    when the slave state is already up. Tested on both systems, works fine.
    Notice: The same problem can maybe also occrur in mode 8023AD but I'm unable to
    test that.
    Signed-off-by: Jiri Pirko <>
    Signed-off-by: David S. Miller <>
    Cc: Jean Delvare <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jiri Pirko committed with gregkh Mar 26, 2009
  5. IPoIB: Fix world-writable child interface control sysfs attributes

    commit 7a52b34 upstream.
    Sumeet Lahorani <> reported that the IPoIB
    child entries are world-writable; however we don't want ordinary users
    to be able to create and destroy child interfaces, so fix them to be
    writable only by root.
    Signed-off-by: Or Gerlitz <>
    Signed-off-by: Roland Dreier <>
    Signed-off-by: Greg Kroah-Hartman <>
    Or Gerlitz committed with gregkh Jun 6, 2010
  6. x86, Calgary: Limit the max PHB number to 256

    commit d596043 upstream.
    The x3950 family can have as many as 256 PCI buses in a single system, so
    change the limits to the maximum.  Since there can only be 256 PCI buses in one
    domain, we no longer need the BUG_ON check.
    Signed-off-by: Darrick J. Wong <>
    LKML-Reference: <>
    Signed-off-by: H. Peter Anvin <>
    Signed-off-by: Greg Kroah-Hartman <>
    Darrick J. Wong committed with gregkh Jul 1, 2010
  7. x86, Calgary: Increase max PHB number

    commit 499a00e upstream.
    Newer systems (x3950M2) can have 48 PHBs per chassis and 8
    chassis, so bump the limits up and provide an explanation
    of the requirements for each class.
    Signed-off-by: Darrick J. Wong <>
    Acked-by: Muli Ben-Yehuda <>
    Cc: Corinna Schultz <>
    LKML-Reference: <>
    [ v2: Fixed build bug, added back PHBS_PER_CALGARY == 4 ]
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
    Darrick J. Wong committed with gregkh Jun 24, 2010
  8. amd64-agp: Probe unknown AGP devices the right way

    commit 6fd0248 upstream.
    The current initialisation code probes 'unsupported' AGP devices
    simply by calling its own probe function.  It does not lock these
    devices or even check whether another driver is already bound to
    We must use the device core to manage this.  So if the specific
    device id table didn't match anything and agp_try_unsupported=1,
    switch the device id table and call driver_attach() again.
    Signed-off-by: Ben Hutchings <>
    Signed-off-by: Dave Airlie <>
    Signed-off-by: Greg Kroah-Hartman <>
    bwhacks committed with gregkh Mar 24, 2010
  9. SCSI: aacraid: Eliminate use after free

    commit 8a52da6 upstream.
    The debugging code using the freed structure is moved before the kfree.
    A simplified version of the semantic match that finds this problem is as
    follows: (
    // <smpl>
    expression E;
    position p;
    expression free.E, subE<=free.E, E1;
    position free.p;
      subE = E1
    * E
    // </smpl>
    Signed-off-by: Julia Lawall <>
    Signed-off-by: James Bottomley <>
    JuliaLawall committed with gregkh May 15, 2010
  10. netfilter: ip6t_REJECT: fix a dst leak in ipv6 REJECT

    commit 499031a upstream.
    We should release dst if dst->error is set.
    Bug introduced in 2.6.14 by commit e104411
    ([XFRM]: Always release dst_entry on error in xfrm_lookup)
    Signed-off-by: Eric Dumazet <>
    Signed-off-by: Patrick McHardy <>
    Signed-off-by: Greg Kroah-Hartman <>
    Eric Dumazet committed with gregkh Jul 2, 2010
  11. hostap: Protect against initialization interrupt

    commit d6a574f upstream.
    Use an irq spinlock to hold off the IRQ handler until
    enough early card init is complete such that the handler
    can run without faulting.
    Signed-off-by: Tim Gardner <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
    Tim Gardner committed with gregkh Jun 8, 2010
  12. math-emu: correct test for downshifting fraction in _FP_FROM_INT()

    commit f8324e2 upstream.
    The kernel's math-emu code contains a macro _FP_FROM_INT() which is
    used to convert an integer to a raw normalized floating-point value.
    It does this basically in three steps:
    1. Compute the exponent from the number of leading zero bits.
    2. Downshift large fractions to put the MSB in the right position
       for normalized fractions.
    3. Upshift small fractions to put the MSB in the right position.
    There is an boundary error in step 2, causing a fraction with its
    MSB exactly one bit above the normalized MSB position to not be
    downshifted.  This results in a non-normalized raw float, which when
    packed becomes a massively inaccurate representation for that input.
    The impact of this depends on a number of arch-specific factors,
    but it is known to have broken emulation of FXTOD instructions
    on UltraSPARC III, which was originally reported as GCC bug 44631
    Any arch which uses math-emu to emulate conversions from integers to
    same-size floats may be affected.
    The fix is simple: the exponent comparison used to determine if the
    fraction should be downshifted must be "<=" not "<".
    I'm sending a kernel module to test this as a reply to this message.
    There are also SPARC user-space test cases in the GCC bug entry.
    Signed-off-by: Mikael Pettersson <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Mikael Pettersson committed with gregkh Jul 21, 2010
  13. sky2: enable rx/tx in sky2_phy_reinit()

    commit 38000a9 upstream.
    sky2_phy_reinit is called by the ethtool helpers sky2_set_settings,
    sky2_nway_reset and sky2_set_pauseparam when netif_running.
    However, at the end of sky2_phy_init GM_GP_CTRL has GM_GPCR_RX_ENA and
    GM_GPCR_TX_ENA cleared. So, doing these commands causes the device to
    stop working:
    $ ethtool -r eth0
    $ ethtool -A eth0 autoneg off
    Fix this issue by enabling Rx/Tx after running sky2_phy_init in
    Signed-off-by: Brandon Philips <>
    Tested-by: Brandon Philips <>
    Tested-by: Mike McCormack <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    philips committed with gregkh Jun 16, 2010
  14. cpmac: do not leak struct net_device on phy_connect errors

    commit ed770f0 upstream.
    If the call to phy_connect fails, we will return directly instead of freeing
    the previously allocated struct net_device.
    Signed-off-by: Florian Fainelli <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    ffainelli committed with gregkh Jun 20, 2010
  15. cifs: Fix a kernel BUG with remote OS/2 server (try #3)

    commit 6513a81 upstream.
    While chasing a bug report involving a OS/2 server, I noticed the server sets
    pSMBr->CountHigh to a incorrect value even in case of normal writes. This
    results in 'nbytes' being computed wrongly and triggers a kernel BUG at
    void iov_iter_advance(struct iov_iter *i, size_t bytes)
            BUG_ON(i->count < bytes);    <--- BUG here
    Why the server is setting 'CountHigh' is not clear but only does so after
    writing 64k bytes. Though this looks like the server bug, the client side
    crash may not be acceptable.
    The workaround is to mask off high 16 bits if the number of bytes written as
    returned by the server is greater than the bytes requested by the client as
    suggested by Jeff Layton.
    Reviewed-by: Jeff Layton <>
    Signed-off-by: Suresh Jayaraman <>
    Signed-off-by: Steve French <>
    Signed-off-by: Greg Kroah-Hartman <>
    Suresh Jayaraman committed with gregkh Mar 31, 2010
  16. cifs: remove bogus first_time check in NTLMv2 session setup code

    commit 8a224d4 upstream.
    This bug appears to be the result of a cut-and-paste mistake from the
    NTLMv1 code. The function to generate the MAC key was commented out, but
    not the conditional above it. The conditional then ended up causing the
    session setup key not to be copied to the buffer unless this was the
    first session on the socket, and that made all but the first NTLMv2
    session setup fail.
    Fix this by removing the conditional and all of the commented clutter
    that made it difficult to see.
    Reported-by: Gunther Deschner <>
    Signed-off-by: Jeff Layton <>
    Signed-off-by: Greg Kroah-Hartman <>
    jtlayton committed with gregkh Jun 16, 2010
  17. hwmon: (coretemp) Skip duplicate CPU entries

    commit d883b9f upstream.
    On hyper-threaded CPUs, each core appears twice in the CPU list. Skip
    the second entry to avoid duplicate sensors.
    Signed-off-by: Jean Delvare <>
    Acked-by: Huaxu Wan <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jean Delvare committed with gregkh Jul 9, 2010
  18. hwmon: (coretemp) Properly label the sensors

    commit 3f4f09b upstream.
    Don't assume that CPU entry number and core ID always match. It
    worked in the simple cases (single CPU, no HT) but fails on
    multi-CPU systems.
    Signed-off-by: Jean Delvare <>
    Acked-by: Huaxu Wan <>
    Signed-off-by: Greg Kroah-Hartman <>
    Jean Delvare committed with gregkh Jul 9, 2010
Commits on Jul 5, 2010
  1. Linux

    gregkh committed Jul 5, 2010
  2. sctp: fix append error cause to ERROR chunk correctly

    commit 2e3219b upstream.
    commit 5fa782c
      sctp: Fix skb_over_panic resulting from multiple invalid \
        parameter errors (CVE-2010-1173) (v4)
    cause 'error cause' never be add the the ERROR chunk due to
    some typo when check valid length in sctp_init_cause_fixed().
    Signed-off-by: Wei Yongjun <>
    Reviewed-by: Neil Horman <>
    Acked-by: Vlad Yasevich <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Wei Yongjun committed with gregkh May 18, 2010
  3. KEYS: find_keyring_by_name() can gain access to a freed keyring

    commit cea7daa upstream.
    find_keyring_by_name() can gain access to a keyring that has had its reference
    count reduced to zero, and is thus ready to be freed.  This then allows the
    dead keyring to be brought back into use whilst it is being destroyed.
    The following timeline illustrates the process:
    |(cleaner)                           (user)
    | free_user(user)                    sys_keyctl()
    |  |                                  |
    |  key_put(user->session_keyring)     keyctl_get_keyring_ID()
    |  ||	//=> keyring->usage = 0        |
    |  |schedule_work(&key_cleanup_task)   lookup_user_key()
    |  ||                                   |
    |  kmem_cache_free(,user)               |
    |  .                                    |[KEY_SPEC_USER_KEYRING]
    |  .                                    install_user_keyrings()
    |  .                                    ||
    | key_cleanup() [<= worker_thread()]    ||
    |  |                                    ||
    |  [spin_lock(&key_serial_lock)]        |[mutex_lock(&key_user_keyr..mutex)]
    |  |                                    ||
    |  atomic_read() == 0                   ||
    |  |{ rb_ease(&key->serial_node,) }     ||
    |  |                                    ||
    |  [spin_unlock(&key_serial_lock)]      |find_keyring_by_name()
    |  |                                    |||
    |  keyring_destroy(keyring)             ||[read_lock(&keyring_name_lock)]
    |  ||                                   |||
    |  |[write_lock(&keyring_name_lock)]    ||atomic_inc(&keyring->usage)
    |  |.                                   ||| *** GET freeing keyring ***
    |  |.                                   ||[read_unlock(&keyring_name_lock)]
    |  ||                                   ||
    |  |list_del()                          |[mutex_unlock(&key_user_k..mutex)]
    |  ||                                   |
    |  |[write_unlock(&keyring_name_lock)]  ** INVALID keyring is returned **
    |  |                                    .
    |  kmem_cache_free(,keyring)            .
    |                                       .
    |                                       atomic_dec(&keyring->usage)
    v                                         *** DESTROYED ***
    If CONFIG_SLUB_DEBUG=y then we may see the following message generated:
    	BUG key_jar: Poison overwritten
    	INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b
    	INFO: Allocated in key_alloc+0x10b/0x35f age=25 cpu=1 pid=5086
    	INFO: Freed in key_cleanup+0xd0/0xd5 age=12 cpu=1 pid=10
    	INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3
    	INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300
    	Bytes b4 0xffff880197a7e1f0:  5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
    	  Object 0xffff880197a7e200:  6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk
    Alternatively, we may see a system panic happen, such as:
    	BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
    	IP: [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
    	PGD 6b2b4067 PUD 6a80d067 PMD 0
    	Oops: 0000 [#1] SMP
    	last sysfs file: /sys/kernel/kexec_crash_loaded
    	CPU 1
    	Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY
    	RIP: 0010:[<ffffffff810e61a3>]  [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
    	RSP: 0018:ffff88006af3bd98  EFLAGS: 00010002
    	RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88007d19900b
    	RDX: 0000000100000000 RSI: 00000000000080d0 RDI: ffffffff81828430
    	RBP: ffffffff81828430 R08: ffff88000a293750 R09: 0000000000000000
    	R10: 0000000000000001 R11: 0000000000100000 R12: 00000000000080d0
    	R13: 00000000000080d0 R14: 0000000000000296 R15: ffffffff810f20ce
    	FS:  00007f97116bc700(0000) GS:ffff88000a280000(0000) knlGS:0000000000000000
    	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    	CR2: 0000000000000001 CR3: 000000006a91c000 CR4: 00000000000006e0
    	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    	DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    	Process su (pid: 31245, threadinfo ffff88006af3a000, task ffff8800374414c0)
    	 0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001
    	 0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce
    	 0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3
    	Call Trace:
    	 [<ffffffff810f20ce>] ? get_empty_filp+0x70/0x12f
    	 [<ffffffff810face3>] ? do_filp_open+0x145/0x590
    	 [<ffffffff810ce208>] ? tlb_finish_mmu+0x2a/0x33
    	 [<ffffffff810ce43c>] ? unmap_region+0xd3/0xe2
    	 [<ffffffff810e4393>] ? virt_to_head_page+0x9/0x2d
    	 [<ffffffff81103916>] ? alloc_fd+0x69/0x10e
    	 [<ffffffff810ef4ed>] ? do_sys_open+0x56/0xfc
    	 [<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
    	Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef
    	RIP  [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
    This problem is that find_keyring_by_name does not confirm that the keyring is
    valid before accepting it.
    Skipping keyrings that have been reduced to a zero count seems the way to go.
    To this end, use atomic_inc_not_zero() to increment the usage count and skip
    the candidate keyring if that returns false.
    The following script _may_ cause the bug to happen, but there's no guarantee
    as the window of opportunity is small:
    	/bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
    	for ((i=0; i<LOOP; i++))
    		/bin/su -c "echo '$i' > /dev/null" $USER
    	(( add == 1 )) && /usr/sbin/userdel -r $USER
    Note that the nominated user must not be in use.
    An alternative way of testing this may be:
    	for ((i=0; i<100000; i++))
    		keyctl session foo /bin/true || break
    	done >&/dev/null
    as that uses a keyring named "foo" rather than relying on the user and
    user-session named keyrings.
    Reported-by: Toshiyuki Okajima <>
    Signed-off-by: David Howells <>
    Tested-by: Toshiyuki Okajima <>
    Acked-by: Serge Hallyn <>
    Signed-off-by: James Morris <>
    Cc: Ben Hutchings <>
    Cc: Chuck Ebbert <>
    Signed-off-by: Greg Kroah-Hartman <>
    Toshiyuki Okajima committed with gregkh Apr 30, 2010
  4. KEYS: Return more accurate error codes

    commit 4d09ec0 upstream.
    We were using the wrong variable here so the error codes weren't being returned
    properly.  The original code returns -ENOKEY.
    Signed-off-by: Dan Carpenter <>
    Signed-off-by: David Howells <>
    Signed-off-by: James Morris <>
    Signed-off-by: Greg Kroah-Hartman <>
    error27 committed with gregkh May 17, 2010
  5. parisc: clear floating point exception flag on SIGFPE signal

    commit 550f0d9 upstream.
    Clear the floating point exception flag before returning to
    user space. This is needed, else the libc trampoline handler
    may hit the same SIGFPE again while building up a trampoline
    to a signal handler.
    Fixes debian bug #559406.
    Signed-off-by: Helge Deller <>
    Signed-off-by: Kyle McMartin <>
    Signed-off-by: Greg Kroah-Hartman <>
    Helge Deller committed with gregkh May 3, 2010
  6. tipc: Fix oops on send prior to entering networked mode (v3)

    commit d0021b2 upstream.
    Fix TIPC to disallow sending to remote addresses prior to entering NET_MODE
    user programs can oops the kernel by sending datagrams via AF_TIPC prior to
    entering networked mode.  The following backtrace has been observed:
    ID: 13459  TASK: ffff810014640040  CPU: 0   COMMAND: "tipc-client"
    [exception RIP: tipc_node_select_next_hop+90]
    RIP: ffffffff8869d3c3  RSP: ffff81002d9a5ab8  RFLAGS: 00010202
    RAX: 0000000000000001  RBX: 0000000000000001  RCX: 0000000000000001
    RDX: 0000000000000000  RSI: 0000000000000001  RDI: 0000000001001001
    RBP: 0000000001001001   R8: 0074736575716552   R9: 0000000000000000
    R10: ffff81003fbd0680  R11: 00000000000000c8  R12: 0000000000000008
    R13: 0000000000000001  R14: 0000000000000001  R15: ffff810015c6ca00
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
    RIP: 0000003cbd8d49a3  RSP: 00007fffc84e0be8  RFLAGS: 00010206
    RAX: 000000000000002c  RBX: ffffffff8005d116  RCX: 0000000000000000
    RDX: 0000000000000008  RSI: 00007fffc84e0c00  RDI: 0000000000000003
    RBP: 0000000000000000   R8: 00007fffc84e0c10   R9: 0000000000000010
    R10: 0000000000000000  R11: 0000000000000246  R12: 0000000000000000
    R13: 00007fffc84e0d10  R14: 0000000000000000  R15: 00007fffc84e0c30
    ORIG_RAX: 000000000000002c  CS: 0033  SS: 002b
    What happens is that, when the tipc module in inserted it enters a standalone
    node mode in which communication to its own address is allowed <0.0.0> but not
    to other addresses, since the appropriate data structures have not been
    allocated yet (specifically the tipc_net pointer).  There is nothing stopping a
    client from trying to send such a message however, and if that happens, we
    attempt to dereference tipc_net.zones while the pointer is still NULL, and
    explode.  The fix is pretty straightforward.  Since these oopses all arise from
    the dereference of global pointers prior to their assignment to allocated
    values, and since these allocations are small (about 2k total), lets convert
    these pointers to static arrays of the appropriate size.  All the accesses to
    these bits consider 0/NULL to be a non match when searching, so all the lookups
    still work properly, and there is no longer a chance of a bad dererence
    anywhere.  As a bonus, this lets us eliminate the setup/teardown routines for
    those pointers, and elimnates the need to preform any locking around them to
    prevent access while their being allocated/freed.
    I've updated the tipc_net structure to behave this way to fix the exact reported
    problem, and also fixed up the tipc_bearers and media_list arrays to fix an
    obvious simmilar problem that arises from issuing tipc-config commands to
    manipulate bearers/links prior to entering networked mode
    I've tested this for a few hours by running the sanity tests and stress test
    with the tipcutils suite, and nothing has fallen over.  There have been a few
    lockdep warnings, but those were there before, and can be addressed later, as
    they didn't actually result in any deadlock.
    Signed-off-by: Neil Horman <>
    CC: Allan Stephens <>
    CC: David S. Miller <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Neil Horman committed with gregkh Mar 3, 2010
  7. vfs: add NOFOLLOW flag to umount(2)

    commit db1f05b upstream.
    Add a new UMOUNT_NOFOLLOW flag to umount(2).  This is needed to prevent
    symlink attacks in unprivileged unmounts (fuse, samba, ncpfs).
    Additionally, return -EINVAL if an unknown flag is used (and specify
    an explicitly unused flag: UMOUNT_UNUSED).  This makes it possible for
    the caller to determine if a flag is supported or not.
    CC: Eugene Teo <>
    CC: Michael Kerrisk <>
    Signed-off-by: Miklos Szeredi <>
    Signed-off-by: Al Viro <>
    Signed-off-by: Greg Kroah-Hartman <>
    Miklos Szeredi committed with gregkh Feb 10, 2010
  8. sctp: Fix skb_over_panic resulting from multiple invalid parameter er…

    …rors (CVE-2010-1173) (v4)
    commit 5fa782c upstream.
    Ok, version 4
    Change Notes:
    1) Minor cleanups, from Vlads notes
    	Recently, it was reported to me that the kernel could oops in the
    following way:
    <5> kernel BUG at net/core/skbuff.c:91!
    <5> invalid operand: 0000 [#1]
    <5> Modules linked in: sctp netconsole nls_utf8 autofs4 sunrpc iptable_filter
    ip_tables cpufreq_powersave parport_pc lp parport vmblock(U) vsock(U) vmci(U)
    vmxnet(U) vmmemctl(U) vmhgfs(U) acpiphp dm_mirror dm_mod button battery ac md5
    ipv6 uhci_hcd ehci_hcd snd_ens1371 snd_rawmidi snd_seq_device snd_pcm_oss
    snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_ac97_codec snd soundcore
    pcnet32 mii floppy ext3 jbd ata_piix libata mptscsih mptsas mptspi mptscsi
    mptbase sd_mod scsi_mod
    <5> CPU:    0
    <5> EIP:    0060:[<c02bff27>]    Not tainted VLI
    <5> EFLAGS: 00010216   (2.6.9-89.0.25.EL)
    <5> EIP is at skb_over_panic+0x1f/0x2d
    <5> eax: 0000002c   ebx: c033f461   ecx: c0357d96   edx: c040fd44
    <5> esi: c033f461   edi: df653280   ebp: 00000000   esp: c040fd40
    <5> ds: 007b   es: 007b   ss: 0068
    <5> Process swapper (pid: 0, threadinfo=c040f000 task=c0370be0)
    <5> Stack: c0357d96 e0c29478 00000084 00000004 c033f461 df653280 d7883180
    <5>        00000000 00000080 df653490 00000004 de4f1ac0 de4f1ac0 00000004
    <5>        00000001 e0c2877a 08000800 de4f1ac0 df653490 00000000 e0c29d2e
    <5> Call Trace:
    <5>  [<e0c29478>] sctp_addto_chunk+0xb0/0x128 [sctp]
    <5>  [<e0c2947d>] sctp_addto_chunk+0xb5/0x128 [sctp]
    <5>  [<e0c2877a>] sctp_init_cause+0x3f/0x47 [sctp]
    <5>  [<e0c29d2e>] sctp_process_unk_param+0xac/0xb8 [sctp]
    <5>  [<e0c29e90>] sctp_verify_init+0xcc/0x134 [sctp]
    <5>  [<e0c20322>] sctp_sf_do_5_1B_init+0x83/0x28e [sctp]
    <5>  [<e0c25333>] sctp_do_sm+0x41/0x77 [sctp]
    <5>  [<c01555a4>] cache_grow+0x140/0x233
    <5>  [<e0c26ba1>] sctp_endpoint_bh_rcv+0xc5/0x108 [sctp]
    <5>  [<e0c2b863>] sctp_inq_push+0xe/0x10 [sctp]
    <5>  [<e0c34600>] sctp_rcv+0x454/0x509 [sctp]
    <5>  [<e084e017>] ipt_hook+0x17/0x1c [iptable_filter]
    <5>  [<c02d005e>] nf_iterate+0x40/0x81
    <5>  [<c02e0bb9>] ip_local_deliver_finish+0x0/0x151
    <5>  [<c02e0c7f>] ip_local_deliver_finish+0xc6/0x151
    <5>  [<c02d0362>] nf_hook_slow+0x83/0xb5
    <5>  [<c02e0bb2>] ip_local_deliver+0x1a2/0x1a9
    <5>  [<c02e0bb9>] ip_local_deliver_finish+0x0/0x151
    <5>  [<c02e103e>] ip_rcv+0x334/0x3b4
    <5>  [<c02c66fd>] netif_receive_skb+0x320/0x35b
    <5>  [<e0a0928b>] init_stall_timer+0x67/0x6a [uhci_hcd]
    <5>  [<c02c67a4>] process_backlog+0x6c/0xd9
    <5>  [<c02c690f>] net_rx_action+0xfe/0x1f8
    <5>  [<c012a7b1>] __do_softirq+0x35/0x79
    <5>  [<c0107efb>] handle_IRQ_event+0x0/0x4f
    <5>  [<c01094de>] do_softirq+0x46/0x4d
    Its an skb_over_panic BUG halt that results from processing an init chunk in
    which too many of its variable length parameters are in some way malformed.
    The problem is in sctp_process_unk_param:
    if (NULL == *errp)
    	*errp = sctp_make_op_error_space(asoc, chunk,
    	if (*errp) {
    		sctp_init_cause(*errp, SCTP_ERROR_UNKNOWN_PARAM,
    When we allocate an error chunk, we assume that the worst case scenario requires
    that we have chunk_hdr->length data allocated, which would be correct nominally,
    given that we call sctp_addto_chunk for the violating parameter.  Unfortunately,
    we also, in sctp_init_cause insert a sctp_errhdr_t structure into the error
    chunk, so the worst case situation in which all parameters are in violation
    requires chunk_hdr->length+(sizeof(sctp_errhdr_t)*param_count) bytes of data.
    The result of this error is that a deliberately malformed packet sent to a
    listening host can cause a remote DOS, described in CVE-2010-1173:
    I've tested the below fix and confirmed that it fixes the issue.  We move to a
    strategy whereby we allocate a fixed size error chunk and ignore errors we don't
    have space to report.  Tested by me successfully
    Signed-off-by: Neil Horman <>
    Acked-by: Vlad Yasevich <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Greg Kroah-Hartman <>
    Neil Horman committed with gregkh Apr 28, 2010
  9. ext4: Implement range_cyclic in ext4_da_writepages instead of write_c…

    commit 2acf2c2 upstream.
    With delayed allocation we lock the page in write_cache_pages() and
    try to build an in memory extent of contiguous blocks.  This is needed
    so that we can get large contiguous blocks request.  If range_cyclic
    mode is enabled, write_cache_pages() will loop back to the 0 index if
    no I/O has been done yet, and try to start writing from the beginning
    of the range.  That causes an attempt to take the page lock of lower
    index page while holding the page lock of higher index page, which can
    cause a dead lock with another writeback thread.
    The solution is to implement the range_cyclic behavior in
    ext4_da_writepages() instead.
    Signed-off-by: Aneesh Kumar K.V <>
    Signed-off-by: "Theodore Ts'o" <>
    Signed-off-by: Jayson R. King <>
    Signed-off-by: Greg Kroah-Hartman <>
    kvaneesh committed with gregkh May 28, 2010
  10. ext4: Fix file fragmentation during large file write.

    commit 22208de upstream.
    The range_cyclic writeback mode uses the address_space writeback_index
    as the start index for writeback.  With delayed allocation we were
    updating writeback_index wrongly resulting in highly fragmented file.
    This patch reduces the number of extents reduced from 4000 to 27 for a
    3GB file.
    Signed-off-by: Aneesh Kumar K.V <>
    Signed-off-by: Theodore Ts'o <>
    [ Some changed lines from the original version of this patch were dropped, since they were rolled up with another cherry-picked patch applied to 2.6.27.y earlier.]
    [ Use of wbc->no_nrwrite_index_update was dropped, since write_cache_pages_da() implies it.]
    Signed-off-by: Jayson R. King <>
    Signed-off-by: Greg Kroah-Hartman <>
    kvaneesh committed with gregkh May 28, 2010
  11. ext4: Use our own write_cache_pages()

    commit 8e48dcf upstream.
    Make a copy of write_cache_pages() for the benefit of
    ext4_da_writepages().  This allows us to simplify the code some, and
    will allow us to further customize the code in future patches.
    There are some nasty hacks in write_cache_pages(), which Linus has
    (correctly) characterized as vile.  I've just copied it into
    write_cache_pages_da(), without trying to clean those bits up lest I
    break something in the ext4's delalloc implementation, which is a bit
    fragile right now.  This will allow Dave Chinner to clean up
    write_cache_pages() in mm/page-writeback.c, without worrying about
    breaking ext4.  Eventually write_cache_pages_da() will go away when I
    rewrite ext4's delayed allocation and create a general
    ext4_writepages() which is used for all of ext4's writeback.  Until
    now this is the lowest risk way to clean up the core
    write_cache_pages() function.
    Signed-off-by: "Theodore Ts'o" <>
    Cc: Dave Chinner <>
    [ Dropped the hunks which reverted the use of no_nrwrite_index_update, since those lines weren't ever created on 2.6.27.y]
    [ Copied from 2.6.27.y's version of write_cache_pages(), plus the changes to it from patch "vfs: Add no_nrwrite_index_update writeback control flag"]
    Signed-off-by: Jayson R. King <>
    Signed-off-by: Greg Kroah-Hartman <>
    tytso committed with gregkh May 28, 2010