1. 20 May, 2009 2 commits
    • Johannes Berg's avatar
      wext: verify buffer size for SIOCSIWENCODEEXT · 88f16db7
      Johannes Berg authored
      Another design flaw in wireless extensions (is anybody
      surprised?) in the way it handles the iw_encode_ext
      structure: The structure is part of the 'extra' memory
      but contains the key length explicitly, instead of it
      just being the length of the extra buffer - size of
      the struct and using the explicit key length only for
      the get operation (which only writes it).
      
      Therefore, we have this layout:
      
      extra: +-------------------------+
             | struct iw_encode_ext  { |
             |     ...                 |
             |     u16 key_len;        |
             |     u8 key[0];          |
             | };                      |
             +-------------------------+
             | key material            |
             +-------------------------+
      
      Now, all drivers I checked use ext->key_len without
      checking that both key_len and the struct fit into the
      extra buffer that has been copied from userspace. This
      leads to a buffer overrun while reading that buffer,
      depending on the driver it may be possible to specify
      arbitrary key_len or it may need to be a proper length
      for the key algorithm specified.
      
      Thankfully, this is only exploitable by root, but root
      can actually cause a segfault or use kernel memory as
      a key (which you can even get back with siocgiwencode
      or siocgiwencodeext from the key buffer).
      
      Fix this by verifying that key_len fits into the buffer
      along with struct iw_encode_ext.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      88f16db7
    • Pavel Roskin's avatar
      ath5k: fix scanning in AR2424 · 2b611cb6
      Pavel Roskin authored
      AR5K_PHY_PLL_40MHZ_5413 should not be ORed with AR5K_PHY_MODE_RAD_RF5112
      for 5 GHz channels.
      
      The incorrect PLL value breaks scanning in the countries where 5 GHz
      channels are allowed.
      Signed-off-by: default avatarPavel Roskin <proski@gnu.org>
      Acked-by: default avatarNick Kossifidis <mickflemm@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2b611cb6
  2. 19 May, 2009 3 commits
  3. 18 May, 2009 14 commits
    • Ajit Khaparde's avatar
    • Eric Dumazet's avatar
      sch_teql: should not dereference skb after ndo_start_xmit() · c0f84d0d
      Eric Dumazet authored
      It is illegal to dereference a skb after a successful ndo_start_xmit()
      call. We must store skb length in a local variable instead.
      
      Bug was introduced in 2.6.27 by commit 0abf77e5
      (net_sched: Add accessor function for packet length for qdiscs)
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0f84d0d
    • Ilpo Järvinen's avatar
      tcp: fix MSG_PEEK race check · 77527313
      Ilpo Järvinen authored
      Commit 518a09ef (tcp: Fix recvmsg MSG_PEEK influence of
      blocking behavior) lets the loop run longer than the race check
      did previously expect, so we need to be more careful with this
      check and consider the work we have been doing.
      
      I tried my best to deal with urg hole madness too which happens
      here:
      	if (!sock_flag(sk, SOCK_URGINLINE)) {
      		++*seq;
      		...
      by using additional offset by one but I certainly have very
      little interest in testing that part.
      Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Tested-by: default avatarFrans Pop <elendil@planet.nl>
      Tested-by: default avatarIan Zimmermann <itz@buug.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      77527313
    • Wang Tinggong's avatar
    • roel kluin's avatar
      Neterion: *FIFO1_DMA_ERR set twice, should 2nd be *FIFO2_DMA_ERR? · d77dd8d2
      roel kluin authored
      FIFO1_DMA_ERR is set twice, the second should be FIFO2_DMA_ERR.
      Signed-off-by: default avatarRoel Kluin <roel.kluin@gmail.com>
      Acked-by: default avatarRam Vepa <ram.vepa@neterion.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d77dd8d2
    • Gabriel Paubert's avatar
      mv643xx_eth: fix PPC DMA breakage · eb0519b5
      Gabriel Paubert authored
      After 2.6.29, PPC no more admits passing NULL to the dev parameter of
      the DMA API. The result is a BUG followed by solid lock-up when the 
      mv643xx_eth driver brings an interface up. The following patch makes 
      the driver work on my Pegasos again; it is mostly a search and replace 
      of NULL by mp->dev->dev.parent in dma allocation/freeing/mapping/unmapping
      functions.
      Signed-off-by: default avatarGabriel Paubert <paubert@iram.es>
      Acked-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb0519b5
    • Stephen Hemminger's avatar
      bonding: fix link down handling in 802.3ad mode · 4cd6fe1c
      Stephen Hemminger authored
      One of the purposes of bonding is to allow for redundant links, and failover
      correctly if the cable is pulled. If all the members of a bonded device have
      no carrier present, the bonded device itself needs to report no carrier present
      to user space so management tools (like routing daemons) can respond.
      
      Bonding in 802.3ad mode does not work correctly for this because it incorrectly
      chooses a link that is down as a possible aggregator.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4cd6fe1c
    • David S. Miller's avatar
    • Stephen Hemminger's avatar
      bridge: fix initial packet flood if !STP · 4f0611af
      Stephen Hemminger authored
      If bridge is configured with no STP and forwarding delay of 0 (which
      is typical for virtualization) then when link starts it will flood all
      packets for the first 20 seconds.
      
      This bug was introduced by a combination of earlier changes:
        * forwarding database uses hold time of zero to indicate
          user wants to always flood packets
        * optimzation of the case of forwarding delay of 0 avoids the initial
          timer tick
      
      The fix is to just skip all the topology change detection code if
      kernel STP is not being used.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4f0611af
    • Stephen Hemminger's avatar
      bridge: relay bridge multicast pkgs if !STP · a598f6ae
      Stephen Hemminger authored
      Currently the bridge catches all STP packets; even if STP is turned
      off.  This prevents other systems (which do have STP turned on)
      from being able to detect loops in the network.
      
      With this patch, if STP is off, then any packet sent to the STP
      multicast group address is forwarded to all ports.
      
      Based on earlier patch by Joakim Tjernlund with changes
      to go through forwarding (not local chain), and optimization
      that only last octet needs to be checked.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a598f6ae
    • Ralf Baechle's avatar
      NET: Meth: Fix unsafe mix of irq and non-irq spinlocks. · a8f492c6
      Ralf Baechle authored
      Mixing of normal and irq spinlocks results in the following lockdep messages
      on bootup on IP32:
      
      [...]
      Sending DHCP requests .
      ======================================================
      [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
      2.6.30-rc5-00164-g41baeef #30
      ------------------------------------------------------
      swapper/1 [HC0[0]:SC0[1]:HE0:SE0] is trying to acquire:
       (&priv->meth_lock){+.+...}, at: [<ffffffff8026388c>] meth_tx+0x48/0x43c
      
      and this task is already holding:
       (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c
      which would create a new lock dependency:
       (_xmit_ETHER#2){+.-...} -> (&priv->meth_lock){+.+...}
      
      but this new dependency connects a SOFTIRQ-irq-safe lock:
       (_xmit_ETHER#2){+.-...}
      ... which became SOFTIRQ-irq-safe at:
        [<ffffffff80061458>] __lock_acquire+0x784/0x1a14
        [<ffffffff800627e0>] lock_acquire+0xf8/0x150
        [<ffffffff800128d0>] _spin_lock+0x30/0x44
        [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
        [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
        [<ffffffff8003da5c>] __do_softirq+0xec/0x208
        [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
        [<ffffffff8003dda0>] irq_exit+0x54/0x9c
        [<ffffffff80004420>] ret_from_irq+0x0/0x4
        [<ffffffff80004720>] r4k_wait+0x20/0x40
        [<ffffffff80015418>] cpu_idle+0x30/0x60
        [<ffffffff804cd934>] start_kernel+0x3ec/0x404
      
      to a SOFTIRQ-irq-unsafe lock:
       (&priv->meth_lock){+.+...}
      ... which became SOFTIRQ-irq-unsafe at:
      ...  [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14
        [<ffffffff800627e0>] lock_acquire+0xf8/0x150
        [<ffffffff800128d0>] _spin_lock+0x30/0x44
        [<ffffffff80263f20>] meth_reset+0x118/0x2d8
        [<ffffffff8026424c>] meth_open+0x28/0x140
        [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
        [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
        [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
        [<ffffffff80012e68>] do_one_initcall+0x58/0x170
        [<ffffffff804cd190>] kernel_init+0x98/0x104
        [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
      
      other info that might help us debug this:
      
      2 locks held by swapper/1:
       #0:  (rcu_read_lock){.+.+..}, at: [<ffffffff802c0954>] dev_queue_xmit+0x1e0/0x4b0
       #1:  (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c
      
      the SOFTIRQ-irq-safe lock's dependencies:
      -> (_xmit_ETHER#2){+.-...} ops: 0 {
         HARDIRQ-ON-W at:
                              [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                              [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                              [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                              [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                              [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                              [<ffffffff80004420>] ret_from_irq+0x0/0x4
                              [<ffffffff80004720>] r4k_wait+0x20/0x40
                              [<ffffffff80015418>] cpu_idle+0x30/0x60
                              [<ffffffff804cd934>] start_kernel+0x3ec/0x404
         IN-SOFTIRQ-W at:
                              [<ffffffff80061458>] __lock_acquire+0x784/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                              [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                              [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                              [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                              [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                              [<ffffffff80004420>] ret_from_irq+0x0/0x4
                              [<ffffffff80004720>] r4k_wait+0x20/0x40
                              [<ffffffff80015418>] cpu_idle+0x30/0x60
                              [<ffffffff804cd934>] start_kernel+0x3ec/0x404
         INITIAL USE at:
                             [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14
                             [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                             [<ffffffff800128d0>] _spin_lock+0x30/0x44
                             [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                             [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                             [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                             [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                             [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                             [<ffffffff80004420>] ret_from_irq+0x0/0x4
                             [<ffffffff80004720>] r4k_wait+0x20/0x40
                             [<ffffffff80015418>] cpu_idle+0x30/0x60
                             [<ffffffff804cd934>] start_kernel+0x3ec/0x404
       }
       ... key      at: [<ffffffff80cf93f0>] netdev_xmit_lock_key+0x8/0x1c8
      
      the SOFTIRQ-irq-unsafe lock's dependencies:
      -> (&priv->meth_lock){+.+...} ops: 0 {
         HARDIRQ-ON-W at:
                              [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                              [<ffffffff8026424c>] meth_open+0x28/0x140
                              [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                              [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                              [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                              [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                              [<ffffffff804cd190>] kernel_init+0x98/0x104
                              [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
         SOFTIRQ-ON-W at:
                              [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                              [<ffffffff8026424c>] meth_open+0x28/0x140
                              [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                              [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                              [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                              [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                              [<ffffffff804cd190>] kernel_init+0x98/0x104
                              [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
         INITIAL USE at:
                             [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14
                             [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                             [<ffffffff800128d0>] _spin_lock+0x30/0x44
                             [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                             [<ffffffff8026424c>] meth_open+0x28/0x140
                             [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                             [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                             [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                             [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                             [<ffffffff804cd190>] kernel_init+0x98/0x104
                             [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
       }
       ... key      at: [<ffffffff80cf6ce8>] __key.32424+0x0/0x8
      
      stack backtrace:
      Call Trace:
      [<ffffffff8000ed0c>] dump_stack+0x8/0x34
      [<ffffffff80060b74>] check_usage+0x470/0x4a0
      [<ffffffff80060c34>] check_irq_usage+0x90/0x130
      [<ffffffff80061f78>] __lock_acquire+0x12a4/0x1a14
      [<ffffffff800627e0>] lock_acquire+0xf8/0x150
      [<ffffffff80012a0c>] _spin_lock_irqsave+0x60/0x84
      [<ffffffff8026388c>] meth_tx+0x48/0x43c
      [<ffffffff802d3a38>] __qdisc_run+0x150/0x30c
      [<ffffffff802c0aa8>] dev_queue_xmit+0x334/0x4b0
      [<ffffffff804e7e6c>] ip_auto_config+0x8d0/0xf28
      [<ffffffff80012e68>] do_one_initcall+0x58/0x170
      [<ffffffff804cd190>] kernel_init+0x98/0x104
      [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
      
      ..... timed out!
      IP-Config: Retrying forever (NFS root)...
      Sending DHCP requests ., OK
      [...]
      
      Fixed by converting all locks to irq locks.
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Tested-by: default avatarAndrew Randrianasulu <randrik_a@yahoo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8f492c6
    • Yevgeny Petrilin's avatar
      mlx4_en: Fix not deleted napi structures · 72876a60
      Yevgeny Petrilin authored
      Napi structures are being created each time we open a port, but when
      the port is closed the napi structure is only disabled but not removed.
      This bug caused hang while removing the driver.
      Signed-off-by: default avatarYevgeny Petrilin <yevgenyp@mellanox.co.il>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72876a60
    • Chris Friesen's avatar
      ipconfig: handle case of delayed DHCP server · 2513dfb8
      Chris Friesen authored
      If a DHCP server is delayed, it's possible for the client to receive the 
      DHCPOFFER after it has already sent out a new DHCPDISCOVER message from 
      a second interface.  The client then sends out a DHCPREQUEST from the 
      second interface, but the server doesn't recognize the device and 
      rejects the request.
      
      This patch simply tracks the current device being configured and throws 
      away the OFFER if it is not intended for the current device.  A more 
      sophisticated approach would be to put the OFFER information into the 
      struct ic_device rather than storing it globally.
      Signed-off-by: default avatarChris Friesen <cfriesen@nortel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2513dfb8
    • Pavel Emelyanov's avatar
      netpoll: don't dereference NULL dev from np · 5e392739
      Pavel Emelyanov authored
      It looks like the dev in netpoll_poll can be NULL - at lease it's
      checked at the function beginning. Thus the dev->netde_ops dereference
      looks dangerous.
      Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e392739
  4. 17 May, 2009 1 commit
  5. 16 May, 2009 16 commits
  6. 15 May, 2009 4 commits