1. 25 Apr, 2023 11 commits
  2. 24 Apr, 2023 29 commits
    • Jakub Kicinski's avatar
      Merge tag 'nf-next-23-04-22' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next · ffcddcae
      Jakub Kicinski authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter/IPVS updates for net-next
      
      1) Reduce jumpstack footprint: Stash chain in last rule marker in blob for
         tracing. Remove last rule and chain from jumpstack. From Florian Westphal.
      
      2) nf_tables validates all tables before committing the new rules.
         Unfortunately, this has two drawbacks:
      
         - Since addition of the transaction mutex pernet state gets written to
           outside of the locked section from the cleanup callback, this is
           wrong so do this cleanup directly after table has passed all checks.
      
         - Revalidate tables that saw no changes. This can be avoided by
           keeping the validation state per table, not per netns.
      
         From Florian Westphal.
      
      3) Get rid of a few redundant pointers in the traceinfo structure.
         The three removed pointers are used in the expression evaluation loop,
         so gcc keeps them in registers. Passing them to the (inlined) helpers
         thus doesn't increase nft_do_chain text size, while stack is reduced
         by another 24 bytes on 64bit arches. From Florian Westphal.
      
      4) IPVS cleanups in several ways without implementing any functional
         changes, aside from removing some debugging output:
      
         - Update width of source for ip_vs_sync_conn_options
           The operation is safe, use an annotation to describe it properly.
      
         - Consistently use array_size() in ip_vs_conn_init()
           It seems better to use helpers consistently.
      
         - Remove {Enter,Leave}Function. These seem to be well past their
           use-by date.
      
         - Correct spelling in comments.
      
         From Simon Horman.
      
      5) Extended netlink error report for netdevice in flowtables and
         netdev/chains. Allow for incrementally add/delete devices to netdev
         basechain. Allow to create netdev chain without device.
      
      * tag 'nf-next-23-04-22' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next:
        netfilter: nf_tables: allow to create netdev chain without device
        netfilter: nf_tables: support for deleting devices in an existing netdev chain
        netfilter: nf_tables: support for adding new devices to an existing netdev chain
        netfilter: nf_tables: rename function to destroy hook list
        netfilter: nf_tables: do not send complete notification of deletions
        netfilter: nf_tables: extended netlink error reporting for netdevice
        ipvs: Correct spelling in comments
        ipvs: Remove {Enter,Leave}Function
        ipvs: Consistently use array_size() in ip_vs_conn_init()
        ipvs: Update width of source for ip_vs_sync_conn_options
        netfilter: nf_tables: do not store rule in traceinfo structure
        netfilter: nf_tables: do not store verdict in traceinfo structure
        netfilter: nf_tables: do not store pktinfo in traceinfo structure
        netfilter: nf_tables: remove unneeded conditional
        netfilter: nf_tables: make validation state per table
        netfilter: nf_tables: don't write table validation state without mutex
        netfilter: nf_tables: don't store chain address on jump
        netfilter: nf_tables: don't store address of last rule on jump
        netfilter: nf_tables: merge nft_rules_old structure and end of ruleblob marker
      ====================
      
      Link: https://lore.kernel.org/r/20230421235021.216950-1-pablo@netfilter.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ffcddcae
    • David S. Miller's avatar
      Merge tag 'for-net-next-2023-04-23' of... · 2efb07b5
      David S. Miller authored
      Merge tag 'for-net-next-2023-04-23' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
      
      bluetooth-next pull request for net-next:
      
       - Introduce devcoredump support
       - Add support for Realtek RTL8821CS, RTL8851B, RTL8852BS
       - Add support for Mediatek MT7663, MT7922
       - Add support for NXP w8997
       - Add support for Actions Semi ATS2851
       - Add support for QTI WCN6855
       - Add support for Marvell 88W8997
      2efb07b5
    • Luiz Augusto von Dentz's avatar
      Bluetooth: hci_sync: Only allow hci_cmd_sync_queue if running · d883a466
      Luiz Augusto von Dentz authored
      This makes sure hci_cmd_sync_queue only queue new work if HCI_RUNNING
      has been set otherwise there is a risk of commands being sent while
      turning off.
      
      Because hci_cmd_sync_queue can no longer queue work while HCI_RUNNING is
      not set it cannot be used to power on adapters so instead
      hci_cmd_sync_submit is introduced which bypass the HCI_RUNNING check, so
      it behaves like the old implementation.
      
      Link: https://lore.kernel.org/all/CAB4PzUpDMvdc8j2MdeSAy1KkAE-D3woprCwAdYWeOc-3v3c9Sw@mail.gmail.com/Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      d883a466
    • Tim Jiang's avatar
      Bluetooth: btusb: Add WCN6855 devcoredump support · 20981ce2
      Tim Jiang authored
      WCN6855 will report memdump via ACL data or HCI event when
      it get crashed, so we collect memdump to debug firmware.
      Signed-off-by: default avatarTim Jiang <quic_tjiang@quicinc.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      20981ce2
    • Neeraj Sanjay Kale's avatar
      Bluetooth: btnxpuart: Enable flow control before checking boot signature · b0310d6e
      Neeraj Sanjay Kale authored
      This enables flow control before checking for bootloader signature and
      deciding whether FW download is needed or not. In case of V1 bootloader
      chips w8987 and w8997, it is observed that if WLAN FW is downloaded first
      and power save is enabled in wlan core, bootloader signatures are not
      emitted by the BT core when the chip is put to sleep. As a result, the
      driver skips FW download and subsequent HCI commands get timeout errors
      in dmesg as shown below:
      
      [  112.898867] Bluetooth: hci0: Opcode 0x c03 failed: -110
      [  114.914865] Bluetooth: hci0: Setting baudrate failed (-110)
      [  116.930856] Bluetooth: hci0: Setting wake-up method failed (-110)
      
      By enabling the flow control, the host enables its RTS pin, and an
      interrupt in chip's UART peripheral causes the bootloader to wake up,
      enabling the bootloader signatures, which then helps in downloading
      the bluetooth FW file.
      
      This changes all instances of 0/1 for serdev_device_set_flow_control()
      to false/true.
      Signed-off-by: default avatarNeeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      b0310d6e
    • Archie Pusaka's avatar
      Bluetooth: Cancel sync command before suspend and power off · f4198635
      Archie Pusaka authored
      Some of the sync commands might take a long time to complete, e.g.
      LE Create Connection when the peer device isn't responding might take
      20 seconds before it times out. If suspend command is issued during
      this time, it will need to wait for completion since both commands are
      using the same sync lock.
      
      This patch cancel any running sync commands before attempting to
      suspend or adapter power off.
      Signed-off-by: default avatarArchie Pusaka <apusaka@chromium.org>
      Reviewed-by: default avatarYing Hsu <yinghsu@chromium.org>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      f4198635
    • Max Chou's avatar
      Bluetooth: btrtl: Add the support for RTL8851B · 7948fe1c
      Max Chou authored
      Add the support for RTL8851B BT controller on USB interface.
      The necessary firmware will be submitted to linux-firmware project.
      
      Note that the Bluetooth devices WITH the VID=0x0bda would be set the
      feature quirk in btrtl_setup_realtek(). It's able to ignore the
      feature flag set for the specific VID and PID in blacklist_table[] of
      btusb.c. (check [1])
      
      If Realtek Bluetooth chips WITHOUT the VID=0x0bda, it shall be added
      the feature flag for the specific VID and PID in blacklist_table[] of
      btusb.c. (check [2])
      
      [1] '9ab9235f ("Bluetooth: btrtl: Enable WBS for the specific
          Realtek devices")'
      [2] '73280f13 ("Bluetooth: btusb: Add the more support IDs for
          Realtek RTL8822CE")'
      
      The device info from /sys/kernel/debug/usb/devices as below.
      
      T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 33 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=0bda ProdID=b851 Rev= 0.00
      S:  Manufacturer=Realtek
      S:  Product=802.11ax WLAN Adapter
      S:  SerialNumber=00E04C885A01
      C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA
      A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
      E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      Signed-off-by: default avatarMax Chou <max.chou@realtek.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      7948fe1c
    • Luiz Augusto von Dentz's avatar
      Bluetooth: btnxpuart: Fix sparse warnings · 9e080b53
      Luiz Augusto von Dentz authored
      This fixes the following sparse warnings:
      
         drivers/bluetooth/btnxpuart.c:681:23: sparse: sparse:
         restricted __le16 degrades to integer
         drivers/bluetooth/btnxpuart.c:690:82: sparse:
         sparse: incorrect type in argument 2 (different base types)
         @@     expected unsigned short [usertype] req_len
         @@     got restricted __le16 [usertype] len @@
         drivers/bluetooth/btnxpuart.c:690:82: sparse:
         expected unsigned short [usertype] req_len
         drivers/bluetooth/btnxpuart.c:690:82: sparse:
         got restricted __le16 [usertype] len
         drivers/bluetooth/btnxpuart.c:694:84: sparse:
         sparse: incorrect type in argument 2 (different base types)
         @@     expected unsigned short [usertype] req_len
         @@     got restricted __le16 [usertype] len @@
         drivers/bluetooth/btnxpuart.c:694:84: sparse:
         expected unsigned short [usertype] req_len
         drivers/bluetooth/btnxpuart.c:694:84: sparse:
         got restricted __le16 [usertype] len
         drivers/bluetooth/btnxpuart.c:708:23: sparse:
         sparse: incorrect type in assignment (different base types)
         @@     expected unsigned int [usertype] requested_len
         @@     got restricted __le16 [usertype] len @@
         drivers/bluetooth/btnxpuart.c:708:23: sparse:
         expected unsigned int [usertype] requested_len
         drivers/bluetooth/btnxpuart.c:708:23: sparse:
         got restricted __le16 [usertype] len
         drivers/bluetooth/btnxpuart.c:787:78: sparse:
         sparse: incorrect type in argument 2 (different base types)
         @@     expected unsigned short [usertype] chipid
         @@     got restricted __le16 [usertype] chip_id @@
         drivers/bluetooth/btnxpuart.c:787:78: sparse:
         expected unsigned short [usertype] chipid
         drivers/bluetooth/btnxpuart.c:787:78: sparse:
         got restricted __le16 [usertype] chip_id
         drivers/bluetooth/btnxpuart.c:810:74: sparse:
         sparse: incorrect type in argument 2 (different base types)
         @@     expected unsigned short [usertype] req_len
         @@     got restricted __le16 [usertype] len @@
         drivers/bluetooth/btnxpuart.c:810:74: sparse:
         expected unsigned short [usertype] req_len
         drivers/bluetooth/btnxpuart.c:810:74: sparse:
         got restricted __le16 [usertype] len
         drivers/bluetooth/btnxpuart.c:815:76: sparse:
         sparse: incorrect type in argument 2 (different base types)
         @@     expected unsigned short [usertype] req_len
         @@     got restricted __le16 [usertype] len @@
         drivers/bluetooth/btnxpuart.c:815:76: sparse:
         expected unsigned short [usertype] req_len
         drivers/bluetooth/btnxpuart.c:815:76: sparse:
         got restricted __le16 [usertype] len
         drivers/bluetooth/btnxpuart.c:834:16: sparse:
         sparse: restricted __le32 degrades to integer
         drivers/bluetooth/btnxpuart.c:843:55: sparse:
         sparse: restricted __le32 degrades to integer
         drivers/bluetooth/btnxpuart.c:844:36: sparse:
         sparse: incorrect type in argument 3 (different base types)
         @@     expected unsigned long [usertype]
         @@     got restricted __le16 [usertype] len @@
         drivers/bluetooth/btnxpuart.c:844:36: sparse:
         expected unsigned long [usertype]
         drivers/bluetooth/btnxpuart.c:844:36: sparse:
         got restricted __le16 [usertype] len
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Link: https://lore.kernel.org/oe-kbuild-all/202304160736.Tsa0zTBU-lkp@intel.com/Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      9e080b53
    • Max Chou's avatar
      Bluetooth: btrtl: Firmware format v2 support · 9a24ce5e
      Max Chou authored
      Realtek changed the format of the firmware file as v2. The driver
      should implement the patch to extract the firmware data from the
      firmware file. The future chips must apply this patch for firmware loading.
      This patch is compatible with the both previous format and v2 as well.
      Signed-off-by: default avatarAllen Chen <allen_chen@realsil.com.cn>
      Signed-off-by: default avatarAlex Lu <alex_lu@realsil.com.cn>
      Tested-by: default avatarHilda Wu <hildawu@realtek.com>
      Signed-off-by: default avatarMax Chou <max.chou@realtek.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      9a24ce5e
    • Zijun Hu's avatar
      Bluetooth: Devcoredump: Fix storing u32 without specifying byte order issue · 0ab905c3
      Zijun Hu authored
      API hci_devcd_init() stores its u32 type parameter @dump_size into
      skb, but it does not specify which byte order is used to store the
      integer, let us take little endian to store and parse the integer.
      
      Fixes: f5cc609d09d4 ("Bluetooth: Add support for hci devcoredump")
      Signed-off-by: default avatarZijun Hu <quic_zijuhu@quicinc.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      0ab905c3
    • Ruihan Li's avatar
      bluetooth: Perform careful capability checks in hci_sock_ioctl() · 25c150ac
      Ruihan Li authored
      Previously, capability was checked using capable(), which verified that the
      caller of the ioctl system call had the required capability. In addition,
      the result of the check would be stored in the HCI_SOCK_TRUSTED flag,
      making it persistent for the socket.
      
      However, malicious programs can abuse this approach by deliberately sharing
      an HCI socket with a privileged task. The HCI socket will be marked as
      trusted when the privileged task occasionally makes an ioctl call.
      
      This problem can be solved by using sk_capable() to check capability, which
      ensures that not only the current task but also the socket opener has the
      specified capability, thus reducing the risk of privilege escalation
      through the previously identified vulnerability.
      
      Cc: stable@vger.kernel.org
      Fixes: f81f5b2d ("Bluetooth: Send control open and close messages for HCI raw sockets")
      Signed-off-by: default avatarRuihan Li <lrh2000@pku.edu.cn>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      25c150ac
    • Min Li's avatar
      Bluetooth: L2CAP: fix "bad unlock balance" in l2cap_disconnect_rsp · 25e97f7b
      Min Li authored
      conn->chan_lock isn't acquired before l2cap_get_chan_by_scid,
      if l2cap_get_chan_by_scid returns NULL, then 'bad unlock balance'
      is triggered.
      
      Reported-by: syzbot+9519d6b5b79cf7787cf3@syzkaller.appspotmail.com
      Link: https://lore.kernel.org/all/000000000000894f5f05f95e9f4d@google.com/Signed-off-by: default avatarMin Li <lm0963hack@gmail.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      25e97f7b
    • Ruihan Li's avatar
      bluetooth: Add cmd validity checks at the start of hci_sock_ioctl() · 000c2fa2
      Ruihan Li authored
      Previously, channel open messages were always sent to monitors on the first
      ioctl() call for unbound HCI sockets, even if the command and arguments
      were completely invalid. This can leave an exploitable hole with the abuse
      of invalid ioctl calls.
      
      This commit hardens the ioctl processing logic by first checking if the
      command is valid, and immediately returning with an ENOIOCTLCMD error code
      if it is not. This ensures that ioctl calls with invalid commands are free
      of side effects, and increases the difficulty of further exploitation by
      forcing exploitation to find a way to pass a valid command first.
      Signed-off-by: default avatarRuihan Li <lrh2000@pku.edu.cn>
      Co-developed-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      000c2fa2
    • Liu Jian's avatar
      Revert "Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work" · db2bf510
      Liu Jian authored
      This reverts commit 1e9ac114.
      
      This patch introduces a possible null-ptr-def problem. Revert it. And the
      fixed bug by this patch have resolved by commit 73f7b171 ("Bluetooth:
      btsdio: fix use after free bug in btsdio_remove due to race condition").
      
      Fixes: 1e9ac114 ("Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work")
      Signed-off-by: default avatarLiu Jian <liujian56@huawei.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      db2bf510
    • Raul Cheleguini's avatar
      Bluetooth: Add new quirk for broken set random RPA timeout for ATS2851 · 91b6d02d
      Raul Cheleguini authored
      The ATS2851 based controller advertises support for command "LE Set Random
      Private Address Timeout" but does not actually implement it, impeding the
      controller initialization.
      
      Add the quirk HCI_QUIRK_BROKEN_SET_RPA_TIMEOUT to unblock the controller
      initialization.
      
      < HCI Command: LE Set Resolvable Private... (0x08|0x002e) plen 2
              Timeout: 900 seconds
      > HCI Event: Command Status (0x0f) plen 4
            LE Set Resolvable Private Address Timeout (0x08|0x002e) ncmd 1
              Status: Unknown HCI Command (0x01)
      Co-developed-by: default avatarimoc <wzj9912@gmail.com>
      Signed-off-by: default avatarimoc <wzj9912@gmail.com>
      Signed-off-by: default avatarRaul Cheleguini <raul.cheleguini@gmail.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      91b6d02d
    • Luiz Augusto von Dentz's avatar
      Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED · c09b80be
      Luiz Augusto von Dentz authored
      When submitting HCI_OP_LE_CREATE_CIS the code shall wait for
      HCI_EVT_LE_CIS_ESTABLISHED thus enforcing the serialization of
      HCI_OP_LE_CREATE_CIS as the Core spec does not allow to send them in
      parallel:
      
        BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E page 2566:
      
        If the Host issues this command before all the HCI_LE_CIS_Established
        events from the previous use of the command have been generated, the
        Controller shall return the error code Command Disallowed (0x0C).
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      c09b80be
    • Luiz Augusto von Dentz's avatar
      Bluetooth: hci_conn: Fix not matching by CIS ID · c14516fa
      Luiz Augusto von Dentz authored
      This fixes only matching CIS by address which prevents creating new hcon
      if upper layer is requesting a specific CIS ID.
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      c14516fa
    • Luiz Augusto von Dentz's avatar
      Bluetooth: hci_conn: Add support for linking multiple hcon · 06149746
      Luiz Augusto von Dentz authored
      Since it is required for some configurations to have multiple CIS with
      the same peer which is now covered by iso-tester in the following test
      cases:
      
          ISO AC 6(i) - Success
          ISO AC 7(i) - Success
          ISO AC 8(i) - Success
          ISO AC 9(i) - Success
          ISO AC 11(i) - Success
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      06149746
    • Dan Carpenter's avatar
      Bluetooth: vhci: Fix info leak in force_devcd_write() · e4eea890
      Dan Carpenter authored
      There are a number of bugs here:
      
      1) If "count" is less than sizeof(dump_data.data) then it copies
         uninitialized data.
      2) If simple_write_to_buffer() returns -EFAULT then we run into a
         problem "ret < count" comparison.  "count" is an unsigned long so the
         comparison is type promoted to unsigned long and the negative returns
         become high positive values.  That also results in copying
         uninitialized data.
      3) If "*ppos" is non-zero then the first part of the dump_data
         buffer is uninitialized.  Using copy_from_user() instead of
         simple_write_to_buffer() is more appropriate here.
      
      Fixes: d5d5df6da0aa ("Bluetooth: Add vhci devcoredump support")
      Signed-off-by: default avatarDan Carpenter <error27@gmail.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      e4eea890
    • Steev Klimaszewski's avatar
      Bluetooth: hci_qca: mark OF related data as maybe unused · 0811ff48
      Steev Klimaszewski authored
      The driver can be compile tested with !CONFIG_OF making certain data
      unused.
      Signed-off-by: default avatarSteev Klimaszewski <steev@kali.org>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      0811ff48
    • Iulia Tanasescu's avatar
      Bluetooth: hci_conn: remove extra line in hci_le_big_create_sync · 9e3c2ea6
      Iulia Tanasescu authored
      Remove extra line setting the broadcast code parameter of the
      hci_cp_le_create_big struct to 0. The broadcast code is copied
      from the QoS struct.
      Signed-off-by: default avatarIulia Tanasescu <iulia.tanasescu@nxp.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      9e3c2ea6
    • Lanzhe Li's avatar
      Bluetooth: fix inconsistent indenting · 3c690a0d
      Lanzhe Li authored
      Fixed a wrong indentation before "return".This line uses a 7 space
      indent instead of a tab.
      Signed-off-by: default avatarLanzhe Li <u202212060@hust.edu.cn>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      3c690a0d
    • Neeraj Sanjay Kale's avatar
      Bluetooth: btnxpuart: No need to check the received bootloader signature · 305d6b6e
      Neeraj Sanjay Kale authored
      We can never assume the uart will deliver a complete packet to the BT
      layer at once, the expected packet may be divided into several parts by
      uart as uart doesn't know the received packet size, the received data
      count may mismatch with the expected packet size, so here
      is_valid_bootloader_signature() check may always return false.
      
      Even we remove the count check in is_valid_bootloader_signature(), then
      the first part of the data which includes the packet type can pass the
      is_valid_bootloader_signature() check, but the remaining parts don't
      have the packet type data still cannot pass the check, here return
      directly will cause the data loss.
      
      So need to remove the received bootloader signature check here, the
      h4_recv_buf() can help us combine the different data received into one
      packet. If any out-of-sync or incomplete bootloader signature is received,
      it is safe to ignore and discard it, and process the next bootloader
      signature.
      Co-developed-by: default avatarSherry Sun <sherry.sun@nxp.com>
      Signed-off-by: default avatarSherry Sun <sherry.sun@nxp.com>
      Signed-off-by: default avatarNeeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      305d6b6e
    • Neeraj Sanjay Kale's avatar
      Bluetooth: btnxpuart: Disable Power Save feature on startup · 893410b2
      Neeraj Sanjay Kale authored
      This sets the default power save mode setting to disabled.
      With this setting, this driver will behave like a normal h4 driver.
      If user needs to use the power save feature, it can be enabled
      using the following vendor command:
      hcitool cmd 3f 23 02 00 00 (HCI_NXP_AUTO_SLEEP_MODE)
      Signed-off-by: default avatarNeeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      893410b2
    • Neeraj Sanjay Kale's avatar
      Bluetooth: btnxpuart: Deasset UART break before closing serdev device · 86d55f12
      Neeraj Sanjay Kale authored
      This adds a call to ps_wakeup() before closing the serdev device, to
      de-assert UART break.
      Signed-off-by: default avatarNeeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      86d55f12
    • Neeraj Sanjay Kale's avatar
      Bluetooth: btnxpuart: Add support to download helper FW file for w8997 · 38a4f83d
      Neeraj Sanjay Kale authored
      This adds support to download helper FW file for the legacy NXP chipset
      88w8997 for the btnxpuart driver. This helper FW file is necessary to
      set the bootloader baudrate to 3000000 after which the actual BT FW file
      can be downloaded. This change helps bring the FW download time from
      around 10 sec to less than 2 sec for 88w8997 chip. For newer chipsets,
      both V1 and V3 bootloader, driver sends the cmd5 and cmd7 to the chip
      bootloader, and does not need a helper FW file.
      Signed-off-by: default avatarNeeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      38a4f83d
    • Hans de Goede's avatar
      Bluetooth: hci_bcm: Add Acer Iconia One 7 B1-750 to the bcm_broken_irq_dmi_table · 09df5a91
      Hans de Goede authored
      The DSDT for the Acer Iconia One 7 B1-750 models (which share
      the same mainboard) specifies a IOAPIC IRQ for the HCI -> host IRQ but
      this is not correct.
      
      Like the Asus TF103C these tablets use pin 17 of the INT33FC:02 GPIO
      controller for the IRQ and this pin is _not_ configured in direct IRQ
      mode by the firmware.
      
      Add a DMI match for this, re-using the Asus TF103C gpiod_lookup_table,
      to fix bluetooth not working on these tablets.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      09df5a91
    • Hans de Goede's avatar
      Bluetooth: hci_bcm: Add Lenovo Yoga Tablet 2 830 / 1050 to the bcm_broken_irq_dmi_table · 9a094602
      Hans de Goede authored
      The DSDT for the Lenovo Yoga Tablet 2 830 / 1050 models (which share
      the same mainboard) specifies a IOAPIC IRQ for the HCI -> host IRQ but
      this is not correct.
      
      Like the Asus TF103C these tablets use pin 17 of the INT33FC:02 GPIO
      controller for the IRQ and this pin is _not_ configured in direct IRQ
      mode by the firmware.
      
      Add a DMI match for this, re-using the Asus TF103C gpiod_lookup_table,
      to fix bluetooth not working on these tablets.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      9a094602
    • Hans de Goede's avatar
      Bluetooth: hci_bcm: Limit bcm43430a0 / bcm43430a1 baudrate to 2000000 · ce439473
      Hans de Goede authored
      The bcm43430a0 and bcm43430a1 BT does not support the 0xfc45 command
      to set the UART clock to 48 MHz and it also does not work at 4000000
      baud without this command as some newer models do.
      
      These chips are found on ACPI/x86 devices where the operating baudrate
      does not come from the firmware but is hardcoded at 4000000, which does
      not work.
      
      Add a max_baudrate value to struct bcm_device_data and set this
      to 2000000 on all known ACPI hardware-ids for the bcm43430a0
      and the bcm43430a1.
      
      Note this also adds the BCM2E9F ACPI HID which was missing until now.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      ce439473