1. 07 Mar, 2022 3 commits
  2. 06 Mar, 2022 1 commit
  3. 05 Mar, 2022 2 commits
  4. 04 Mar, 2022 3 commits
    • Tung Nguyen's avatar
      tipc: fix kernel panic when enabling bearer · be4977b8
      Tung Nguyen authored
      When enabling a bearer on a node, a kernel panic is observed:
      
      [    4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]
      ...
      [    4.520030] Call Trace:
      [    4.520689]  <IRQ>
      [    4.521236]  tipc_link_build_proto_msg+0x375/0x750 [tipc]
      [    4.522654]  tipc_link_build_state_msg+0x48/0xc0 [tipc]
      [    4.524034]  __tipc_node_link_up+0xd7/0x290 [tipc]
      [    4.525292]  tipc_rcv+0x5da/0x730 [tipc]
      [    4.526346]  ? __netif_receive_skb_core+0xb7/0xfc0
      [    4.527601]  tipc_l2_rcv_msg+0x5e/0x90 [tipc]
      [    4.528737]  __netif_receive_skb_list_core+0x20b/0x260
      [    4.530068]  netif_receive_skb_list_internal+0x1bf/0x2e0
      [    4.531450]  ? dev_gro_receive+0x4c2/0x680
      [    4.532512]  napi_complete_done+0x6f/0x180
      [    4.533570]  virtnet_poll+0x29c/0x42e [virtio_net]
      ...
      
      The node in question is receiving activate messages in another
      thread after changing bearer status to allow message sending/
      receiving in current thread:
      
               thread 1           |              thread 2
               --------           |              --------
                                  |
      tipc_enable_bearer()        |
        test_and_set_bit_lock()   |
          tipc_bearer_xmit_skb()  |
                                  | tipc_l2_rcv_msg()
                                  |   tipc_rcv()
                                  |     __tipc_node_link_up()
                                  |       tipc_link_build_state_msg()
                                  |         tipc_link_build_proto_msg()
                                  |           tipc_mon_prep()
                                  |           {
                                  |             ...
                                  |             // null-pointer dereference
                                  |             u16 gen = mon->dom_gen;
                                  |             ...
                                  |           }
        // Not being executed yet |
        tipc_mon_create()         |
        {                         |
          ...                     |
          // allocate             |
          mon = kzalloc();        |
          ...                     |
        }                         |
      
      Monitoring pointer in thread 2 is dereferenced before monitoring data
      is allocated in thread 1. This causes kernel panic.
      
      This commit fixes it by allocating the monitoring data before enabling
      the bearer to receive messages.
      
      Fixes: 35c55c98 ("tipc: add neighbor monitoring framework")
      Reported-by: default avatarShuang Li <shuali@redhat.com>
      Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
      Signed-off-by: default avatarTung Nguyen <tung.q.nguyen@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      be4977b8
    • Robert Hancock's avatar
      net: macb: Fix lost RX packet wakeup race in NAPI receive · 0bf476fc
      Robert Hancock authored
      There is an oddity in the way the RSR register flags propagate to the
      ISR register (and the actual interrupt output) on this hardware: it
      appears that RSR register bits only result in ISR being asserted if the
      interrupt was actually enabled at the time, so enabling interrupts with
      RSR bits already set doesn't trigger an interrupt to be raised. There
      was already a partial fix for this race in the macb_poll function where
      it checked for RSR bits being set and re-triggered NAPI receive.
      However, there was a still a race window between checking RSR and
      actually enabling interrupts, where a lost wakeup could happen. It's
      necessary to check again after enabling interrupts to see if RSR was set
      just prior to the interrupt being enabled, and re-trigger receive in that
      case.
      
      This issue was noticed in a point-to-point UDP request-response protocol
      which periodically saw timeouts or abnormally high response times due to
      received packets not being processed in a timely fashion. In many
      applications, more packets arriving, including TCP retransmissions, would
      cause the original packet to be processed, thus masking the issue.
      
      Fixes: 02f7a34f ("net: macb: Re-enable RX interrupt only when RX is done")
      Cc: stable@vger.kernel.org
      Co-developed-by: default avatarScott McNutt <scott.mcnutt@siriusxm.com>
      Signed-off-by: default avatarScott McNutt <scott.mcnutt@siriusxm.com>
      Signed-off-by: default avatarRobert Hancock <robert.hancock@calian.com>
      Tested-by: default avatarClaudiu Beznea <claudiu.beznea@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0bf476fc
    • Jakub Kicinski's avatar
      Merge tag 'for-net-2022-03-03' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth · 9f3956d6
      Jakub Kicinski authored
      Luiz Augusto von Dentz says:
      
      ====================
      bluetooth pull request for net:
      
       - Fix regression with processing of MGMT commands
       - Fix unbalanced unlock in Set Device Flags
      
      * tag 'for-net-2022-03-03' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth:
        Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work
        Bluetooth: hci_core: Fix unbalanced unlock in set_device_flags()
      ====================
      
      Link: https://lore.kernel.org/r/20220303210743.314679-1-luiz.dentz@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      9f3956d6
  5. 03 Mar, 2022 26 commits
  6. 02 Mar, 2022 5 commits