Commits on Aug 2, 2010
  1. @gregkh

    Linux 2.6.27.49

    gregkh committed Aug 2, 2010
  2. @gregkh

    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
    clearer.
    
    Fixes: CVE-2010-2492
    
    Signed-off-by: Andre Osterhues <aosterhues@escrypt.com>
    Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Andre Osterhues committed with gregkh Jul 13, 2010
  3. @gregkh

    kbuild: Fix modpost segfault

    commit 1c93866 upstream.
    
    Alan <alan@clueserver.org> 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 <alan@clueserver.org>
    Signed-off-by: Krzysztof Hałasa <khc@pm.waw.pl>
    Tested-by: Alan <alan@clueserver.org>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Krzysztof Halasa committed with gregkh Jun 11, 2010
  4. @gregkh

    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
    IFF_MASTER
    event_dev: bond0, event: 8
    IFF_MASTER
    bond_ioctl: master=bond0, cmd=35216
    slave_dev=cac5d800:
    slave_dev->name=eth1:
    eth1: ! NETIF_F_VLAN_CHALLENGED
    event_dev: eth1, event: 8
    eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1
    event_dev: eth1, event: 1
    event_dev: eth1, event: 8
    IFF_SLAVE
    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
    IFF_MASTER
    bond0: no IPv6 routers present
    
    <<<<cable unplug>>>>
    
    eth1: link down
    event_dev: eth1, event: 4
    IFF_SLAVE
    bonding: bond0: link status definitely down for interface eth1, disabling it
    event_dev: bond0, event: 4
    IFF_MASTER
    
    <<<<cable plug>>>>
    
    eth1: link up, 100Mbps, full-duplex, lpa 0xC5E1
    event_dev: eth1, event: 4
    IFF_SLAVE
    bonding: bond0: link status definitely up for interface eth1.
    bonding: bond0: making interface eth1 the new active one.
    event_dev: eth1, event: 8
    IFF_SLAVE
    event_dev: eth1, event: 8
    IFF_SLAVE
    bonding: bond0: first active interface up!
    event_dev: bond0, event: 4
    IFF_MASTER
    ----
    
    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 <jpirko@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Jiri Pirko committed with gregkh Mar 25, 2009
  5. @gregkh

    IPoIB: Fix world-writable child interface control sysfs attributes

    commit 7a52b34 upstream.
    
    Sumeet Lahorani <sumeet.lahorani@oracle.com> 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 <ogerlitz@voltaire.com>
    Signed-off-by: Roland Dreier <rolandd@cisco.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Or Gerlitz committed with gregkh Jun 6, 2010
  6. @gregkh

    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 <djwong@us.ibm.com>
    LKML-Reference: <20100701004519.GQ15515@tux1.beaverton.ibm.com>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Darrick J. Wong committed with gregkh Jun 30, 2010
  7. @gregkh

    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 <djwong@us.ibm.com>
    Acked-by: Muli Ben-Yehuda <muli@il.ibm.com>
    Cc: Corinna Schultz <cschultz@linux.vnet.ibm.com>
    LKML-Reference: <20100624212647.GI15515@tux1.beaverton.ibm.com>
    [ v2: Fixed build bug, added back PHBS_PER_CALGARY == 4 ]
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Darrick J. Wong committed with gregkh Jun 24, 2010
  8. @bwhacks @gregkh

    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
    them.
    
    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 <ben@decadent.org.uk>
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    bwhacks committed with gregkh Mar 24, 2010
  9. @JuliaLawall @gregkh

    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: (http://coccinelle.lip6.fr/)
    
    // <smpl>
    @free@
    expression E;
    position p;
    @@
    kfree@p(E)
    
    @@
    expression free.E, subE<=free.E, E1;
    position free.p;
    @@
    
      kfree@p(E)
      ...
    (
      subE = E1
    |
    * E
    )
    // </smpl>
    
    Signed-off-by: Julia Lawall <julia@diku.dk>
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    JuliaLawall committed with gregkh May 15, 2010
  10. @gregkh

    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 <eric.dumazet@gmail.com>
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Eric Dumazet committed with gregkh Jul 2, 2010
  11. @gregkh

    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 <tim.gardner@canonical.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Tim Gardner committed with gregkh Jun 8, 2010
  12. @gregkh

    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
    <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=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 <mikpe@it.uu.se>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Mikael Pettersson committed with gregkh Jul 20, 2010
  13. @philips @gregkh

    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
    sky2_phy_reinit.
    
    Signed-off-by: Brandon Philips <bphilips@suse.de>
    Tested-by: Brandon Philips <bphilips@suse.de>
    Cc: stable@kernel.org
    Tested-by: Mike McCormack <mikem@ring3k.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    philips committed with gregkh Jun 16, 2010
  14. @ffainelli @gregkh

    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 <florian@openwrt.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    ffainelli committed with gregkh Jun 20, 2010
  15. @gregkh

    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
    mm/filemap.c.
    
    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 <jlayton@samba.org>
    Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Suresh Jayaraman committed with gregkh Mar 31, 2010
  16. @jtlayton @gregkh

    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 <gdeschne@redhat.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    jtlayton committed with gregkh Jun 16, 2010
  17. @gregkh

    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 <khali@linux-fr.org>
    Acked-by: Huaxu Wan <huaxu.wan@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Jean Delvare committed with gregkh Jul 9, 2010
  18. @gregkh

    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 <khali@linux-fr.org>
    Acked-by: Huaxu Wan <huaxu.wan@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Jean Delvare committed with gregkh Jul 9, 2010
Commits on Jul 5, 2010
  1. @gregkh

    Linux 2.6.27.48

    gregkh committed Jul 5, 2010
  2. @gregkh

    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 <yjwei@cn.fujitsu.com>
    Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Wei Yongjun committed with gregkh May 17, 2010
  3. @gregkh

    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 ***
    TIME
    
    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)
    	Stack:
    	 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/sh
    	LOOP=100000
    	USER=dummy_user
    	/bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
    	for ((i=0; i<LOOP; i++))
    	do
    		/bin/su -c "echo '$i' > /dev/null" $USER
    	done
    	(( add == 1 )) && /usr/sbin/userdel -r $USER
    	exit
    
    Note that the nominated user must not be in use.
    
    An alternative way of testing this may be:
    
    	for ((i=0; i<100000; i++))
    	do
    		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 <toshi.okajima@jp.fujitsu.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Tested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
    Acked-by: Serge Hallyn <serue@us.ibm.com>
    Signed-off-by: James Morris <jmorris@namei.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Toshiyuki Okajima committed with gregkh Apr 30, 2010
  4. @error27 @gregkh

    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 <error27@gmail.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: James Morris <jmorris@namei.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    error27 committed with gregkh May 17, 2010
  5. @gregkh

    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 <deller@gmx.de>
    Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Helge Deller committed with gregkh May 3, 2010
  6. @gregkh

    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 <nhorman@tuxdriver.com>
    CC: Allan Stephens <allan.stephens@windriver.com>
    CC: David S. Miller <davem@davemloft.net>
    CC: tipc-discussion@lists.sourceforge.net
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Neil Horman committed with gregkh Mar 3, 2010
  7. @gregkh

    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 <eugene@redhat.com>
    CC: Michael Kerrisk <mtk.manpages@gmail.com>
    Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Miklos Szeredi committed with gregkh Feb 10, 2010
  8. @gregkh

    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
    
    Summary:
    
    Hey-
    	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
    e0c2947d
    <5>        00000000 00000080 df653490 00000004 de4f1ac0 de4f1ac0 00000004
    df653490
    <5>        00000001 e0c2877a 08000800 de4f1ac0 df653490 00000000 e0c29d2e
    00000004
    <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,
    					 ntohs(chunk->chunk_hdr->length));
    
    	if (*errp) {
    		sctp_init_cause(*errp, SCTP_ERROR_UNKNOWN_PARAM,
    				 WORD_ROUND(ntohs(param.p->length)));
    		sctp_addto_chunk(*errp,
    			WORD_ROUND(ntohs(param.p->length)),
    				  param.v);
    
    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:
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=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 <nhorman@tuxdriver.com>
    Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Neil Horman committed with gregkh Apr 28, 2010
  9. @kvaneesh @gregkh

    ext4: Implement range_cyclic in ext4_da_writepages instead of write_c…

    …ache_pages
    
    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.
    
    http://bugzilla.kernel.org/show_bug.cgi?id=12579
    
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Jayson R. King <dev@jaysonking.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    kvaneesh committed with gregkh May 28, 2010
  10. @kvaneesh @gregkh

    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 <aneesh.kumar@linux.vnet.ibm.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    [dev@jaysonking.com: 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.]
    [dev@jaysonking.com: Use of wbc->no_nrwrite_index_update was dropped, since write_cache_pages_da() implies it.]
    Signed-off-by: Jayson R. King <dev@jaysonking.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    kvaneesh committed with gregkh May 28, 2010
  11. @tytso @gregkh

    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" <tytso@mit.edu>
    Cc: Dave Chinner <david@fromorbit.com>
    [dev@jaysonking.com: Dropped the hunks which reverted the use of no_nrwrite_index_update, since those lines weren't ever created on 2.6.27.y]
    [dev@jaysonking.com: 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 <dev@jaysonking.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    tytso committed with gregkh May 28, 2010
  12. @gregkh

    ext4: check s_log_groups_per_flex in online resize code

    commit 42007ef upstream.
    
    If groups_per_flex < 2, sbi->s_flex_groups[] doesn't get filled out,
    and every other access to this first tests s_log_groups_per_flex;
    same thing needs to happen in resize or we'll wander off into
    a null pointer when doing an online resize of the file system.
    
    Thanks to Christoph Biedl, who came up with the trivial testcase:
    
    # truncate --size 128M fsfile
    # mkfs.ext3 -F fsfile
    # tune2fs -O extents,uninit_bg,dir_index,flex_bg,huge_file,dir_nlink,extra_isize fsfile
    # e2fsck -yDf -C0 fsfile
    # truncate --size 132M fsfile
    # losetup /dev/loop0 fsfile
    # mount /dev/loop0 mnt
    # resize2fs -p /dev/loop0
    
    	https://bugzilla.kernel.org/show_bug.cgi?id=13549
    
    Reported-by: Alessandro Polverini <alex@nibbles.it>
    Test-case-by: Christoph Biedl  <bugzilla.kernel.bpeb@manchmal.in-ulm.de>
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Eric Sandeen committed with gregkh May 16, 2010
  13. @gregkh

    gconfig: fix build failure on fedora 13

    commit cbab05f upstream.
    
    Making gconfig fails on fedora 13 as the linker cannot resolve dlsym.
    
    Adding libdl to the link command fixes this.
    
    make shows this error :-
        /usr/bin/ld: scripts/kconfig/kconfig_load.o: undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
        /usr/bin/ld: note: 'dlsym@@GLIBC_2.2.5' is defined in DSO /lib64/libdl.so.2 so try adding it to the linker command line
        /lib64/libdl.so.2: could not read symbols: Invalid operation
    
    tested on x86_64 fedora 13.
    
    Signed-off-by: Richard Kennedy <richard@rsk.demon.co.uk>
    Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Richard Kennedy committed with gregkh May 27, 2010
  14. @gregkh

    ipmi: handle run_to_completion properly in deliver_recv_msg()

    commit a747c5a upstream.
    
    If run_to_completion flag is set, it means that we are running in a
    single-threaded mode, and thus no locks are held.
    
    This fixes a deadlock when IPMI notifier is being called during panic.
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Acked-by: Corey Minyard <minyard@acm.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Jiri Kosina committed with gregkh May 26, 2010
  15. @JeffMoyer @gregkh

    do_generic_file_read: clear page errors when issuing a fresh read of …

    …the page
    
    commit 91803b4 upstream.
    
    I/O errors can happen due to temporary failures, like multipath
    errors or losing network contact with the iSCSI server. Because
    of that, the VM will retry readpage on the page.
    
    However, do_generic_file_read does not clear PG_error.  This
    causes the system to be unable to actually use the data in the
    page cache page, even if the subsequent readpage completes
    successfully!
    
    The function filemap_fault has had a ClearPageError before
    readpage forever.  This patch simply adds the same to
    do_generic_file_read.
    
    Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Rik van Riel <riel@redhat.com>
    Acked-by: Larry Woodman <lwoodman@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    JeffMoyer committed with gregkh May 26, 2010
  16. @djbw @gregkh

    md: set mddev readonly flag on blkdev BLKROSET ioctl

    commit e221835 upstream.
    
    When the user sets the block device to readwrite then the mddev should
    follow suit.  Otherwise, the BUG_ON in md_write_start() will be set to
    trigger.
    
    The reverse direction, setting mddev->ro to match a set readonly
    request, can be ignored because the blkdev level readonly flag precludes
    the need to have mddev->ro set correctly.  Nevermind the fact that
    setting mddev->ro to 1 may fail if the array is in use.
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    djbw committed with gregkh May 12, 2010
  17. @neilbrown @gregkh

    md: Fix read balancing in RAID1 and RAID10 on drives > 2TB

    commit af3a2cd upstream.
    
    read_balance uses a "unsigned long" for a sector number which
    will get truncated beyond 2TB.
    This will cause read-balancing to be non-optimal, and can cause
    data to be read from the 'wrong' branch during a resync.  This has a
    very small chance of returning wrong data.
    
    Reported-by: Jordan Russell <jr-list-2010@quo.to>
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    neilbrown committed with gregkh May 8, 2010