1. 07 Dec, 2022 3 commits
    • Ido Schimmel's avatar
      ipv4: Fix incorrect route flushing when source address is deleted · f96a3d74
      Ido Schimmel authored
      Cited commit added the table ID to the FIB info structure, but did not
      prevent structures with different table IDs from being consolidated.
      This can lead to routes being flushed from a VRF when an address is
      deleted from a different VRF.
      
      Fix by taking the table ID into account when looking for a matching FIB
      info. This is already done for FIB info structures backed by a nexthop
      object in fib_find_info_nh().
      
      Add test cases that fail before the fix:
      
       # ./fib_tests.sh -t ipv4_del_addr
      
       IPv4 delete address route tests
           Regular FIB info
           TEST: Route removed from VRF when source address deleted            [ OK ]
           TEST: Route in default VRF not removed                              [ OK ]
           TEST: Route removed in default VRF when source address deleted      [ OK ]
           TEST: Route in VRF is not removed by address delete                 [ OK ]
           Identical FIB info with different table ID
           TEST: Route removed from VRF when source address deleted            [FAIL]
           TEST: Route in default VRF not removed                              [ OK ]
       RTNETLINK answers: File exists
           TEST: Route removed in default VRF when source address deleted      [ OK ]
           TEST: Route in VRF is not removed by address delete                 [FAIL]
      
       Tests passed:   6
       Tests failed:   2
      
      And pass after:
      
       # ./fib_tests.sh -t ipv4_del_addr
      
       IPv4 delete address route tests
           Regular FIB info
           TEST: Route removed from VRF when source address deleted            [ OK ]
           TEST: Route in default VRF not removed                              [ OK ]
           TEST: Route removed in default VRF when source address deleted      [ OK ]
           TEST: Route in VRF is not removed by address delete                 [ OK ]
           Identical FIB info with different table ID
           TEST: Route removed from VRF when source address deleted            [ OK ]
           TEST: Route in default VRF not removed                              [ OK ]
           TEST: Route removed in default VRF when source address deleted      [ OK ]
           TEST: Route in VRF is not removed by address delete                 [ OK ]
      
       Tests passed:   8
       Tests failed:   0
      
      Fixes: 5a56a0b3 ("net: Don't delete routes in different VRFs")
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f96a3d74
    • Rasmus Villemoes's avatar
      net: fec: properly guard irq coalesce setup · 7e630356
      Rasmus Villemoes authored
      Prior to the Fixes: commit, the initialization code went through the
      same fec_enet_set_coalesce() function as used by ethtool, and that
      function correctly checks whether the current variant has support for
      irq coalescing.
      
      Now that the initialization code instead calls fec_enet_itr_coal_set()
      directly, that call needs to be guarded by a check for the
      FEC_QUIRK_HAS_COALESCE bit.
      
      Fixes: df727d45 (net: fec: don't reset irq coalesce settings to defaults on "ip link up")
      Reported-by: default avatarGreg Ungerer <gregungerer@westnet.com.au>
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Link: https://lore.kernel.org/r/20221205204604.869853-1-linux@rasmusvillemoes.dkSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7e630356
    • Hangbin Liu's avatar
      bonding: get correct NA dest address · 1f154f3b
      Hangbin Liu authored
      In commit 4d633d1b ("bonding: fix ICMPv6 header handling when receiving
      IPv6 messages"), there is a copy/paste issue for NA daddr. I found that
      in my testing and fixed it in my local branch. But I forgot to re-format
      the patch and sent the wrong mail.
      
      Fix it by reading the correct dest address.
      
      Fixes: 4d633d1b ("bonding: fix ICMPv6 header handling when receiving IPv6 messages")
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarJiri Pirko <jiri@nvidia.com>
      Acked-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Link: https://lore.kernel.org/r/20221206032055.7517-1-liuhangbin@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1f154f3b
  2. 06 Dec, 2022 12 commits
  3. 05 Dec, 2022 7 commits
  4. 04 Dec, 2022 1 commit
  5. 03 Dec, 2022 7 commits
  6. 02 Dec, 2022 10 commits
    • Luiz Augusto von Dentz's avatar
      Bluetooth: Fix crash when replugging CSR fake controllers · b5ca3387
      Luiz Augusto von Dentz authored
      It seems fake CSR 5.0 clones can cause the suspend notifier to be
      registered twice causing the following kernel panic:
      
      [   71.986122] Call Trace:
      [   71.986124]  <TASK>
      [   71.986125]  blocking_notifier_chain_register+0x33/0x60
      [   71.986130]  hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da]
      [   71.986154]  btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477]
      [   71.986159]  ? __pm_runtime_set_status+0x1a9/0x300
      [   71.986162]  ? ktime_get_mono_fast_ns+0x3e/0x90
      [   71.986167]  usb_probe_interface+0xe3/0x2b0
      [   71.986171]  really_probe+0xdb/0x380
      [   71.986174]  ? pm_runtime_barrier+0x54/0x90
      [   71.986177]  __driver_probe_device+0x78/0x170
      [   71.986180]  driver_probe_device+0x1f/0x90
      [   71.986183]  __device_attach_driver+0x89/0x110
      [   71.986186]  ? driver_allows_async_probing+0x70/0x70
      [   71.986189]  bus_for_each_drv+0x8c/0xe0
      [   71.986192]  __device_attach+0xb2/0x1e0
      [   71.986195]  bus_probe_device+0x92/0xb0
      [   71.986198]  device_add+0x422/0x9a0
      [   71.986201]  ? sysfs_merge_group+0xd4/0x110
      [   71.986205]  usb_set_configuration+0x57a/0x820
      [   71.986208]  usb_generic_driver_probe+0x4f/0x70
      [   71.986211]  usb_probe_device+0x3a/0x110
      [   71.986213]  really_probe+0xdb/0x380
      [   71.986216]  ? pm_runtime_barrier+0x54/0x90
      [   71.986219]  __driver_probe_device+0x78/0x170
      [   71.986221]  driver_probe_device+0x1f/0x90
      [   71.986224]  __device_attach_driver+0x89/0x110
      [   71.986227]  ? driver_allows_async_probing+0x70/0x70
      [   71.986230]  bus_for_each_drv+0x8c/0xe0
      [   71.986232]  __device_attach+0xb2/0x1e0
      [   71.986235]  bus_probe_device+0x92/0xb0
      [   71.986237]  device_add+0x422/0x9a0
      [   71.986239]  ? _dev_info+0x7d/0x98
      [   71.986242]  ? blake2s_update+0x4c/0xc0
      [   71.986246]  usb_new_device.cold+0x148/0x36d
      [   71.986250]  hub_event+0xa8a/0x1910
      [   71.986255]  process_one_work+0x1c4/0x380
      [   71.986259]  worker_thread+0x51/0x390
      [   71.986262]  ? rescuer_thread+0x3b0/0x3b0
      [   71.986264]  kthread+0xdb/0x110
      [   71.986266]  ? kthread_complete_and_exit+0x20/0x20
      [   71.986268]  ret_from_fork+0x1f/0x30
      [   71.986273]  </TASK>
      [   71.986274] ---[ end trace 0000000000000000 ]---
      [   71.986284] btusb: probe of 2-1.6:1.0 failed with error -17
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=216683
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Tested-by: default avatarLeonardo Eugênio <lelgenio@disroot.org>
      b5ca3387
    • Chen Zhongjin's avatar
      Bluetooth: Fix not cleanup led when bt_init fails · 2f3957c7
      Chen Zhongjin authored
      bt_init() calls bt_leds_init() to register led, but if it fails later,
      bt_leds_cleanup() is not called to unregister it.
      
      This can cause panic if the argument "bluetooth-power" in text is freed
      and then another led_trigger_register() tries to access it:
      
      BUG: unable to handle page fault for address: ffffffffc06d3bc0
      RIP: 0010:strcmp+0xc/0x30
        Call Trace:
          <TASK>
          led_trigger_register+0x10d/0x4f0
          led_trigger_register_simple+0x7d/0x100
          bt_init+0x39/0xf7 [bluetooth]
          do_one_initcall+0xd0/0x4e0
      
      Fixes: e64c97b5 ("Bluetooth: Add combined LED trigger for controller power")
      Signed-off-by: default avatarChen Zhongjin <chenzhongjin@huawei.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      2f3957c7
    • Chethan T N's avatar
      Bluetooth: Fix support for Read Local Supported Codecs V2 · 828cea2b
      Chethan T N authored
      Handling of Read Local Supported Codecs was broken during the
      HCI serialization design change patches.
      
      Fixes: d0b13706 ("Bluetooth: hci_sync: Rework init stages")
      Signed-off-by: default avatarChethan T N <chethan.tumkur.narayan@intel.com>
      Signed-off-by: default avatarKiran K <kiran.k@intel.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      828cea2b
    • Chethan T N's avatar
      Bluetooth: Remove codec id field in vendor codec definition · 93df7d56
      Chethan T N authored
      As per the specfication vendor codec id is defined.
      BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E page 2127
      
      Fixes: 9ae66402 ("Bluetooth: Add support for Read Local Supported Codecs V2")
      Signed-off-by: default avatarChethan T N <chethan.tumkur.narayan@intel.com>
      Signed-off-by: default avatarKiran K <kiran.k@intel.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      93df7d56
    • Sungwoo Kim's avatar
      Bluetooth: L2CAP: Fix u8 overflow · bcd70260
      Sungwoo Kim authored
      By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases
      multiple times and eventually it will wrap around the maximum number
      (i.e., 255).
      This patch prevents this by adding a boundary check with
      L2CAP_MAX_CONF_RSP
      
      Btmon log:
      Bluetooth monitor ver 5.64
      = Note: Linux version 6.1.0-rc2 (x86_64)                               0.264594
      = Note: Bluetooth subsystem version 2.22                               0.264636
      @ MGMT Open: btmon (privileged) version 1.22                  {0x0001} 0.272191
      = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0)          [hci0] 13.877604
      @ RAW Open: 9496 (privileged) version 2.22                   {0x0002} 13.890741
      = Open Index: 00:00:00:00:00:00                                [hci0] 13.900426
      (...)
      > ACL Data RX: Handle 200 flags 0x00 dlen 1033             #32 [hci0] 14.273106
              invalid packet size (12 != 1033)
              08 00 01 00 02 01 04 00 01 10 ff ff              ............
      > ACL Data RX: Handle 200 flags 0x00 dlen 1547             #33 [hci0] 14.273561
              invalid packet size (14 != 1547)
              0a 00 01 00 04 01 06 00 40 00 00 00 00 00        ........@.....
      > ACL Data RX: Handle 200 flags 0x00 dlen 2061             #34 [hci0] 14.274390
              invalid packet size (16 != 2061)
              0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04  ........@.......
      > ACL Data RX: Handle 200 flags 0x00 dlen 2061             #35 [hci0] 14.274932
              invalid packet size (16 != 2061)
              0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00  ........@.......
      = bluetoothd: Bluetooth daemon 5.43                                   14.401828
      > ACL Data RX: Handle 200 flags 0x00 dlen 1033             #36 [hci0] 14.275753
              invalid packet size (12 != 1033)
              08 00 01 00 04 01 04 00 40 00 00 00              ........@...
      Signed-off-by: default avatarSungwoo Kim <iam@sung-woo.kim>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      bcd70260
    • Mateusz Jończyk's avatar
      Bluetooth: silence a dmesg error message in hci_request.c · 696bd362
      Mateusz Jończyk authored
      On kernel 6.1-rcX, I have been getting the following dmesg error message
      on every boot, resume from suspend and rfkill unblock of the Bluetooth
      device:
      
      	Bluetooth: hci0: HCI_REQ-0xfcf0
      
      After some investigation, it turned out to be caused by
      commit dd50a864 ("Bluetooth: Delete unreferenced hci_request code")
      which modified hci_req_add() in net/bluetooth/hci_request.c to always
      print an error message when it is executed. In my case, the function was
      executed by msft_set_filter_enable() in net/bluetooth/msft.c, which
      provides support for Microsoft vendor opcodes.
      
      As explained by Brian Gix, "the error gets logged because it is using a
      deprecated (but still working) mechanism to issue HCI opcodes" [1]. So
      this is just a debugging tool to show that a deprecated function is
      executed. As such, it should not be included in the mainline kernel.
      See for example
      commit 771c0353 ("deprecate the '__deprecated' attribute warnings entirely and for good")
      Additionally, this error message is cryptic and the user is not able to
      do anything about it.
      
      [1]
      Link: https://lore.kernel.org/lkml/beb8dcdc3aee4c5c833aa382f35995f17e7961a1.camel@intel.com/
      
      Fixes: dd50a864 ("Bluetooth: Delete unreferenced hci_request code")
      Signed-off-by: default avatarMateusz Jończyk <mat.jonczyk@o2.pl>
      Cc: Brian Gix <brian.gix@intel.com>
      Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      696bd362
    • Wang ShaoBo's avatar
      Bluetooth: hci_conn: add missing hci_dev_put() in iso_listen_bis() · 7e7df2c1
      Wang ShaoBo authored
      hci_get_route() takes reference, we should use hci_dev_put() to release
      it when not need anymore.
      
      Fixes: f764a6c2 ("Bluetooth: ISO: Add broadcast support")
      Signed-off-by: default avatarWang ShaoBo <bobo.shaobowang@huawei.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      7e7df2c1
    • Wang ShaoBo's avatar
      Bluetooth: 6LoWPAN: add missing hci_dev_put() in get_l2cap_conn() · 747da130
      Wang ShaoBo authored
      hci_get_route() takes reference, we should use hci_dev_put() to release
      it when not need anymore.
      
      Fixes: 6b8d4a6a ("Bluetooth: 6LoWPAN: Use connected oriented channel instead of fixed one")
      Signed-off-by: default avatarWang ShaoBo <bobo.shaobowang@huawei.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      747da130
    • Ismael Ferreras Morezuelas's avatar
      Bluetooth: btusb: Add debug message for CSR controllers · 955aebd4
      Ismael Ferreras Morezuelas authored
      The rationale of showing this is that it's potentially critical
      information to diagnose and find more CSR compatibility bugs in the
      future and it will save a lot of headaches.
      
      Given that clones come from a wide array of vendors (some are actually
      Barrot, some are something else) and these numbers are what let us find
      differences between actual and fake ones, it will be immensely helpful
      to scour the Internet looking for this pattern and building an actual
      database to find correlations and improve the checks.
      
      Cc: stable@vger.kernel.org
      Cc: Hans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarIsmael Ferreras Morezuelas <swyterzone@gmail.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      955aebd4
    • Ismael Ferreras Morezuelas's avatar
      Bluetooth: btusb: Fix CSR clones again by re-adding ERR_DATA_REPORTING quirk · 42d7731e
      Ismael Ferreras Morezuelas authored
      A patch series by a Qualcomm engineer essentially removed my
      quirk/workaround because they thought it was unnecessary.
      
      It wasn't, and it broke everything again:
      
      https://patchwork.kernel.org/project/netdevbpf/list/?series=661703&archive=both&state=*
      
      He argues that the quirk is not necessary because the code should check
      if the dongle says if it's supported or not. The problem is that for
      these Chinese CSR clones they say that it would work:
      
      = New Index: 00:00:00:00:00:00 (Primary,USB,hci0)
      = Open Index: 00:00:00:00:00:00
      < HCI Command: Read Local Version Information (0x04|0x0001) plen 0
      > HCI Event: Command Complete (0x0e) plen 12
      > [hci0] 11.276039
            Read Local Version Information (0x04|0x0001) ncmd 1
              Status: Success (0x00)
              HCI version: Bluetooth 5.0 (0x09) - Revision 2064 (0x0810)
              LMP version: Bluetooth 5.0 (0x09) - Subversion 8978 (0x2312)
              Manufacturer: Cambridge Silicon Radio (10)
      ...
      < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
      > HCI Event: Command Complete (0x0e) plen 68
      > [hci0] 11.668030
            Read Local Supported Commands (0x04|0x0002) ncmd 1
              Status: Success (0x00)
              Commands: 163 entries
                ...
                Read Default Erroneous Data Reporting (Octet 18 - Bit 2)
                Write Default Erroneous Data Reporting (Octet 18 - Bit 3)
                ...
      ...
      < HCI Command: Read Default Erroneous Data Reporting (0x03|0x005a) plen 0
      = Close Index: 00:1A:7D:DA:71:XX
      
      So bring it back wholesale.
      
      Fixes: 63b1a7dd ("Bluetooth: hci_sync: Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING")
      Fixes: e168f690 ("Bluetooth: btusb: Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for fake CSR")
      Fixes: 766ae242 ("Bluetooth: hci_sync: Check LMP feature bit instead of quirk")
      Cc: stable@vger.kernel.org
      Cc: Zijun Hu <quic_zijuhu@quicinc.com>
      Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Tested-by: default avatarIsmael Ferreras Morezuelas <swyterzone@gmail.com>
      Signed-off-by: default avatarIsmael Ferreras Morezuelas <swyterzone@gmail.com>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      42d7731e