Skip to content
  1. Aug 09, 2023
    • Remi Pommarel's avatar
      batman-adv: Fix batadv_v_ogm_aggr_send memory leak · 421d467d
      Remi Pommarel authored
      When batadv_v_ogm_aggr_send is called for an inactive interface, the skb
      is silently dropped by batadv_v_ogm_send_to_if() but never freed causing
      the following memory leak:
      
        unreferenced object 0xffff00000c164800 (size 512):
          comm "kworker/u8:1", pid 2648, jiffies 4295122303 (age 97.656s)
          hex dump (first 32 bytes):
            00 80 af 09 00 00 ff ff e1 09 00 00 75 01 60 83  ............u.`.
            1f 00 00 00 b8 00 00 00 15 00 05 00 da e3 d3 64  ...............d
          backtrace:
            [<0000000007ad20f6>] __kmalloc_track_caller+0x1a8/0x310
            [<00000000d1029e55>] kmalloc_reserve.constprop.0+0x70/0x13c
            [<000000008b9d4183>] __alloc_skb+0xec/0x1fc
            [<00000000c7af5051>] __netdev_alloc_skb+0x48/0x23c
            [<00000000642ee5f5>] batadv_v_ogm_aggr_send+0x50/0x36c
            [<0000000088660bd7>] batadv_v_ogm_aggr_work+0x24/0x40
            [<0000000042fc2606>] process_one_work+0x3b0/0x610
            [<000000002f2a0b1c>] worker_thread+0xa0/0x690
            [<0000000059fae5d4>] kthread+0x1fc/0x210
            [<000000000c587d3a>] ret_from_fork+0x10/0x20
      
      Free the skb in that case to fix this leak.
      
      Cc: stable@vger.kernel.org
      Fixes: 0da00359
      
       ("batman-adv: OGMv2 - add basic infrastructure")
      Signed-off-by: default avatarRemi Pommarel <repk@triplefau.lt>
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      421d467d
  2. Aug 05, 2023
    • Remi Pommarel's avatar
      batman-adv: Fix TT global entry leak when client roamed back · d25ddb7e
      Remi Pommarel authored
      When a client roamed back to a node before it got time to destroy the
      pending local entry (i.e. within the same originator interval) the old
      global one is directly removed from hash table and left as such.
      
      But because this entry had an extra reference taken at lookup (i.e using
      batadv_tt_global_hash_find) there is no way its memory will be reclaimed
      at any time causing the following memory leak:
      
        unreferenced object 0xffff0000073c8000 (size 18560):
          comm "softirq", pid 0, jiffies 4294907738 (age 228.644s)
          hex dump (first 32 bytes):
            06 31 ac 12 c7 7a 05 00 01 00 00 00 00 00 00 00  .1...z..........
            2c ad be 08 00 80 ff ff 6c b6 be 08 00 80 ff ff  ,.......l.......
          backtrace:
            [<00000000ee6e0ffa>] kmem_cache_alloc+0x1b4/0x300
            [<000000000ff2fdbc>] batadv_tt_global_add+0x700/0xe20
            [<00000000443897c7>] _batadv_tt_update_changes+0x21c/0x790
            [<000000005dd90463>] batadv_tt_update_changes+0x3c/0x110
            [<00000000a2d7fc57>] batadv_tt_tvlv_unicast_handler_v1+0xafc/0xe10
            [<0000000011793f2a>] batadv_tvlv_containers_process+0x168/0x2b0
            [<00000000b7cbe2ef>] batadv_recv_unicast_tvlv+0xec/0x1f4
            [<0000000042aef1d8>] batadv_batman_skb_recv+0x25c/0x3a0
            [<00000000bbd8b0a2>] __netif_receive_skb_core.isra.0+0x7a8/0xe90
            [<000000004033d428>] __netif_receive_skb_one_core+0x64/0x74
            [<000000000f39a009>] __netif_receive_skb+0x48/0xe0
            [<00000000f2cd8888>] process_backlog+0x174/0x344
            [<00000000507d6564>] __napi_poll+0x58/0x1f4
            [<00000000b64ef9eb>] net_rx_action+0x504/0x590
            [<00000000056fa5e4>] _stext+0x1b8/0x418
            [<00000000878879d6>] run_ksoftirqd+0x74/0xa4
        unreferenced object 0xffff00000bae1a80 (size 56):
          comm "softirq", pid 0, jiffies 4294910888 (age 216.092s)
          hex dump (first 32 bytes):
            00 78 b1 0b 00 00 ff ff 0d 50 00 00 00 00 00 00  .x.......P......
            00 00 00 00 00 00 00 00 50 c8 3c 07 00 00 ff ff  ........P.<.....
          backtrace:
            [<00000000ee6e0ffa>] kmem_cache_alloc+0x1b4/0x300
            [<00000000d9aaa49e>] batadv_tt_global_add+0x53c/0xe20
            [<00000000443897c7>] _batadv_tt_update_changes+0x21c/0x790
            [<000000005dd90463>] batadv_tt_update_changes+0x3c/0x110
            [<00000000a2d7fc57>] batadv_tt_tvlv_unicast_handler_v1+0xafc/0xe10
            [<0000000011793f2a>] batadv_tvlv_containers_process+0x168/0x2b0
            [<00000000b7cbe2ef>] batadv_recv_unicast_tvlv+0xec/0x1f4
            [<0000000042aef1d8>] batadv_batman_skb_recv+0x25c/0x3a0
            [<00000000bbd8b0a2>] __netif_receive_skb_core.isra.0+0x7a8/0xe90
            [<000000004033d428>] __netif_receive_skb_one_core+0x64/0x74
            [<000000000f39a009>] __netif_receive_skb+0x48/0xe0
            [<00000000f2cd8888>] process_backlog+0x174/0x344
            [<00000000507d6564>] __napi_poll+0x58/0x1f4
            [<00000000b64ef9eb>] net_rx_action+0x504/0x590
            [<00000000056fa5e4>] _stext+0x1b8/0x418
            [<00000000878879d6>] run_ksoftirqd+0x74/0xa4
      
      Releasing the extra reference from batadv_tt_global_hash_find even at
      roam back when batadv_tt_global_free is called fixes this memory leak.
      
      Cc: stable@vger.kernel.org
      Fixes: 068ee6e2
      
       ("batman-adv: roaming handling mechanism redesign")
      Signed-off-by: default avatarRemi Pommarel <repk@triplefau.lt>
      Signed-off-by; Sven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      d25ddb7e
  3. Jul 28, 2023
    • Remi Pommarel's avatar
      batman-adv: Do not get eth header before batadv_check_management_packet · eac27a41
      Remi Pommarel authored
      If received skb in batadv_v_elp_packet_recv or batadv_v_ogm_packet_recv
      is either cloned or non linearized then its data buffer will be
      reallocated by batadv_check_management_packet when skb_cow or
      skb_linearize get called. Thus geting ethernet header address inside
      skb data buffer before batadv_check_management_packet had any chance to
      reallocate it could lead to the following kernel panic:
      
        Unable to handle kernel paging request at virtual address ffffff8020ab069a
        Mem abort info:
          ESR = 0x96000007
          EC = 0x25: DABT (current EL), IL = 32 bits
          SET = 0, FnV = 0
          EA = 0, S1PTW = 0
          FSC = 0x07: level 3 translation fault
        Data abort info:
          ISV = 0, ISS = 0x00000007
          CM = 0, WnR = 0
        swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000040f45000
        [ffffff8020ab069a] pgd=180000007fffa003, p4d=180000007fffa003, pud=180000007fffa003, pmd=180000007fefe003, pte=0068000020ab0706
        Internal error: Oops: 96000007 [#1] SMP
        Modules linked in: ahci_mvebu libahci_platform libahci dvb_usb_af9035 dvb_usb_dib0700 dib0070 dib7000m dibx000_common ath11k_pci ath10k_pci ath10k_core mwl8k_new nf_nat_sip nf_conntrack_sip xhci_plat_hcd xhci_hcd nf_nat_pptp nf_conntrack_pptp at24 sbsa_gwdt
        CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.15.42-00066-g3242268d425c-dirty #550
        Hardware name: A8k (DT)
        pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
        pc : batadv_is_my_mac+0x60/0xc0
        lr : batadv_v_ogm_packet_recv+0x98/0x5d0
        sp : ffffff8000183820
        x29: ffffff8000183820 x28: 0000000000000001 x27: ffffff8014f9af00
        x26: 0000000000000000 x25: 0000000000000543 x24: 0000000000000003
        x23: ffffff8020ab0580 x22: 0000000000000110 x21: ffffff80168ae880
        x20: 0000000000000000 x19: ffffff800b561000 x18: 0000000000000000
        x17: 0000000000000000 x16: 0000000000000000 x15: 00dc098924ae0032
        x14: 0f0405433e0054b0 x13: ffffffff00000080 x12: 0000004000000001
        x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
        x8 : 0000000000000000 x7 : ffffffc076dae000 x6 : ffffff8000183700
        x5 : ffffffc00955e698 x4 : ffffff80168ae000 x3 : ffffff80059cf000
        x2 : ffffff800b561000 x1 : ffffff8020ab0696 x0 : ffffff80168ae880
        Call trace:
         batadv_is_my_mac+0x60/0xc0
         batadv_v_ogm_packet_recv+0x98/0x5d0
         batadv_batman_skb_recv+0x1b8/0x244
         __netif_receive_skb_core.isra.0+0x440/0xc74
         __netif_receive_skb_one_core+0x14/0x20
         netif_receive_skb+0x68/0x140
         br_pass_frame_up+0x70/0x80
         br_handle_frame_finish+0x108/0x284
         br_handle_frame+0x190/0x250
         __netif_receive_skb_core.isra.0+0x240/0xc74
         __netif_receive_skb_list_core+0x6c/0x90
         netif_receive_skb_list_internal+0x1f4/0x310
         napi_complete_done+0x64/0x1d0
         gro_cell_poll+0x7c/0xa0
         __napi_poll+0x34/0x174
         net_rx_action+0xf8/0x2a0
         _stext+0x12c/0x2ac
         run_ksoftirqd+0x4c/0x7c
         smpboot_thread_fn+0x120/0x210
         kthread+0x140/0x150
         ret_from_fork+0x10/0x20
        Code: f9403844 eb03009f 54fffee1 f94
      
      Thus ethernet header address should only be fetched after
      batadv_check_management_packet has been called.
      
      Fixes: 0da00359
      
       ("batman-adv: OGMv2 - add basic infrastructure")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRemi Pommarel <repk@triplefau.lt>
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      eac27a41
  4. Jul 20, 2023
    • Sven Eckelmann's avatar
      batman-adv: Don't increase MTU when set by user · d8e42a2b
      Sven Eckelmann authored
      If the user set an MTU value, it usually means that there are special
      requirements for the MTU. But if an interface gots activated, the MTU was
      always recalculated and then the user set value was overwritten.
      
      The only reason why this user set value has to be overwritten, is when the
      MTU has to be decreased because batman-adv is not able to transfer packets
      with the user specified size.
      
      Fixes: c6c8fea2
      
       ("net: Add batman-adv meshing protocol")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      d8e42a2b
    • Sven Eckelmann's avatar
      batman-adv: Trigger events for auto adjusted MTU · c6a953cc
      Sven Eckelmann authored
      If an interface changes the MTU, it is expected that an NETDEV_PRECHANGEMTU
      and NETDEV_CHANGEMTU notification events is triggered. This worked fine for
      .ndo_change_mtu based changes because core networking code took care of it.
      But for auto-adjustments after hard-interfaces changes, these events were
      simply missing.
      
      Due to this problem, non-batman-adv components weren't aware of MTU changes
      and thus couldn't perform their own tasks correctly.
      
      Fixes: c6c8fea2
      
       ("net: Add batman-adv meshing protocol")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      c6a953cc
  5. Jul 10, 2023
  6. Jul 09, 2023