1. 23 Nov, 2021 11 commits
    • Alex Elder's avatar
      net: ipa: separate disabling setup from modem stop · 8afc7e47
      Alex Elder authored
      The IPA setup_complete flag is set at the end of ipa_setup(), when
      the setup phase of initialization has completed successfully.  This
      occurs as part of driver probe processing, or (if "modem-init" is
      specified in the DTS file) it is triggered by the "ipa-setup-ready"
      SMP2P interrupt generated by the modem.
      
      In the latter case, it's possible for driver shutdown (or remove) to
      begin while setup processing is underway, and this can't be allowed.
      The problem is that the setup_complete flag is not adequate to signal
      that setup is underway.
      
      If setup_complete is set, it will never be un-set, so that case is
      not a problem.  But if setup_complete is false, there's a chance
      setup is underway.
      
      Because setup is triggered by an interrupt on a "modem-init" system,
      there is a simple way to ensure the value of setup_complete is safe
      to read.  The threaded handler--if it is executing--will complete as
      part of a request to disable the "ipa-modem-ready" interrupt.  This
      means that ipa_setup() (which is called from the handler) will run
      to completion if it was underway, or will never be called otherwise.
      
      The request to disable the "ipa-setup-ready" interrupt is currently
      made within ipa_modem_stop().  Instead, disable the interrupt
      outside that function in the two places it's called.  In the case of
      ipa_remove(), this ensures the setup_complete flag is safe to read
      before we read it.
      
      Rename ipa_smp2p_disable() to be ipa_smp2p_irq_disable_setup(), to be
      more specific about its effect.
      
      Fixes: 530f9216 ("soc: qcom: ipa: AP/modem communications")
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8afc7e47
    • Alex Elder's avatar
      net: ipa: directly disable ipa-setup-ready interrupt · 33a15310
      Alex Elder authored
      We currently maintain a "disabled" Boolean flag to determine whether
      the "ipa-setup-ready" SMP2P IRQ handler does anything.  That flag
      must be accessed under protection of a mutex.
      
      Instead, disable the SMP2P interrupt when requested, which prevents
      the interrupt handler from ever being called.  More importantly, it
      synchronizes a thread disabling the interrupt with the completion of
      the interrupt handler in case they run concurrently.
      
      Use the IPA setup_complete flag rather than the disabled flag in the
      handler to determine whether to ignore any interrupts arriving after
      the first.
      
      Rename the "disabled" flag to be "setup_disabled", to be specific
      about its purpose.
      
      Fixes: 530f9216 ("soc: qcom: ipa: AP/modem communications")
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33a15310
    • David S. Miller's avatar
      Merge branch 'mlxsw-fixes' · bd08ee23
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Two small fixes
      
      Patch #1 fixes a recent regression that prevents the driver from loading
      with old firmware versions.
      
      Patch #2 protects the driver from a NULL pointer dereference when
      working on top of a buggy firmware. This was never observed in an actual
      system, only on top of an emulator during development.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bd08ee23
    • Amit Cohen's avatar
      mlxsw: spectrum: Protect driver from buggy firmware · 63b08b1f
      Amit Cohen authored
      When processing port up/down events generated by the device's firmware,
      the driver protects itself from events reported for non-existent local
      ports, but not the CPU port (local port 0), which exists, but lacks a
      netdev.
      
      This can result in a NULL pointer dereference when calling
      netif_carrier_{on,off}().
      
      Fix this by bailing early when processing an event reported for the CPU
      port. Problem was only observed when running on top of a buggy emulator.
      
      Fixes: 28b1987e ("mlxsw: spectrum: Register CPU port with devlink")
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      63b08b1f
    • Danielle Ratson's avatar
      mlxsw: spectrum: Allow driver to load with old firmware versions · ce4995bc
      Danielle Ratson authored
      The driver fails to load with old firmware versions that cannot report
      the maximum number of RIF MAC profiles [1].
      
      Fix this by defaulting to a maximum of a single profile in such
      situations, as multiple profiles are not supported by old firmware
      versions.
      
      [1]
      mlxsw_spectrum 0000:03:00.0: cannot register bus device
      mlxsw_spectrum: probe of 0000:03:00.0 failed with error -5
      
      Fixes: 1c375ffb ("mlxsw: spectrum_router: Expose RIF MAC profiles to devlink resource")
      Signed-off-by: default avatarDanielle Ratson <danieller@nvidia.com>
      Reported-by: default avatarVadim Pasternak <vadimp@nvidia.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce4995bc
    • David S. Miller's avatar
      Merge branch 'smc-fixes' · 5789d04b
      David S. Miller authored
      Tony Lu says:
      
      ====================
      smc: Fixes for closing process and minor cleanup
      
      Patch 1 is a minor cleanup for local struct sock variables.
      
      Patch 2 ensures the active closing side enters TIME_WAIT.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5789d04b
    • Tony Lu's avatar
      net/smc: Ensure the active closing peer first closes clcsock · 606a63c9
      Tony Lu authored
      The side that actively closed socket, it's clcsock doesn't enter
      TIME_WAIT state, but the passive side does it. It should show the same
      behavior as TCP sockets.
      
      Consider this, when client actively closes the socket, the clcsock in
      server enters TIME_WAIT state, which means the address is occupied and
      won't be reused before TIME_WAIT dismissing. If we restarted server, the
      service would be unavailable for a long time.
      
      To solve this issue, shutdown the clcsock in [A], perform the TCP active
      close progress first, before the passive closed side closing it. So that
      the actively closed side enters TIME_WAIT, not the passive one.
      
      Client                                            |  Server
      close() // client actively close                  |
        smc_release()                                   |
            smc_close_active() // PEERCLOSEWAIT1        |
                smc_close_final() // abort or closed = 1|
                    smc_cdc_get_slot_and_msg_send()     |
                [A]                                     |
                                                        |smc_cdc_msg_recv_action() // ACTIVE
                                                        |  queue_work(smc_close_wq, &conn->close_work)
                                                        |    smc_close_passive_work() // PROCESSABORT or APPCLOSEWAIT1
                                                        |      smc_close_passive_abort_received() // only in abort
                                                        |
                                                        |close() // server recv zero, close
                                                        |  smc_release() // PROCESSABORT or APPCLOSEWAIT1
                                                        |    smc_close_active()
                                                        |      smc_close_abort() or smc_close_final() // CLOSED
                                                        |        smc_cdc_get_slot_and_msg_send() // abort or closed = 1
      smc_cdc_msg_recv_action()                         |    smc_clcsock_release()
        queue_work(smc_close_wq, &conn->close_work)     |      sock_release(tcp) // actively close clc, enter TIME_WAIT
          smc_close_passive_work() // PEERCLOSEWAIT1    |    smc_conn_free()
            smc_close_passive_abort_received() // CLOSED|
            smc_conn_free()                             |
            smc_clcsock_release()                       |
              sock_release(tcp) // passive close clc    |
      
      Link: https://www.spinics.net/lists/netdev/msg780407.html
      Fixes: b38d7324 ("smc: socket closing and linkgroup cleanup")
      Signed-off-by: default avatarTony Lu <tonylu@linux.alibaba.com>
      Reviewed-by: default avatarWen Gu <guwen@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      606a63c9
    • Tony Lu's avatar
      net/smc: Clean up local struct sock variables · 45c3ff7a
      Tony Lu authored
      There remains some variables to replace with local struct sock. So clean
      them up all.
      
      Fixes: 3163c507 ("net/smc: use local struct sock variables consistently")
      Signed-off-by: default avatarTony Lu <tonylu@linux.alibaba.com>
      Reviewed-by: default avatarWen Gu <guwen@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      45c3ff7a
    • Nikolay Aleksandrov's avatar
      net: nexthop: fix null pointer dereference when IPv6 is not enabled · 1c743127
      Nikolay Aleksandrov authored
      When we try to add an IPv6 nexthop and IPv6 is not enabled
      (!CONFIG_IPV6) we'll hit a NULL pointer dereference[1] in the error path
      of nh_create_ipv6() due to calling ipv6_stub->fib6_nh_release. The bug
      has been present since the beginning of IPv6 nexthop gateway support.
      Commit 1aefd3de ("ipv6: Add fib6_nh_init and release to stubs") tells
      us that only fib6_nh_init has a dummy stub because fib6_nh_release should
      not be called if fib6_nh_init returns an error, but the commit below added
      a call to ipv6_stub->fib6_nh_release in its error path. To fix it return
      the dummy stub's -EAFNOSUPPORT error directly without calling
      ipv6_stub->fib6_nh_release in nh_create_ipv6()'s error path.
      
      [1]
       Output is a bit truncated, but it clearly shows the error.
       BUG: kernel NULL pointer dereference, address: 000000000000000000
       #PF: supervisor instruction fetch in kernel modede
       #PF: error_code(0x0010) - not-present pagege
       PGD 0 P4D 0
       Oops: 0010 [#1] PREEMPT SMP NOPTI
       CPU: 4 PID: 638 Comm: ip Kdump: loaded Not tainted 5.16.0-rc1+ #446
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014
       RIP: 0010:0x0
       Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
       RSP: 0018:ffff888109f5b8f0 EFLAGS: 00010286^Ac
       RAX: 0000000000000000 RBX: ffff888109f5ba28 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8881008a2860
       RBP: ffff888109f5b9d8 R08: 0000000000000000 R09: 0000000000000000
       R10: ffff888109f5b978 R11: ffff888109f5b948 R12: 00000000ffffff9f
       R13: ffff8881008a2a80 R14: ffff8881008a2860 R15: ffff8881008a2840
       FS:  00007f98de70f100(0000) GS:ffff88822bf00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: ffffffffffffffd6 CR3: 0000000100efc000 CR4: 00000000000006e0
       Call Trace:
        <TASK>
        nh_create_ipv6+0xed/0x10c
        rtm_new_nexthop+0x6d7/0x13f3
        ? check_preemption_disabled+0x3d/0xf2
        ? lock_is_held_type+0xbe/0xfd
        rtnetlink_rcv_msg+0x23f/0x26a
        ? check_preemption_disabled+0x3d/0xf2
        ? rtnl_calcit.isra.0+0x147/0x147
        netlink_rcv_skb+0x61/0xb2
        netlink_unicast+0x100/0x187
        netlink_sendmsg+0x37f/0x3a0
        ? netlink_unicast+0x187/0x187
        sock_sendmsg_nosec+0x67/0x9b
        ____sys_sendmsg+0x19d/0x1f9
        ? copy_msghdr_from_user+0x4c/0x5e
        ? rcu_read_lock_any_held+0x2a/0x78
        ___sys_sendmsg+0x6c/0x8c
        ? asm_sysvec_apic_timer_interrupt+0x12/0x20
        ? lockdep_hardirqs_on+0xd9/0x102
        ? sockfd_lookup_light+0x69/0x99
        __sys_sendmsg+0x50/0x6e
        do_syscall_64+0xcb/0xf2
        entry_SYSCALL_64_after_hwframe+0x44/0xae
       RIP: 0033:0x7f98dea28914
       Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41 89 d4 55 48 89 f5 53
       RSP: 002b:00007fff859f5e68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e2e
       RAX: ffffffffffffffda RBX: 00000000619cb810 RCX: 00007f98dea28914
       RDX: 0000000000000000 RSI: 00007fff859f5ed0 RDI: 0000000000000003
       RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000008
       R10: fffffffffffffce6 R11: 0000000000000246 R12: 0000000000000001
       R13: 000055c0097ae520 R14: 000055c0097957fd R15: 00007fff859f63a0
       </TASK>
       Modules linked in: bridge stp llc bonding virtio_net
      
      Cc: stable@vger.kernel.org
      Fixes: 53010f99 ("nexthop: Add support for IPv6 gateways")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c743127
    • Huang Pei's avatar
      slip: fix macro redefine warning · e5b40668
      Huang Pei authored
      MIPS/IA64 define END as assembly function ending, which conflict
      with END definition in slip.h, just undef it at first
      
      Reported-by: lkp@intel.com
      Signed-off-by: default avatarHuang Pei <huangpei@loongson.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e5b40668
    • Huang Pei's avatar
      hamradio: fix macro redefine warning · 16517829
      Huang Pei authored
      MIPS/IA64 define END as assembly function ending, which conflict
      with END definition in mkiss.c, just undef it at first
      
      Reported-by: lkp@intel.com
      Signed-off-by: default avatarHuang Pei <huangpei@loongson.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16517829
  2. 22 Nov, 2021 16 commits
    • David S. Miller's avatar
      Merge branch 'nh-group-refcnt' · 03a000bf
      David S. Miller authored
      Nikolay Aleksandrov says:
      
      ====================
      net: nexthop: fix refcount issues when replacing groups
      
      This set fixes a refcount bug when replacing nexthop groups and
      modifying routes. It is complex because the objects look valid when
      debugging memory dumps, but we end up having refcount dependency between
      unlinked objects which can never be released, so in turn they cannot
      free their resources and refcounts. The problem happens because we can
      have stale IPv6 per-cpu dsts in nexthops which were removed from a
      group. Even though the IPv6 gen is bumped, the dsts won't be released
      until traffic passes through them or the nexthop is freed, that can take
      arbitrarily long time, and even worse we can create a scenario[1] where it
      can never be released. The fix is to release the IPv6 per-cpu dsts of
      replaced nexthops after an RCU grace period so no new ones can be
      created. To do that we add a new IPv6 stub - fib6_nh_release_dsts, which
      is used by the nexthop code only when necessary. We can further optimize
      group replacement, but that is more suited for net-next as these patches
      would have to be backported to stable releases.
      
      v2: patch 02: update commit msg
          patch 03: check for mausezahn before testing and make a few comments
                    more verbose
      
      [1]
      This info is also present in patch 02's commit message.
      Initial state:
       $ ip nexthop list
        id 200 via 2002:db8::2 dev bridge.10 scope link onlink
        id 201 via 2002:db8::3 dev bridge scope link onlink
        id 203 group 201/200
       $ ip -6 route
        2001:db8::10 nhid 203 metric 1024 pref medium
           nexthop via 2002:db8::3 dev bridge weight 1 onlink
           nexthop via 2002:db8::2 dev bridge.10 weight 1 onlink
      
      Create rt6_info through one of the multipath legs, e.g.:
       $ taskset -a -c 1  ./pkt_inj 24 bridge.10 2001:db8::10
       (pkt_inj is just a custom packet generator, nothing special)
      
      Then remove that leg from the group by replace (let's assume it is id
      200 in this case):
       $ ip nexthop replace id 203 group 201
      
      Now remove the IPv6 route:
       $ ip -6 route del 2001:db8::10/128
      
      The route won't be really deleted due to the stale rt6_info holding 1
      refcnt in nexthop id 200.
      At this point we have the following reference count dependency:
       (deleted) IPv6 route holds 1 reference over nhid 203
       nh 203 holds 1 ref over id 201
       nh 200 holds 1 ref over the net device and the route due to the stale
       rt6_info
      
      Now to create circular dependency between nh 200 and the IPv6 route, and
      also to get a reference over nh 200, restore nhid 200 in the group:
       $ ip nexthop replace id 203 group 201/200
      
      And now we have a permanent circular dependncy because nhid 203 holds a
      reference over nh 200 and 201, but the route holds a ref over nh 203 and
      is deleted.
      
      To trigger the bug just delete the group (nhid 203):
       $ ip nexthop del id 203
      
      It won't really be deleted due to the IPv6 route dependency, and now we
      have 2 unlinked and deleted objects that reference each other: the group
      and the IPv6 route. Since the group drops the reference it holds over its
      entries at free time (i.e. its own refcount needs to drop to 0) that will
      never happen and we get a permanent ref on them, since one of the entries
      holds a reference over the IPv6 route it will also never be released.
      
      At this point the dependencies are:
       (deleted, only unlinked) IPv6 route holds reference over group nh 203
       (deleted, only unlinked) group nh 203 holds reference over nh 201 and 200
       nh 200 holds 1 ref over the net device and the route due to the stale
       rt6_info
      
      This is the last point where it can be fixed by running traffic through
      nh 200, and specifically through the same CPU so the rt6_info (dst) will
      get released due to the IPv6 genid, that in turn will free the IPv6
      route, which in turn will free the ref count over the group nh 203.
      
      If nh 200 is deleted at this point, it will never be released due to the
      ref from the unlinked group 203, it will only be unlinked:
       $ ip nexthop del id 200
       $ ip nexthop
       $
      
      Now we can never release that stale rt6_info, we have IPv6 route with ref
      over group nh 203, group nh 203 with ref over nh 200 and 201, nh 200 with
      rt6_info (dst) with ref over the net device and the IPv6 route. All of
      these objects are only unlinked, and cannot be released, thus they can't
      release their ref counts.
      
       Message from syslogd@dev at Nov 19 14:04:10 ...
        kernel:[73501.828730] unregister_netdevice: waiting for bridge.10 to become free. Usage count = 3
       Message from syslogd@dev at Nov 19 14:04:20 ...
        kernel:[73512.068811] unregister_netdevice: waiting for bridge.10 to become free. Usage count = 3
      
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03a000bf
    • Nikolay Aleksandrov's avatar
      selftests: net: fib_nexthops: add test for group refcount imbalance bug · 02ebe49a
      Nikolay Aleksandrov authored
      The new selftest runs a sequence which causes circular refcount
      dependency between deleted objects which cannot be released and results
      in a netdevice refcount imbalance.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      02ebe49a
    • Nikolay Aleksandrov's avatar
      net: nexthop: release IPv6 per-cpu dsts when replacing a nexthop group · 1005f19b
      Nikolay Aleksandrov authored
      When replacing a nexthop group, we must release the IPv6 per-cpu dsts of
      the removed nexthop entries after an RCU grace period because they
      contain references to the nexthop's net device and to the fib6 info.
      With specific series of events[1] we can reach net device refcount
      imbalance which is unrecoverable. IPv4 is not affected because dsts
      don't take a refcount on the route.
      
      [1]
       $ ip nexthop list
        id 200 via 2002:db8::2 dev bridge.10 scope link onlink
        id 201 via 2002:db8::3 dev bridge scope link onlink
        id 203 group 201/200
       $ ip -6 route
        2001:db8::10 nhid 203 metric 1024 pref medium
           nexthop via 2002:db8::3 dev bridge weight 1 onlink
           nexthop via 2002:db8::2 dev bridge.10 weight 1 onlink
      
      Create rt6_info through one of the multipath legs, e.g.:
       $ taskset -a -c 1  ./pkt_inj 24 bridge.10 2001:db8::10
       (pkt_inj is just a custom packet generator, nothing special)
      
      Then remove that leg from the group by replace (let's assume it is id
      200 in this case):
       $ ip nexthop replace id 203 group 201
      
      Now remove the IPv6 route:
       $ ip -6 route del 2001:db8::10/128
      
      The route won't be really deleted due to the stale rt6_info holding 1
      refcnt in nexthop id 200.
      At this point we have the following reference count dependency:
       (deleted) IPv6 route holds 1 reference over nhid 203
       nh 203 holds 1 ref over id 201
       nh 200 holds 1 ref over the net device and the route due to the stale
       rt6_info
      
      Now to create circular dependency between nh 200 and the IPv6 route, and
      also to get a reference over nh 200, restore nhid 200 in the group:
       $ ip nexthop replace id 203 group 201/200
      
      And now we have a permanent circular dependncy because nhid 203 holds a
      reference over nh 200 and 201, but the route holds a ref over nh 203 and
      is deleted.
      
      To trigger the bug just delete the group (nhid 203):
       $ ip nexthop del id 203
      
      It won't really be deleted due to the IPv6 route dependency, and now we
      have 2 unlinked and deleted objects that reference each other: the group
      and the IPv6 route. Since the group drops the reference it holds over its
      entries at free time (i.e. its own refcount needs to drop to 0) that will
      never happen and we get a permanent ref on them, since one of the entries
      holds a reference over the IPv6 route it will also never be released.
      
      At this point the dependencies are:
       (deleted, only unlinked) IPv6 route holds reference over group nh 203
       (deleted, only unlinked) group nh 203 holds reference over nh 201 and 200
       nh 200 holds 1 ref over the net device and the route due to the stale
       rt6_info
      
      This is the last point where it can be fixed by running traffic through
      nh 200, and specifically through the same CPU so the rt6_info (dst) will
      get released due to the IPv6 genid, that in turn will free the IPv6
      route, which in turn will free the ref count over the group nh 203.
      
      If nh 200 is deleted at this point, it will never be released due to the
      ref from the unlinked group 203, it will only be unlinked:
       $ ip nexthop del id 200
       $ ip nexthop
       $
      
      Now we can never release that stale rt6_info, we have IPv6 route with ref
      over group nh 203, group nh 203 with ref over nh 200 and 201, nh 200 with
      rt6_info (dst) with ref over the net device and the IPv6 route. All of
      these objects are only unlinked, and cannot be released, thus they can't
      release their ref counts.
      
       Message from syslogd@dev at Nov 19 14:04:10 ...
        kernel:[73501.828730] unregister_netdevice: waiting for bridge.10 to become free. Usage count = 3
       Message from syslogd@dev at Nov 19 14:04:20 ...
        kernel:[73512.068811] unregister_netdevice: waiting for bridge.10 to become free. Usage count = 3
      
      Fixes: 7bf4796d ("nexthops: add support for replace")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1005f19b
    • Nikolay Aleksandrov's avatar
      net: ipv6: add fib6_nh_release_dsts stub · 8837cbbf
      Nikolay Aleksandrov authored
      We need a way to release a fib6_nh's per-cpu dsts when replacing
      nexthops otherwise we can end up with stale per-cpu dsts which hold net
      device references, so add a new IPv6 stub called fib6_nh_release_dsts.
      It must be used after an RCU grace period, so no new dsts can be created
      through a group's nexthop entry.
      Similar to fib6_nh_release it shouldn't be used if fib6_nh_init has failed
      so it doesn't need a dummy stub when IPv6 is not enabled.
      
      Fixes: 7bf4796d ("nexthops: add support for replace")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8837cbbf
    • Daniel Borkmann's avatar
      net, neigh: Fix crash in v6 module initialization error path · 4177d5b0
      Daniel Borkmann authored
      When IPv6 module gets initialized, but it's hitting an error in inet6_init()
      where it then needs to undo all the prior initialization work, it also might
      do a call to ndisc_cleanup() which then calls neigh_table_clear(). In there
      is a missing timer cancellation of the table's managed_work item.
      
      The kernel test robot explicitly triggered this error path and caused a UAF
      crash similar to the below:
      
        [...]
        [   28.833183][    C0] BUG: unable to handle page fault for address: f7a43288
        [   28.833973][    C0] #PF: supervisor write access in kernel mode
        [   28.834660][    C0] #PF: error_code(0x0002) - not-present page
        [   28.835319][    C0] *pde = 06b2c067 *pte = 00000000
        [   28.835853][    C0] Oops: 0002 [#1] PREEMPT
        [   28.836367][    C0] CPU: 0 PID: 303 Comm: sed Not tainted 5.16.0-rc1-00233-g83ff5faa0d3b #7
        [   28.837293][    C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1 04/01/2014
        [   28.838338][    C0] EIP: __run_timers.constprop.0+0x82/0x440
        [...]
        [   28.845607][    C0] Call Trace:
        [   28.845942][    C0]  <SOFTIRQ>
        [   28.846333][    C0]  ? check_preemption_disabled.isra.0+0x2a/0x80
        [   28.846975][    C0]  ? __this_cpu_preempt_check+0x8/0xa
        [   28.847570][    C0]  run_timer_softirq+0xd/0x40
        [   28.848050][    C0]  __do_softirq+0xf5/0x576
        [   28.848547][    C0]  ? __softirqentry_text_start+0x10/0x10
        [   28.849127][    C0]  do_softirq_own_stack+0x2b/0x40
        [   28.849749][    C0]  </SOFTIRQ>
        [   28.850087][    C0]  irq_exit_rcu+0x7d/0xc0
        [   28.850587][    C0]  common_interrupt+0x2a/0x40
        [   28.851068][    C0]  asm_common_interrupt+0x119/0x120
        [...]
      
      Note that IPv6 module cannot be unloaded as per 8ce44061 ("ipv6: do not
      allow ipv6 module to be removed") hence this can only be seen during module
      initialization error. Tested with kernel test robot's reproducer.
      
      Fixes: 7482e384 ("net, neigh: Add NTF_MANAGED flag for managed neighbor entries")
      Reported-by: default avatarkernel test robot <oliver.sang@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Li Zhijian <zhijianx.li@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4177d5b0
    • Arnd Bergmann's avatar
      nixge: fix mac address error handling again · a68229ca
      Arnd Bergmann authored
      The change to eth_hw_addr_set() caused gcc to correctly spot a
      bug that was introduced in an earlier incorrect fix:
      
      In file included from include/linux/etherdevice.h:21,
                       from drivers/net/ethernet/ni/nixge.c:7:
      In function '__dev_addr_set',
          inlined from 'eth_hw_addr_set' at include/linux/etherdevice.h:319:2,
          inlined from 'nixge_probe' at drivers/net/ethernet/ni/nixge.c:1286:3:
      include/linux/netdevice.h:4648:9: error: 'memcpy' reading 6 bytes from a region of size 0 [-Werror=stringop-overread]
       4648 |         memcpy(dev->dev_addr, addr, len);
            |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      As nixge_get_nvmem_address() can return either NULL or an error
      pointer, the NULL check is wrong, and we can end up reading from
      ERR_PTR(-EOPNOTSUPP), which gcc knows to contain zero readable
      bytes.
      
      Make the function always return an error pointer again but fix
      the check to match that.
      
      Fixes: f3956ebb ("ethernet: use eth_hw_addr_set() instead of ether_addr_copy()")
      Fixes: abcd3d6f ("net: nixge: Fix error path for obtaining mac address")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a68229ca
    • Wen Gu's avatar
      net/smc: Avoid warning of possible recursive locking · 7a61432d
      Wen Gu authored
      Possible recursive locking is detected by lockdep when SMC
      falls back to TCP. The corresponding warnings are as follows:
      
       ============================================
       WARNING: possible recursive locking detected
       5.16.0-rc1+ #18 Tainted: G            E
       --------------------------------------------
       wrk/1391 is trying to acquire lock:
       ffff975246c8e7d8 (&ei->socket.wq.wait){..-.}-{3:3}, at: smc_switch_to_fallback+0x109/0x250 [smc]
      
       but task is already holding lock:
       ffff975246c8f918 (&ei->socket.wq.wait){..-.}-{3:3}, at: smc_switch_to_fallback+0xfe/0x250 [smc]
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock(&ei->socket.wq.wait);
         lock(&ei->socket.wq.wait);
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
       2 locks held by wrk/1391:
        #0: ffff975246040130 (sk_lock-AF_SMC){+.+.}-{0:0}, at: smc_connect+0x43/0x150 [smc]
        #1: ffff975246c8f918 (&ei->socket.wq.wait){..-.}-{3:3}, at: smc_switch_to_fallback+0xfe/0x250 [smc]
      
       stack backtrace:
       Call Trace:
        <TASK>
        dump_stack_lvl+0x56/0x7b
        __lock_acquire+0x951/0x11f0
        lock_acquire+0x27a/0x320
        ? smc_switch_to_fallback+0x109/0x250 [smc]
        ? smc_switch_to_fallback+0xfe/0x250 [smc]
        _raw_spin_lock_irq+0x3b/0x80
        ? smc_switch_to_fallback+0x109/0x250 [smc]
        smc_switch_to_fallback+0x109/0x250 [smc]
        smc_connect_fallback+0xe/0x30 [smc]
        __smc_connect+0xcf/0x1090 [smc]
        ? mark_held_locks+0x61/0x80
        ? __local_bh_enable_ip+0x77/0xe0
        ? lockdep_hardirqs_on+0xbf/0x130
        ? smc_connect+0x12a/0x150 [smc]
        smc_connect+0x12a/0x150 [smc]
        __sys_connect+0x8a/0xc0
        ? syscall_enter_from_user_mode+0x20/0x70
        __x64_sys_connect+0x16/0x20
        do_syscall_64+0x34/0x90
        entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      The nested locking in smc_switch_to_fallback() is considered to
      possibly cause a deadlock because smc_wait->lock and clc_wait->lock
      are the same type of lock. But actually it is safe so far since
      there is no other place trying to obtain smc_wait->lock when
      clc_wait->lock is held. So the patch replaces spin_lock() with
      spin_lock_nested() to avoid false report by lockdep.
      
      Link: https://lkml.org/lkml/2021/11/19/962
      Fixes: 2153bd1e ("Transfer remaining wait queue entries during fallback")
      Reported-by: syzbot+e979d3597f48262cb4ee@syzkaller.appspotmail.com
      Signed-off-by: default avatarWen Gu <guwen@linux.alibaba.com>
      Acked-by: default avatarTony Lu <tonylu@linux.alibaba.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7a61432d
    • Michael S. Tsirkin's avatar
      vsock/virtio: suppress used length validation · f7a36b03
      Michael S. Tsirkin authored
      It turns out that vhost vsock violates the virtio spec
      by supplying the out buffer length in the used length
      (should just be the in length).
      As a result, attempts to validate the used length fail with:
      vmw_vsock_virtio_transport virtio1: tx: used len 44 is larger than in buflen 0
      
      Since vsock driver does not use the length fox tx and
      validates the length before use for rx, it is safe to
      suppress the validation in virtio core for this driver.
      Reported-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Fixes: 939779f5 ("virtio_ring: validate used buffer length")
      Cc: "Jason Wang" <jasowang@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarStefano Garzarella <sgarzare@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7a36b03
    • Nicolas Iooss's avatar
      net: ax88796c: do not receive data in pointer · f93fd0ca
      Nicolas Iooss authored
      Function axspi_read_status calls:
      
          ret = spi_write_then_read(ax_spi->spi, ax_spi->cmd_buf, 1,
                                    (u8 *)&status, 3);
      
      status is a pointer to a struct spi_status, which is 3-byte wide:
      
          struct spi_status {
              u16 isr;
              u8 status;
          };
      
      But &status is the pointer to this pointer, and spi_write_then_read does
      not dereference this parameter:
      
          int spi_write_then_read(struct spi_device *spi,
                                  const void *txbuf, unsigned n_tx,
                                  void *rxbuf, unsigned n_rx)
      
      Therefore axspi_read_status currently receive a SPI response in the
      pointer status, which overwrites 24 bits of the pointer.
      
      Thankfully, on Little-Endian systems, the pointer is only used in
      
          le16_to_cpus(&status->isr);
      
      ... which is a no-operation. So there, the overwritten pointer is not
      dereferenced. Nevertheless on Big-Endian systems, this can lead to
      dereferencing pointers after their 24 most significant bits were
      overwritten. And in all systems this leads to possible use of
      uninitialized value in functions calling spi_write_then_read which
      expect status to be initialized when the function returns.
      
      Moreover function axspi_read_status (and macro AX_READ_STATUS) do not
      seem to be used anywhere. So currently this seems to be dead code. Fix
      the issue anyway so that future code works properly when using function
      axspi_read_status.
      
      Fixes: a97c69ba ("net: ax88796c: ASIX AX88796C SPI Ethernet Adapter Driver")
      Signed-off-by: default avatarNicolas Iooss <nicolas.iooss_linux@m4x.org>
      Acked-by: default avatarŁukasz Stelmach <l.stelmach@samsung.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f93fd0ca
    • Holger Assmann's avatar
      net: stmmac: retain PTP clock time during SIOCSHWTSTAMP ioctls · a6da2bbb
      Holger Assmann authored
      Currently, when user space emits SIOCSHWTSTAMP ioctl calls such as
      enabling/disabling timestamping or changing filter settings, the driver
      reads the current CLOCK_REALTIME value and programming this into the
      NIC's hardware clock. This might be necessary during system
      initialization, but at runtime, when the PTP clock has already been
      synchronized to a grandmaster, a reset of the timestamp settings might
      result in a clock jump. Furthermore, if the clock is also controlled by
      phc2sys in automatic mode (where the UTC offset is queried from ptp4l),
      that UTC-to-TAI offset (currently 37 seconds in 2021) would be
      temporarily reset to 0, and it would take a long time for phc2sys to
      readjust so that CLOCK_REALTIME and the PHC are apart by 37 seconds
      again.
      
      To address the issue, we introduce a new function called
      stmmac_init_tstamp_counter(), which gets called during ndo_open().
      It contains the code snippet moved from stmmac_hwtstamp_set() that
      manages the time synchronization. Besides, the sub second increment
      configuration is also moved here since the related values are hardware
      dependent and runtime invariant.
      
      Furthermore, the hardware clock must be kept running even when no time
      stamping mode is selected in order to retain the synchronized time base.
      That way, timestamping can be enabled again at any time only with the
      need to compensate the clock's natural drifting.
      
      As a side effect, this patch fixes the issue that ptp_clock_info::enable
      can be called before SIOCSHWTSTAMP and the driver (which looks at
      priv->systime_flags) was not prepared to handle that ordering.
      
      Fixes: 92ba6888 ("stmmac: add the support for PTP hw clock driver")
      Reported-by: default avatarMichael Olbrich <m.olbrich@pengutronix.de>
      Signed-off-by: default avatarAhmad Fatoum <a.fatoum@pengutronix.de>
      Signed-off-by: default avatarHolger Assmann <h.assmann@pengutronix.de>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a6da2bbb
    • Diana Wang's avatar
      nfp: checking parameter process for rx-usecs/tx-usecs is invalid · 3bd6b2a8
      Diana Wang authored
      Use nn->tlv_caps.me_freq_mhz instead of nn->me_freq_mhz to check whether
      rx-usecs/tx-usecs is valid.
      
      This is because nn->tlv_caps.me_freq_mhz represents the clock_freq (MHz) of
      the flow processing cores (FPC) on the NIC. While nn->me_freq_mhz is not
      be set.
      
      Fixes: ce991ab6 ("nfp: read ME frequency from vNIC ctrl memory")
      Signed-off-by: default avatarDiana Wang <na.wang@corigine.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@corigine.com>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3bd6b2a8
    • Eric Dumazet's avatar
      ipv6: fix typos in __ip6_finish_output() · 19d36c5f
      Eric Dumazet authored
      We deal with IPv6 packets, so we need to use IP6CB(skb)->flags and
      IP6SKB_REROUTED, instead of IPCB(skb)->flags and IPSKB_REROUTED
      
      Found by code inspection, please double check that fixing this bug
      does not surface other bugs.
      
      Fixes: 09ee9dba ("ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Tobias Brunner <tobias@strongswan.org>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: David Ahern <dsahern@kernel.org>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Tested-by: default avatarTobias Brunner <tobias@strongswan.org>
      Acked-by: default avatarTobias Brunner <tobias@strongswan.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      19d36c5f
    • Li Zhijian's avatar
      selftests/tc-testings: Be compatible with newer tc output · ac2944ab
      Li Zhijian authored
      old tc(iproute2-5.9.0) output:
       action order 1: bpf action.o:[action-ok] id 60 tag bcf7977d3b93787c jited default-action pipe
      newer tc(iproute2-5.14.0) output:
       action order 1: bpf action.o:[action-ok] id 64 name tag bcf7977d3b93787c jited default-action pipe
      
      It can fix below errors:
       # ok 260 f84a - Add cBPF action with invalid bytecode
       # not ok 261 e939 - Add eBPF action with valid object-file
       #       Could not match regex pattern. Verify command output:
       # total acts 0
       #
       #       action order 1: bpf action.o:[action-ok] id 42 name  tag bcf7977d3b93787c jited default-action pipe
       #        index 667 ref 1 bind 0
      Signed-off-by: default avatarLi Zhijian <zhijianx.li@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ac2944ab
    • Li Zhijian's avatar
      selftests/tc-testing: match any qdisc type · bdf1565f
      Li Zhijian authored
      We should not always presume all kernels use pfifo_fast as the default qdisc.
      
      For example, a fq_codel qdisk could have below output:
      qdisc fq_codel 0: parent 1:4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Suggested-by: default avatarPeilin Ye <peilin.ye@bytedance.com>
      Signed-off-by: default avatarLi Zhijian <zhijianx.li@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bdf1565f
    • Robert Marko's avatar
      net: dsa: qca8k: fix MTU calculation · 65258b9d
      Robert Marko authored
      qca8k has a global MTU, so its tracking the MTU per port to make sure
      that the largest MTU gets applied.
      Since it uses the frame size instead of MTU the driver MTU change function
      will then add the size of Ethernet header and checksum on top of MTU.
      
      The driver currently populates the per port MTU size as Ethernet frame
      length + checksum which equals 1518.
      
      The issue is that then MTU change function will go through all of the
      ports, find the largest MTU and apply the Ethernet header + checksum on
      top of it again, so for a desired MTU of 1500 you will end up with 1536.
      
      This is obviously incorrect, so to correct it populate the per port struct
      MTU with just the MTU and not include the Ethernet header + checksum size
      as those will be added by the MTU change function.
      
      Fixes: f58d2598 ("net: dsa: qca8k: implement the port MTU callbacks")
      Signed-off-by: default avatarRobert Marko <robert.marko@sartura.hr>
      Signed-off-by: default avatarAnsuel Smith <ansuelsmth@gmail.com>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      65258b9d
    • Ansuel Smith's avatar
      net: dsa: qca8k: fix internal delay applied to the wrong PAD config · 3b00a07c
      Ansuel Smith authored
      With SGMII phy the internal delay is always applied to the PAD0 config.
      This is caused by the falling edge configuration that hardcode the reg
      to PAD0 (as the falling edge bits are present only in PAD0 reg)
      Move the delay configuration before the reg overwrite to correctly apply
      the delay.
      
      Fixes: cef08115 ("net: dsa: qca8k: set internal delay also for sgmii")
      Signed-off-by: default avatarAnsuel Smith <ansuelsmth@gmail.com>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b00a07c
  3. 20 Nov, 2021 5 commits
  4. 19 Nov, 2021 8 commits
    • Brett Creeley's avatar
      iavf: Fix VLAN feature flags after VFR · 5951a2b9
      Brett Creeley authored
      When a VF goes through a reset, it's possible for the VF's feature set
      to change. For example it may lose the VIRTCHNL_VF_OFFLOAD_VLAN
      capability after VF reset. Unfortunately, the driver doesn't correctly
      deal with this situation and errors are seen from downing/upping the
      interface and/or moving the interface in/out of a network namespace.
      
      When setting the interface down/up we see the following errors after the
      VIRTCHNL_VF_OFFLOAD_VLAN capability was taken away from the VF:
      
      ice 0000:51:00.1: VF 1 failed opcode 12, retval: -64 iavf 0000:51:09.1:
      Failed to add VLAN filter, error IAVF_NOT_SUPPORTED ice 0000:51:00.1: VF
      1 failed opcode 13, retval: -64 iavf 0000:51:09.1: Failed to delete VLAN
      filter, error IAVF_NOT_SUPPORTED
      
      These add/delete errors are happening because the VLAN filters are
      tracked internally to the driver and regardless of the VLAN_ALLOWED()
      setting the driver tries to delete/re-add them over virtchnl.
      
      Fix the delete failure by making sure to delete any VLAN filter tracking
      in the driver when a removal request is made, while preventing the
      virtchnl request.  This makes it so the driver's VLAN list is up to date
      and the errors are
      
      Fix the add failure by making sure the check for VLAN_ALLOWED() during
      reset is done after the VF receives its capability list from the PF via
      VIRTCHNL_OP_GET_VF_RESOURCES. If VLAN functionality is not allowed, then
      prevent requesting re-adding the filters over virtchnl.
      
      When moving the interface into a network namespace we see the following
      errors after the VIRTCHNL_VF_OFFLOAD_VLAN capability was taken away from
      the VF:
      
      iavf 0000:51:09.1 enp81s0f1v1: NIC Link is Up Speed is 25 Gbps Full Duplex
      iavf 0000:51:09.1 temp_27: renamed from enp81s0f1v1
      iavf 0000:51:09.1 mgmt: renamed from temp_27
      iavf 0000:51:09.1 dev27: set_features() failed (-22); wanted 0x020190001fd54833, left 0x020190001fd54bb3
      
      These errors are happening because we aren't correctly updating the
      netdev capabilities and dealing with ndo_fix_features() and
      ndo_set_features() correctly.
      
      Fix this by only reporting errors in the driver's ndo_set_features()
      callback when VIRTCHNL_VF_OFFLOAD_VLAN is not allowed and any attempt to
      enable the VLAN features is made. Also, make sure to disable VLAN
      insertion, filtering, and stripping since the VIRTCHNL_VF_OFFLOAD_VLAN
      flag applies to all of them and not just VLAN stripping.
      
      Also, after we process the capabilities in the VF reset path, make sure
      to call netdev_update_features() in case the capabilities have changed
      in order to update the netdev's feature set to match the VF's actual
      capabilities.
      
      Lastly, make sure to always report success on VLAN filter delete when
      VIRTCHNL_VF_OFFLOAD_VLAN is not supported. The changed flow in
      iavf_del_vlans() allows the stack to delete previosly existing VLAN
      filters even if VLAN filtering is not allowed. This makes it so the VLAN
      filter list is up to date.
      
      Fixes: 8774370d ("i40e/i40evf: support for VF VLAN tag stripping control")
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      5951a2b9
    • Jedrzej Jagielski's avatar
      iavf: Fix refreshing iavf adapter stats on ethtool request · 3b5bdd18
      Jedrzej Jagielski authored
      Currently iavf adapter statistics are refreshed only in a
      watchdog task, triggered approximately every two seconds,
      which causes some ethtool requests to return outdated values.
      
      Add explicit statistics refresh when requested by ethtool -S.
      
      Fixes: b476b003 ("iavf: Move commands processing to the separate function")
      Signed-off-by: default avatarJan Sokolowski <jan.sokolowski@intel.com>
      Signed-off-by: default avatarJedrzej Jagielski <jedrzej.jagielski@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      3b5bdd18
    • Jedrzej Jagielski's avatar
      iavf: Fix deadlock occurrence during resetting VF interface · 0cc318d2
      Jedrzej Jagielski authored
      System hangs if close the interface is called from the kernel during
      the interface is in resetting state.
      During resetting operation the link is closing but kernel didn't
      know it and it tried to close this interface again what sometimes
      led to deadlock.
      Inform kernel about current state of interface
      and turn off the flag IFF_UP when interface is closing until reset
      is finished.
      Previously it was most likely to hang the system when kernel
      (network manager) tried to close the interface in the same time
      when interface was in resetting state because of deadlock.
      
      Fixes: 3c8e0b98 ("i40vf: don't stop me now")
      Signed-off-by: default avatarJaroslaw Gawin <jaroslawx.gawin@intel.com>
      Signed-off-by: default avatarJedrzej Jagielski <jedrzej.jagielski@intel.com>
      Tested-by: default avatarKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      0cc318d2
    • Nitesh B Venkatesh's avatar
      iavf: Prevent changing static ITR values if adaptive moderation is on · e792779e
      Nitesh B Venkatesh authored
      Resolve being able to change static values on VF when adaptive interrupt
      moderation is enabled.
      
      This problem is fixed by checking the interrupt settings is not
      a combination of change of static value while adaptive interrupt
      moderation is turned on.
      
      Without this fix, the user would be able to change static values
      on VF with adaptive moderation enabled.
      
      Fixes: 65e87c03 ("i40evf: support queue-specific settings for interrupt moderation")
      Signed-off-by: default avatarNitesh B Venkatesh <nitesh.b.venkatesh@intel.com>
      Tested-by: default avatarGeorge Kuruvinakunnel <george.kuruvinakunnel@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      e792779e
    • Zekun Shen's avatar
      stmmac_pci: Fix underflow size in stmmac_rx · 0f296e78
      Zekun Shen authored
      This bug report came up when we were testing the device driver
      by fuzzing. It shows that buf1_len can get underflowed and be
      0xfffffffc (4294967292).
      
      This bug is triggerable with a compromised/malfunctioning device.
      We found the bug through QEMU emulation tested the patch with
      emulation. We did NOT test it on real hardware.
      
      Attached is the bug report by fuzzing.
      
      BUG: KASAN: use-after-free in stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac]
      Read of size 4294967292 at addr ffff888016358000 by task ksoftirqd/0/9
      
      CPU: 0 PID: 9 Comm: ksoftirqd/0 Tainted: G        W         5.6.0 #1
      Call Trace:
       dump_stack+0x76/0xa0
       print_address_description.constprop.0+0x16/0x200
       ? stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac]
       ? stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac]
       __kasan_report.cold+0x37/0x7c
       ? stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac]
       kasan_report+0xe/0x20
       check_memory_region+0x15a/0x1d0
       memcpy+0x20/0x50
       stmmac_napi_poll_rx+0x1c08/0x36e0 [stmmac]
       ? stmmac_suspend+0x850/0x850 [stmmac]
       ? __next_timer_interrupt+0xba/0xf0
       net_rx_action+0x363/0xbd0
       ? call_timer_fn+0x240/0x240
       ? __switch_to_asm+0x40/0x70
       ? napi_busy_loop+0x520/0x520
       ? __schedule+0x839/0x15a0
       __do_softirq+0x18c/0x634
       ? takeover_tasklets+0x5f0/0x5f0
       run_ksoftirqd+0x15/0x20
       smpboot_thread_fn+0x2f1/0x6b0
       ? smpboot_unregister_percpu_thread+0x160/0x160
       ? __kthread_parkme+0x80/0x100
       ? smpboot_unregister_percpu_thread+0x160/0x160
       kthread+0x2b5/0x3b0
       ? kthread_create_on_node+0xd0/0xd0
       ret_from_fork+0x22/0x40
      Reported-by: default avatarBrendan Dolan-Gavitt <brendandg@nyu.edu>
      Signed-off-by: default avatarZekun Shen <bruceshenzk@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0f296e78
    • Zekun Shen's avatar
      atlantic: fix double-free in aq_ring_tx_clean · 6a405f6c
      Zekun Shen authored
      We found this bug while fuzzing the device driver. Using and freeing
      the dangling pointer buff->skb would cause use-after-free and
      double-free.
      
      This bug is triggerable with compromised/malfunctioning devices. We
      found the bug with QEMU emulation and tested the patch by emulation.
      We did NOT test on a real device.
      
      Attached is the bug report.
      
      BUG: KASAN: double-free or invalid-free in consume_skb+0x6c/0x1c0
      
      Call Trace:
       dump_stack+0x76/0xa0
       print_address_description.constprop.0+0x16/0x200
       ? consume_skb+0x6c/0x1c0
       kasan_report_invalid_free+0x61/0xa0
       ? consume_skb+0x6c/0x1c0
       __kasan_slab_free+0x15e/0x170
       ? consume_skb+0x6c/0x1c0
       kfree+0x8c/0x230
       consume_skb+0x6c/0x1c0
       aq_ring_tx_clean+0x5c2/0xa80 [atlantic]
       aq_vec_poll+0x309/0x5d0 [atlantic]
       ? _sub_I_65535_1+0x20/0x20 [atlantic]
       ? __next_timer_interrupt+0xba/0xf0
       net_rx_action+0x363/0xbd0
       ? call_timer_fn+0x240/0x240
       ? __switch_to_asm+0x34/0x70
       ? napi_busy_loop+0x520/0x520
       ? net_tx_action+0x379/0x720
       __do_softirq+0x18c/0x634
       ? takeover_tasklets+0x5f0/0x5f0
       run_ksoftirqd+0x15/0x20
       smpboot_thread_fn+0x2f1/0x6b0
       ? smpboot_unregister_percpu_thread+0x160/0x160
       ? __kthread_parkme+0x80/0x100
       ? smpboot_unregister_percpu_thread+0x160/0x160
       kthread+0x2b5/0x3b0
       ? kthread_create_on_node+0xd0/0xd0
       ret_from_fork+0x22/0x40
      Reported-by: default avatarBrendan Dolan-Gavitt <brendandg@nyu.edu>
      Signed-off-by: default avatarZekun Shen <bruceshenzk@gmail.com>
      Reviewed-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6a405f6c
    • Volodymyr Mytnyk's avatar
      net: marvell: prestera: fix double free issue on err path · e8d03250
      Volodymyr Mytnyk authored
      fix error path handling in prestera_bridge_port_join() that
      cases prestera driver to crash (see below).
      
       Trace:
         Internal error: Oops: 96000044 [#1] SMP
         Modules linked in: prestera_pci prestera uio_pdrv_genirq
         CPU: 1 PID: 881 Comm: ip Not tainted 5.15.0 #1
         pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
         pc : prestera_bridge_destroy+0x2c/0xb0 [prestera]
         lr : prestera_bridge_port_join+0x2cc/0x350 [prestera]
         sp : ffff800011a1b0f0
         ...
         x2 : ffff000109ca6c80 x1 : dead000000000100 x0 : dead000000000122
          Call trace:
         prestera_bridge_destroy+0x2c/0xb0 [prestera]
         prestera_bridge_port_join+0x2cc/0x350 [prestera]
         prestera_netdev_port_event.constprop.0+0x3c4/0x450 [prestera]
         prestera_netdev_event_handler+0xf4/0x110 [prestera]
         raw_notifier_call_chain+0x54/0x80
         call_netdevice_notifiers_info+0x54/0xa0
         __netdev_upper_dev_link+0x19c/0x380
      
      Fixes: e1189d9a ("net: marvell: prestera: Add Switchdev driver implementation")
      Signed-off-by: default avatarVolodymyr Mytnyk <vmytnyk@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8d03250
    • Volodymyr Mytnyk's avatar
      net: marvell: prestera: fix brige port operation · 253e9b4d
      Volodymyr Mytnyk authored
      Return NOTIFY_DONE (dont't care) for switchdev notifications
      that prestera driver don't know how to handle them.
      
      With introduction of SWITCHDEV_BRPORT_[UN]OFFLOADED switchdev
      events, the driver rejects adding swport to bridge operation
      which is handled by prestera_bridge_port_join() func. The root
      cause of this is that prestera driver returns error (EOPNOTSUPP)
      in prestera_switchdev_blk_event() handler for unknown swdev
      events. This causes switchdev_bridge_port_offload() to fail
      when adding port to bridge in prestera_bridge_port_join().
      
      Fixes: 957e2235 ("net: make switchdev_bridge_port_{,unoffload} loosely coupled with the bridge")
      Signed-off-by: default avatarVolodymyr Mytnyk <vmytnyk@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      253e9b4d