1. 14 Sep, 2010 1 commit
    • Michael S. Tsirkin's avatar
      vhost-net: fix range checking in mrg bufs case · ee05d693
      Michael S. Tsirkin authored
      In mergeable buffer case, we use headcount, log_num
      and seg as indexes in same-size arrays, and
      we know that headcount <= seg and
      log_num equals either 0 or seg.
      
      Therefore, the right thing to do is range-check seg,
      not headcount as we do now: these will be different
      if guest chains s/g descriptors (this does not
      happen now, but we can not trust the guest).
      
      Long term, we should add BUG_ON checks to verify
      two other indexes are what we think they should be.
      Reported-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      ee05d693
  2. 10 Sep, 2010 3 commits
  3. 09 Sep, 2010 4 commits
  4. 08 Sep, 2010 5 commits
    • Jianzhao Wang's avatar
      net: blackhole route should always be recalculated · ae2688d5
      Jianzhao Wang authored
      Blackhole routes are used when xfrm_lookup() returns -EREMOTE (error
      triggered by IKE for example), hence this kind of route is always
      temporary and so we should check if a better route exists for next
      packets.
      Bug has been introduced by commit d11a4dc1.
      Signed-off-by: default avatarJianzhao Wang <jianzhao.wang@6wind.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae2688d5
    • Jarek Poplawski's avatar
      ipv4: Suppress lockdep-RCU false positive in FIB trie (3) · f6b085b6
      Jarek Poplawski authored
      Hi,
      Here is one more of these warnings and a patch below:
      
      Sep  5 23:52:33 del kernel: [46044.244833] ===================================================
      Sep  5 23:52:33 del kernel: [46044.269681] [ INFO: suspicious rcu_dereference_check() usage. ]
      Sep  5 23:52:33 del kernel: [46044.277000] ---------------------------------------------------
      Sep  5 23:52:33 del kernel: [46044.285185] net/ipv4/fib_trie.c:1756 invoked rcu_dereference_check() without protection!
      Sep  5 23:52:33 del kernel: [46044.293627]
      Sep  5 23:52:33 del kernel: [46044.293632] other info that might help us debug this:
      Sep  5 23:52:33 del kernel: [46044.293634]
      Sep  5 23:52:33 del kernel: [46044.325333]
      Sep  5 23:52:33 del kernel: [46044.325335] rcu_scheduler_active = 1, debug_locks = 0
      Sep  5 23:52:33 del kernel: [46044.348013] 1 lock held by pppd/1717:
      Sep  5 23:52:33 del kernel: [46044.357548]  #0:  (rtnl_mutex){+.+.+.}, at: [<c125dc1f>] rtnl_lock+0xf/0x20
      Sep  5 23:52:33 del kernel: [46044.367647]
      Sep  5 23:52:33 del kernel: [46044.367652] stack backtrace:
      Sep  5 23:52:33 del kernel: [46044.387429] Pid: 1717, comm: pppd Not tainted 2.6.35.4.4a #3
      Sep  5 23:52:33 del kernel: [46044.398764] Call Trace:
      Sep  5 23:52:33 del kernel: [46044.409596]  [<c12f9aba>] ? printk+0x18/0x1e
      Sep  5 23:52:33 del kernel: [46044.420761]  [<c1053969>] lockdep_rcu_dereference+0xa9/0xb0
      Sep  5 23:52:33 del kernel: [46044.432229]  [<c12b7235>] trie_firstleaf+0x65/0x70
      Sep  5 23:52:33 del kernel: [46044.443941]  [<c12b74d4>] fib_table_flush+0x14/0x170
      Sep  5 23:52:33 del kernel: [46044.455823]  [<c1033e92>] ? local_bh_enable_ip+0x62/0xd0
      Sep  5 23:52:33 del kernel: [46044.467995]  [<c12fc39f>] ? _raw_spin_unlock_bh+0x2f/0x40
      Sep  5 23:52:33 del kernel: [46044.480404]  [<c12b24d0>] ? fib_sync_down_dev+0x120/0x180
      Sep  5 23:52:33 del kernel: [46044.493025]  [<c12b069d>] fib_flush+0x2d/0x60
      Sep  5 23:52:33 del kernel: [46044.505796]  [<c12b06f5>] fib_disable_ip+0x25/0x50
      Sep  5 23:52:33 del kernel: [46044.518772]  [<c12b10d3>] fib_netdev_event+0x73/0xd0
      Sep  5 23:52:33 del kernel: [46044.531918]  [<c1048dfd>] notifier_call_chain+0x2d/0x70
      Sep  5 23:52:33 del kernel: [46044.545358]  [<c1048f0a>] raw_notifier_call_chain+0x1a/0x20
      Sep  5 23:52:33 del kernel: [46044.559092]  [<c124f687>] call_netdevice_notifiers+0x27/0x60
      Sep  5 23:52:33 del kernel: [46044.573037]  [<c124faec>] __dev_notify_flags+0x5c/0x80
      Sep  5 23:52:33 del kernel: [46044.586489]  [<c124fb47>] dev_change_flags+0x37/0x60
      Sep  5 23:52:33 del kernel: [46044.599394]  [<c12a8a8d>] devinet_ioctl+0x54d/0x630
      Sep  5 23:52:33 del kernel: [46044.612277]  [<c12aabb7>] inet_ioctl+0x97/0xc0
      Sep  5 23:52:34 del kernel: [46044.625208]  [<c123f6af>] sock_ioctl+0x6f/0x270
      Sep  5 23:52:34 del kernel: [46044.638046]  [<c109d2b0>] ? handle_mm_fault+0x420/0x6c0
      Sep  5 23:52:34 del kernel: [46044.650968]  [<c123f640>] ? sock_ioctl+0x0/0x270
      Sep  5 23:52:34 del kernel: [46044.663865]  [<c10c3188>] vfs_ioctl+0x28/0xa0
      Sep  5 23:52:34 del kernel: [46044.676556]  [<c10c38fa>] do_vfs_ioctl+0x6a/0x5c0
      Sep  5 23:52:34 del kernel: [46044.688989]  [<c1048676>] ? up_read+0x16/0x30
      Sep  5 23:52:34 del kernel: [46044.701411]  [<c1021376>] ? do_page_fault+0x1d6/0x3a0
      Sep  5 23:52:34 del kernel: [46044.714223]  [<c10b6588>] ? fget_light+0xf8/0x2f0
      Sep  5 23:52:34 del kernel: [46044.726601]  [<c1241f98>] ? sys_socketcall+0x208/0x2c0
      Sep  5 23:52:34 del kernel: [46044.739140]  [<c10c3eb3>] sys_ioctl+0x63/0x70
      Sep  5 23:52:34 del kernel: [46044.751967]  [<c12fca3d>] syscall_call+0x7/0xb
      Sep  5 23:52:34 del kernel: [46044.764734]  [<c12f0000>] ? cookie_v6_check+0x3d0/0x630
      
      -------------->
      
      This patch fixes the warning:
       ===================================================
       [ INFO: suspicious rcu_dereference_check() usage. ]
       ---------------------------------------------------
       net/ipv4/fib_trie.c:1756 invoked rcu_dereference_check() without protection!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 1, debug_locks = 0
       1 lock held by pppd/1717:
        #0:  (rtnl_mutex){+.+.+.}, at: [<c125dc1f>] rtnl_lock+0xf/0x20
      
       stack backtrace:
       Pid: 1717, comm: pppd Not tainted 2.6.35.4a #3
       Call Trace:
        [<c12f9aba>] ? printk+0x18/0x1e
        [<c1053969>] lockdep_rcu_dereference+0xa9/0xb0
        [<c12b7235>] trie_firstleaf+0x65/0x70
        [<c12b74d4>] fib_table_flush+0x14/0x170
        ...
      
      Allow trie_firstleaf() to be called either under rcu_read_lock()
      protection or with RTNL held. The same annotation is added to
      node_parent_rcu() to prevent a similar warning a bit later.
      
      Followup of commits 634a4b20 and 4eaa0e3c.
      Signed-off-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6b085b6
    • Ben Hutchings's avatar
      niu: Fix kernel buffer overflow for ETHTOOL_GRXCLSRLALL · ee9c5cfa
      Ben Hutchings authored
      niu_get_ethtool_tcam_all() assumes that its output buffer is the right
      size, and warns before returning if it is not.  However, the output
      buffer size is under user control and ETHTOOL_GRXCLSRLALL is an
      unprivileged ethtool command.  Therefore this is at least a local
      denial-of-service vulnerability.
      
      Change it to check before writing each entry and to return an error if
      the buffer is already full.
      
      Compile-tested only.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee9c5cfa
    • Julian Anastasov's avatar
      ipvs: fix active FTP · 6523ce15
      Julian Anastasov authored
      - Do not create expectation when forwarding the PORT
        command to avoid blocking the connection. The problem is that
        nf_conntrack_ftp.c:help() tries to create the same expectation later in
        POST_ROUTING and drops the packet with "dropping packet" message after
        failure in nf_ct_expect_related.
      
      - Change ip_vs_update_conntrack to alter the conntrack
        for related connections from real server. If we do not alter the reply in
        this direction the next packet from client sent to vport 20 comes as NEW
        connection. We alter it but may be some collision happens for both
        conntracks and the second conntrack gets destroyed immediately. The
        connection stucks too.
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6523ce15
    • Jarek Poplawski's avatar
      gro: Re-fix different skb headrooms · 64289c8e
      Jarek Poplawski authored
      The patch: "gro: fix different skb headrooms" in its part:
      "2) allocate a minimal skb for head of frag_list" is buggy. The copied
      skb has p->data set at the ip header at the moment, and skb_gro_offset
      is the length of ip + tcp headers. So, after the change the length of
      mac header is skipped. Later skb_set_mac_header() sets it into the
      NET_SKB_PAD area (if it's long enough) and ip header is misaligned at
      NET_SKB_PAD + NET_IP_ALIGN offset. There is no reason to assume the
      original skb was wrongly allocated, so let's copy it as it was.
      
      bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
      fixes commit: 3d3be433Reported-by: default avatarPlamen Petrov <pvp-lsts@fs.uni-ruse.bg>
      Signed-off-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Tested-by: default avatarPlamen Petrov <pvp-lsts@fs.uni-ruse.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64289c8e
  5. 07 Sep, 2010 27 commits