Skip to content
  1. Jan 30, 2015
  2. Jan 14, 2015
    • Thomas Graf's avatar
      openvswitch: packet messages need their own probe attribtue · 1ba39804
      Thomas Graf authored
      
      
      User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow
      and packet messages. This leads to an out-of-bounds access in
      ovs_packet_cmd_execute() because OVS_FLOW_ATTR_PROBE >
      OVS_PACKET_ATTR_MAX.
      
      Introduce a new OVS_PACKET_ATTR_PROBE with the same numeric value
      as OVS_FLOW_ATTR_PROBE to grow the range of accepted packet attributes
      while maintaining to be binary compatible with existing OVS binaries.
      
      Fixes: 05da5898 ("openvswitch: Add support for OVS_FLOW_ATTR_PROBE.")
      Reported-by: default avatarSander Eikelenboom <linux@eikelenboom.it>
      Tracked-down-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Reviewed-by: default avatarJesse Gross <jesse@nicira.com>
      Acked-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ba39804
    • Arnd Bergmann's avatar
      bridge: only provide proxy ARP when CONFIG_INET is enabled · d92cfdbb
      Arnd Bergmann authored
      
      
      When IPV4 support is disabled, we cannot call arp_send from
      the bridge code, which would result in a kernel link error:
      
      net/built-in.o: In function `br_handle_frame_finish':
      :(.text+0x59914): undefined reference to `arp_send'
      :(.text+0x59a50): undefined reference to `arp_tbl'
      
      This makes the newly added proxy ARP support in the bridge
      code depend on the CONFIG_INET symbol and lets the compiler
      optimize the code out to avoid the link error.
      
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 95850116 ("bridge: Add support for IEEE 802.11 Proxy ARP")
      Cc: Kyeyoon Park <kyeyoonp@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d92cfdbb
    • Jean-Francois Remy's avatar
      neighbour: fix base_reachable_time(_ms) not effective immediatly when changed · 4bf6980d
      Jean-Francois Remy authored
      
      
      When setting base_reachable_time or base_reachable_time_ms on a
      specific interface through sysctl or netlink, the reachable_time
      value is not updated.
      
      This means that neighbour entries will continue to be updated using the
      old value until it is recomputed in neigh_period_work (which
          recomputes the value every 300*HZ).
      On systems with HZ equal to 1000 for instance, it means 5mins before
      the change is effective.
      
      This patch changes this behavior by recomputing reachable_time after
      each set on base_reachable_time or base_reachable_time_ms.
      The new value will become effective the next time the neighbour's timer
      is triggered.
      
      Changes are made in two places: the netlink code for set and the sysctl
      handling code. For sysctl, I use a proc_handler. The ipv6 network
      code does provide its own handler but it already refreshes
      reachable_time correctly so it's not an issue.
      Any other user of neighbour which provide its own handlers must
      refresh reachable_time.
      
      Signed-off-by: default avatarJean-Francois Remy <jeff@melix.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4bf6980d
  3. Jan 12, 2015
    • Jon Paul Maloy's avatar
      tipc: fix bug in broadcast retransmit code · 16416779
      Jon Paul Maloy authored
      
      
      In commit 58dc55f2 ("tipc: use generic
      SKB list APIs to manage link transmission queue") we replace all list
      traversal loops with the macros skb_queue_walk() or
      skb_queue_walk_safe(). While the previous loops were based on the
      assumption that the list was NULL-terminated, the standard macros
      stop when the iterator reaches the list head, which is non-NULL.
      
      In the function bclink_retransmit_pkt() this macro replacement has
      lead to a bug. When we receive a BCAST STATE_MSG we unconditionally
      call the function bclink_retransmit_pkt(), whether there really is
      anything to retransmit or not, assuming that the sequence number
      comparisons will lead to the correct behavior. However, if the
      transmission queue is empty, or if there are no eligible buffers in
      the transmission queue, we will by mistake pass the list head pointer
      to the function tipc_link_retransmit(). Since the list head is not a
      valid sk_buff, this leads to a crash.
      
      In this commit we fix this by only calling tipc_link_retransmit()
      if we actually found eligible buffers in the transmission queue.
      
      Reviewed-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16416779
    • Christoph Jaeger's avatar
      packet: bail out of packet_snd() if L2 header creation fails · 46d2cfb1
      Christoph Jaeger authored
      
      
      Due to a misplaced parenthesis, the expression
      
        (unlikely(offset) < 0),
      
      which expands to
      
        (__builtin_expect(!!(offset), 0) < 0),
      
      never evaluates to true. Therefore, when sending packets with
      PF_PACKET/SOCK_DGRAM, packet_snd() does not abort as intended
      if the creation of the layer 2 header fails.
      
      Spotted by Coverity - CID 1259975 ("Operands don't affect result").
      
      Fixes: 9c707762 ("packet: make packet_snd fail on len smaller than l2 header")
      Signed-off-by: default avatarChristoph Jaeger <cj@linux.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      46d2cfb1
  4. Jan 08, 2015
  5. Jan 07, 2015
  6. Jan 06, 2015
    • Pablo Neira Ayuso's avatar
      netfilter: nf_tables: fix flush ruleset chain dependencies · a2f18db0
      Pablo Neira Ayuso authored
      
      
      Jumping between chains doesn't mix well with flush ruleset. Rules
      from a different chain and set elements may still refer to us.
      
      [  353.373791] ------------[ cut here ]------------
      [  353.373845] kernel BUG at net/netfilter/nf_tables_api.c:1159!
      [  353.373896] invalid opcode: 0000 [#1] SMP
      [  353.373942] Modules linked in: intel_powerclamp uas iwldvm iwlwifi
      [  353.374017] CPU: 0 PID: 6445 Comm: 31c3.nft Not tainted 3.18.0 #98
      [  353.374069] Hardware name: LENOVO 5129CTO/5129CTO, BIOS 6QET47WW (1.17 ) 07/14/2010
      [...]
      [  353.375018] Call Trace:
      [  353.375046]  [<ffffffff81964c31>] ? nf_tables_commit+0x381/0x540
      [  353.375101]  [<ffffffff81949118>] nfnetlink_rcv+0x3d8/0x4b0
      [  353.375150]  [<ffffffff81943fc5>] netlink_unicast+0x105/0x1a0
      [  353.375200]  [<ffffffff8194438e>] netlink_sendmsg+0x32e/0x790
      [  353.375253]  [<ffffffff818f398e>] sock_sendmsg+0x8e/0xc0
      [  353.375300]  [<ffffffff818f36b9>] ? move_addr_to_kernel.part.20+0x19/0x70
      [  353.375357]  [<ffffffff818f44f9>] ? move_addr_to_kernel+0x19/0x30
      [  353.375410]  [<ffffffff819016d2>] ? verify_iovec+0x42/0xd0
      [  353.375459]  [<ffffffff818f3e10>] ___sys_sendmsg+0x3f0/0x400
      [  353.375510]  [<ffffffff810615fa>] ? native_sched_clock+0x2a/0x90
      [  353.375563]  [<ffffffff81176697>] ? acct_account_cputime+0x17/0x20
      [  353.375616]  [<ffffffff8110dc78>] ? account_user_time+0x88/0xa0
      [  353.375667]  [<ffffffff818f4bbd>] __sys_sendmsg+0x3d/0x80
      [  353.375719]  [<ffffffff81b184f4>] ? int_check_syscall_exit_work+0x34/0x3d
      [  353.375776]  [<ffffffff818f4c0d>] SyS_sendmsg+0xd/0x20
      [  353.375823]  [<ffffffff81b1826d>] system_call_fastpath+0x16/0x1b
      
      Release objects in this order: rules -> sets -> chains -> tables, to
      make sure no references to chains are held anymore.
      
      Reported-by: default avatarAsbjoern Sloth Toennesen <asbjorn@asbjorn.biz>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      a2f18db0
    • Pablo Neira Ayuso's avatar
      netfilter: nfnetlink: relax strict multicast group check from netlink_bind · 62924af2
      Pablo Neira Ayuso authored
      
      
      Relax the checking that was introduced in 97840cb6 ("netfilter:
      nfnetlink: fix insufficient validation in nfnetlink_bind") when the
      subscription bitmask is used. Existing userspace code code may request
      to listen to all of the existing netlink groups by setting an all to one
      subscription group bitmask. Netlink already validates subscription via
      setsockopt() for us.
      
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      62924af2
    • Pablo Neira Ayuso's avatar
      netfilter: nfnetlink: validate nfnetlink header from batch · 9ea2aa8b
      Pablo Neira Ayuso authored
      
      
      Make sure there is enough room for the nfnetlink header in the
      netlink messages that are part of the batch. There is a similar
      check in netlink_rcv_skb().
      
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      9ea2aa8b
    • Pablo Neira Ayuso's avatar
      netfilter: conntrack: fix race between confirmation and flush · 8ca3f5e9
      Pablo Neira Ayuso authored
      Commit 5195c14c ("netfilter: conntrack: fix race in
      __nf_conntrack_confirm against get_next_corpse") aimed to resolve the
      race condition between the confirmation (packet path) and the flush
      command (from control plane). However, it introduced a crash when
      several packets race to add a new conntrack, which seems easier to
      reproduce when nf_queue is in place.
      
      Fix this race, in __nf_conntrack_confirm(), by removing the CT
      from unconfirmed list before checking the DYING bit. In case
      race occured, re-add the CT to the dying list
      
      This patch also changes the verdict from NF_ACCEPT to NF_DROP when
      we lose race. Basically, the confirmation happens for the first packet
      that we see in a flow. If you just invoked conntrack -F once (which
      should be the common case), then this is likely to be the first packet
      of the flow (unless you already called flush anytime soon in the past).
      This should be hard to trigger, but better drop this packet, otherwise
      we leave things in inconsistent state since the destination will likely
      reply to this packet, but it will find no conntrack, unless the origin
      retransmits.
      
      The change of the verdict has been discussed in:
      https://www.marc.info/?l=linux-netdev&m=141588039530056&w=2
      
      
      
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      8ca3f5e9
    • Linus Lüssing's avatar
      batman-adv: fix potential TT client + orig-node memory leak · 9d31b3ce
      Linus Lüssing authored
      
      
      This patch fixes a potential memory leak which can occur once an
      originator times out. On timeout the according global translation table
      entry might not get purged correctly. Furthermore, the non purged TT
      entry will cause its orig-node to leak, too. Which additionally can lead
      to the new multicast optimization feature not kicking in because of a
      therefore bogus counter.
      
      In detail: The batadv_tt_global_entry->orig_list holds the reference to
      the orig-node. Usually this reference is released after
      BATADV_PURGE_TIMEOUT through: _batadv_purge_orig()->
      batadv_purge_orig_node()->batadv_update_route()->_batadv_update_route()->
      batadv_tt_global_del_orig() which purges this global tt entry and
      releases the reference to the orig-node.
      
      However, if between two batadv_purge_orig_node() calls the orig-node
      timeout grew to 2*BATADV_PURGE_TIMEOUT then this call path isn't
      reached. Instead the according orig-node is removed from the
      originator hash in _batadv_purge_orig(), the batadv_update_route()
      part is skipped and won't be reached anymore.
      
      Fixing the issue by moving batadv_tt_global_del_orig() out of the rcu
      callback.
      
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Acked-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      9d31b3ce
    • Linus Lüssing's avatar
      batman-adv: fix multicast counter when purging originators · a5164886
      Linus Lüssing authored
      
      
      When purging an orig_node we should only decrease counter tracking the
      number of nodes without multicast optimizations support if it was
      increased through this orig_node before.
      
      A not yet quite initialized orig_node (meaning it did not have its turn
      in the mcast-tvlv handler so far) which gets purged would not adhere to
      this and will lead to a counter imbalance.
      
      Fixing this by adding a check whether the orig_node is mcast-initalized
      before decreasing the counter in the mcast-orig_node-purging routine.
      
      Introduced by 60432d75
      ("batman-adv: Announce new capability via multicast TVLV")
      
      Reported-by: default avatarTobias Hachmer <tobias@hachmer.de>
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      a5164886
    • Linus Lüssing's avatar
      batman-adv: fix counter for multicast supporting nodes · e8829f00
      Linus Lüssing authored
      
      
      A miscounting of nodes having multicast optimizations enabled can lead
      to multicast packet loss in the following scenario:
      
      If the first OGM a node receives from another one has no multicast
      optimizations support (no multicast tvlv) then we are missing to
      increase the counter. This potentially leads to the wrong assumption
      that we could safely use multicast optimizations.
      
      Fixings this by increasing the counter if the initial OGM has the
      multicast TVLV unset, too.
      
      Introduced by 60432d75
      ("batman-adv: Announce new capability via multicast TVLV")
      
      Reported-by: default avatarTobias Hachmer <tobias@hachmer.de>
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      e8829f00
    • Martin Hundebøll's avatar
      batman-adv: fix lock class for decoding hash in network-coding.c · f44d5407
      Martin Hundebøll authored
      
      
      batadv_has_set_lock_class() is called with the wrong hash table as first
      argument (probably due to a copy-paste error), which leads to false
      positives when running with lockdep.
      
      Introduced-by: 612d2b4f
      ("batman-adv: network coding - save overheard and tx packets for decoding")
      
      Signed-off-by: default avatarMartin Hundebøll <martin@hundeboll.net>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      f44d5407
    • Linus Lüssing's avatar
      batman-adv: fix delayed foreign originator recognition · 2c667a33
      Linus Lüssing authored
      
      
      Currently it can happen that the reception of an OGM from a new
      originator is not being accepted. More precisely it can happen that
      an originator struct gets allocated and initialized
      (batadv_orig_node_new()), even the TQ gets calculated and set correctly
      (batadv_iv_ogm_calc_tq()) but still the periodic orig_node purging
      thread will decide to delete it if it has a chance to jump between
      these two function calls.
      
      This is because batadv_orig_node_new() initializes the last_seen value
      to zero and its caller (batadv_iv_ogm_orig_get()) makes it visible to
      other threads by adding it to the hash table already.
      batadv_iv_ogm_calc_tq() will set the last_seen variable to the correct,
      current time a few lines later but if the purging thread jumps in between
      that it will think that the orig_node timed out and will wrongly
      schedule it for deletion already.
      
      If the purging interval is the same as the originator interval (which is
      the default: 1 second), then this game can continue for several rounds
      until the random OGM jitter added enough difference between these
      two (in tests, two to about four rounds seemed common).
      
      Fixing this by initializing the last_seen variable of an orig_node
      to the current time before adding it to the hash table.
      
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      2c667a33
    • Simon Wunderlich's avatar
      batman-adv: fix and simplify condition when bonding should be used · 329887ad
      Simon Wunderlich authored
      
      
      The current condition actually does NOT consider bonding when the
      interface the packet came in from is the soft interface, which is the
      opposite of what it should do (and the comment describes). Fix that and
      slightly simplify the condition.
      
      Reported-by: default avatarRay Gibson <booray@gmail.com>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: default avatarAntonio Quartulli <antonio@meshcoding.com>
      329887ad
  7. Jan 05, 2015
  8. Jan 02, 2015
  9. Dec 31, 2014
  10. Dec 29, 2014
  11. Dec 27, 2014
Loading