)]}' { "log": [ { "commit": "e40edfa049b967f0b9379bf549c59431302ad181", "tree": "ffad5010334ca63bead7e743fda2d57e6a7b29e2", "parents": [ "ee0662ba1e0a58eba90cab4c7871823bc119c342" ], "author": { "name": "Thomas Huth", "email": "thuth@redhat.com", "time": "Thu Sep 10 14:32:54 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Sep 10 16:04:06 2026 -0400" }, "message": "Bluetooth: SMP: Zeroize raw key data on the stack in smp_e()\n\nsmp_e() already clears the AES key in its \"struct aes_enckey aes\"\non the stack before leaving the function - but the very same\ninformation is also available as raw key data in the tmp[] array,\nso this should get cleared, too.\n\nSigned-off-by: Thomas Huth \u003cthuth@redhat.com\u003e\n" }, { "commit": "ee0662ba1e0a58eba90cab4c7871823bc119c342", "tree": "82428a78583393ff44ad71e0c9e8dea48c624618", "parents": [ "6691666bb4b22157cb3b9ad4e7ebdd1a7e8c19a3" ], "author": { "name": "Chengfeng Ye", "email": "nicoyip.dev@gmail.com", "time": "Sat Aug 22 01:43:50 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Sep 10 16:03:45 2026 -0400" }, "message": "Bluetooth: hci_sync: Serialize local codec list cleanup\n\nhci_dev_close_sync() clears hdev-\u003elocal_codecs after releasing hdev-\u003elock.\nCodec list additions and both traversals in sco_sock_getsockopt() use that\nlock, but the close path does not. A close and BT_CODEC query can therefore\ninterleave as follows:\n\n hci_dev_close_sync() sco_sock_getsockopt()\n hci_dev_lock()\n fetch codec entry\n hci_codec_list_clear()\n kfree(entry)\n read entry-\u003eid\n\nThe reader then accesses an entry which the close path has freed. KASAN\nreported:\n\n BUG: KASAN: slab-use-after-free in sco_sock_getsockopt+0xfa0/0xfe0\n Read of size 1 at addr ffff8881001c3450\n Call Trace:\n sco_sock_getsockopt+0xfa0/0xfe0\n do_sock_getsockopt+0x537/0x7b0\n __sys_getsockopt+0xf2/0x170\n Allocated by task 92:\n hci_codec_list_add.isra.0+0x2c/0x440\n hci_read_codec_capabilities+0x224/0x590\n hci_read_supported_codecs+0x2c2/0x640\n Freed by task 92:\n kfree+0x131/0x3c0\n hci_codec_list_clear+0xd8/0x160\n hci_dev_close_sync+0x92a/0xfa0\n\nTake hdev-\u003elock around the clear operation at its existing point in the\nclose path. This makes the clear wait for active readers and prevents a new\ntraversal until the list is empty without changing teardown ordering.\n\nFixes: b938790e7054 (\"Bluetooth: hci_codec: Fix leaking content of local_codecs\")\nCc: stable@vger.kernel.org\nSigned-off-by: Chengfeng Ye \u003cnicoyip.dev@gmail.com\u003e\n" }, { "commit": "6691666bb4b22157cb3b9ad4e7ebdd1a7e8c19a3", "tree": "d23586ec9d96f64a61ff55c0ba877bbb1790a24f", "parents": [ "ca10117e55dff28a2da9a95b8e8e798c99a01cf9" ], "author": { "name": "Ibrahim Abdelkader", "email": "iabdelka@qti.qualcomm.com", "time": "Wed Aug 19 14:54:25 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Sep 10 16:03:26 2026 -0400" }, "message": "Bluetooth: hci_qca: Do not write to the serial port after it is closed\n\nhci_uart_close() closes the serdev port if HCI_QUIRK_NON_PERSISTENT_SETUP\nis set (for example, for the WCN399x family). A failed hci_dev_open_sync()\nfollowing a successful qca_setup() calls hdev-\u003eclose() but not\nhdev-\u003eshutdown(), so the port is closed while power-\u003evregs_on is left true.\nqca_serdev_remove() then passes its power-\u003evregs_on test and calls\nqca_power_off(), which writes to the closed port unconditionally.\n\nSeen on a WCN3988 by unbinding the driver after a controller failure. The\ntrace below is from a 7.0.0 based kernel, where qca_power_off() was still\nnamed qca_power_shutdown():\n\n Unable to handle kernel NULL pointer dereference at virtual address\n 0000000000000038\n Call trace:\n tty_set_termios+0x50/0x238 (P)\n ttyport_set_baudrate+0x84/0xc0\n serdev_device_set_baudrate+0x24/0x40\n qca_power_shutdown+0x158/0x1fc [hci_uart]\n qca_serdev_remove+0x54/0x68 [hci_uart]\n serdev_drv_remove+0x1c/0x2c\n device_remove+0x4c/0x80\n device_release_driver_internal+0x1cc/0x224\n device_driver_detach+0x18/0x24\n unbind_store+0xb4/0xc0\n\nCheck HCI_UART_PROTO_READY, which hci_uart_close() clears in the same place\nit closes the port, before writing to it. The regulator disable is left\nunconditional so the controller is still powered down.\n\nThe dangling serport-\u003etty that turns this into a use-after-free is\naddressed in a separate patch.\n\nFixes: fa9ad876b8e0 (\"Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990\")\nSigned-off-by: Ibrahim Abdelkader \u003ciabdelka@qti.qualcomm.com\u003e\nReviewed-by: Hans de Goede \u003cjohannes.goede@oss.qualcomm.com\u003e\nSigned-off-by: Hans de Goede \u003cjohannes.goede@oss.qualcomm.com\u003e\n" }, { "commit": "ca10117e55dff28a2da9a95b8e8e798c99a01cf9", "tree": "0320bb4e808e43263240a34c1c9ffda8d87fd293", "parents": [ "803d146cd56b64b0ec918fd73a68bb1ee36288ba" ], "author": { "name": "Jeremy Dean", "email": "deaner92@yahoo.com", "time": "Tue Aug 25 12:22:07 2026 +0000" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Sep 10 15:39:41 2026 -0400" }, "message": "Bluetooth: Fix code style error\n\ncheckpatch.pl flags the zero-length array members in struct\nqca_dump_hdr:\n\n ERROR: Use C99 flexible arrays - see\n https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays\n #3110: FILE: drivers/bluetooth/btusb.c:3110:\n + u8 data0[0];\n\nReplace them with DECLARE_FLEX_ARRAY(), since C99 flexible array\nmembers are not permitted inside unions or as the sole member of\na struct.\n\nThe struct layout is unchanged, and everything compiles with the\nchange.\n\nLink: https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays\nSigned-off-by: Jeremy Dean \u003cdeaner92@yahoo.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "803d146cd56b64b0ec918fd73a68bb1ee36288ba", "tree": "b0604679b6e76e0c339d8c5219d2aa457d484af1", "parents": [ "1b737f2ef1686d0e5a7661eaeb097aad53ea7040" ], "author": { "name": "Laxman Acharya Padhya", "email": "acharyalaxman8848@gmail.com", "time": "Mon Aug 24 21:42:36 2026 +0545" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Sep 10 15:39:36 2026 -0400" }, "message": "Bluetooth: hci_codec: validate vendor codec count length\n\nThe Read Local Supported Codecs parsers consume the variable-sized\nstandard codec array before parsing the vendor codec count. Although the\ninitial reply-size check includes a vendor count byte in the fixed layout,\nit does not guarantee that the byte remains after the standard codec array.\n\nIf a controller reply ends immediately after that array, calculating the\nvendor codec array size reads vnd_codecs-\u003enum beyond the skb data. Use\nskb_pull_data() to validate and consume each codec header before using its\ncount in both command variants.\n\nFixes: 8961987f3f5f (\"Bluetooth: Enumerate local supported codec and cache details\")\nFixes: 9ae664028a9e (\"Bluetooth: Add support for Read Local Supported Codecs V2\")\nCc: stable@vger.kernel.org\nSuggested-by: Luiz Augusto von Dentz \u003cluiz.dentz@gmail.com\u003e\nSigned-off-by: Laxman Acharya Padhya \u003cacharyalaxman8848@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "1b737f2ef1686d0e5a7661eaeb097aad53ea7040", "tree": "f37056328e28005c598e01677c96aff4e8964e5a", "parents": [ "4a7b93f08d1318fab55450de60c74567c7a8e65d" ], "author": { "name": "Chris Lu", "email": "chris.lu@mediatek.com", "time": "Wed Sep 09 20:00:11 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 09 15:33:56 2026 -0400" }, "message": "Bluetooth: btmtk: Replace magic numbers with WMT packet flag enum\n\nThe flag field of a BTMTK_WMT_PATCH_DWNLD packet tells the device where\nthe packet sits in the download sequence, but both download loops write\nthe bare values 1, 2 and 3, so the reader has to infer the meaning from\nthe surrounding conditionals.\n\nAdd enum btmtk_wmt_pkt_flag and use it in btmtk_setup_firmware_79xx()\nand btmtk_setup_firmware(). No functional change.\n\nThe other bare flag values in this driver belong to different WMT\nopcodes (BTMTK_WMT_FUNC_CTRL, BTMTK_WMT_RST, BTMTK_WMT_SEMAPHORE and so\non), where the field means something else entirely, so they are left\nalone.\n\nSigned-off-by: Chris Lu \u003cchris.lu@mediatek.com\u003e\nReviewed-by: Paul Menzel \u003cpmenzel@molgen.mpg.de\u003e\nAssisted-by: Claude:claude-opus-5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "4a7b93f08d1318fab55450de60c74567c7a8e65d", "tree": "29d81721559b4e9ea7d112afb9c329fe13e0a55c", "parents": [ "71147d59cb230e337e14e762796dbfab253e0c3e" ], "author": { "name": "Chris Lu", "email": "chris.lu@mediatek.com", "time": "Wed Sep 09 20:00:10 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 09 15:33:51 2026 -0400" }, "message": "Bluetooth: btmtk: Improve BT firmware logging\n\nThe firmware log line in btmtk_setup_firmware_79xx() never says which\nfile was requested, which matters because btmtk_fw_get_filename() derives\nthe name from the device id and firmware version at runtime. It reports\nthe firmware\u0027s own hwver field as the HW version, when the device id the\ndriver read from the chip is the more useful value and is already\navailable as dev_id. And it prints datetime, a u8[16] with no guaranteed\nNUL terminator, with %s.\n\nLog the filename before the image is parsed, so a file that fails\nvalidation still says which file it was, report dev_id as the HW version,\nand bound datetime with %.16s.\n\nThe datetime change is hardening rather than a fix, hence no Fixes: tag:\nevery file in linux-firmware terminates the field, and provoking the\nover-read needs a malformed file in /lib/firmware.\n\nLog output on MT7922 after the change:\n\n [ 365.245951] Bluetooth: hci0: Loading BT firmware: mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin\n [ 365.245956] Bluetooth: hci0: BT HW ver: 0x7922, SW ver: 0x008a, Build Time: 20260605203811\n\nSigned-off-by: Chris Lu \u003cchris.lu@mediatek.com\u003e\nAssisted-by: Claude:claude-opus-5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "71147d59cb230e337e14e762796dbfab253e0c3e", "tree": "06970362edf30f7507cdffa8b91a3217926122af", "parents": [ "c2daf81dc275dd9605d5f5fede2629add3201c67" ], "author": { "name": "Chris Lu", "email": "chris.lu@mediatek.com", "time": "Wed Sep 09 20:00:09 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 09 15:33:46 2026 -0400" }, "message": "Bluetooth: btmtk: Validate the firmware layout before parsing it\n\nbtmtk_setup_firmware_79xx() reads the section count out of the firmware\u0027s\nglobal descriptor, then walks a 64-byte section map per section and hands\neach section\u0027s file-supplied offset and length to the WMT download path.\nNone of that is checked against fw-\u003esize, so a truncated or corrupted\nfile makes the driver read past the end of request_firmware()\u0027s buffer.\nOn 32-bit the section count can also wrap the section map size\ncalculation.\n\nAdd btmtk_fw_validate_layout() to check that the header, global\ndescriptor and section map array all fit, and btmtk_fw_validate_section()\nto check one section\u0027s offset and length, both written so the size\narithmetic cannot wrap. A section count of zero is rejected as well: it\npasses every size check but leaves the download loop with nothing to do,\nso the function would report success on hardware it never programmed.\nThey are helpers rather than open-coded because the MT7928 CBMCU download\npath added later needs the same arithmetic.\n\nThis is hardening against a corrupted /lib/firmware rather than a bug an\nunprivileged user can trigger, hence bluetooth-next and no Fixes: tag.\nWell-formed firmware files are unaffected.\n\nSigned-off-by: Chris Lu \u003cchris.lu@mediatek.com\u003e\nAssisted-by: Claude:claude-opus-5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "c2daf81dc275dd9605d5f5fede2629add3201c67", "tree": "c16c3ed94284c9d440dd997ba5e29c42bc62aafb", "parents": [ "e35544d233597e4b31b7467ccf53fe841996ed83" ], "author": { "name": "Adriano Cordova", "email": "adrianox@gmail.com", "time": "Tue Sep 08 13:54:13 2026 -0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 09 15:30:44 2026 -0400" }, "message": "Bluetooth: bnep: linearize skb before sending\n\nkernel_sendmsg expects contiguous data. Linearize the skb in the\nbnep_session() loop, before bnep_tx_frame builds its kvec, so it\nis not split across non-linear pages. Drop the dead block and\nFIXME.\n\nSigned-off-by: Adriano Cordova \u003cadrianox@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "e35544d233597e4b31b7467ccf53fe841996ed83", "tree": "d9a9f47190c139ca003acc92a1f31aaaa91065eb", "parents": [ "fb3a817741b1134e59f413784e4f579466047e1c" ], "author": { "name": "Radek Podgorny", "email": "radek@podgorny.cz", "time": "Wed Sep 09 00:29:37 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 09 12:29:04 2026 -0400" }, "message": "Bluetooth: put the peer\u0027s on-air address on air when we cannot resolve\n\nAn identity address only reaches a peer that is advertising an RPA if the\ncontroller resolves it on our behalf. Where it cannot, the host has to put\nthe peer\u0027s on-air address on air itself.\n\nhci_connect_le() still swaps the caller\u0027s identity address for the peer\u0027s\ncached RPA before creating the connection, but __hci_conn_add() resolves\nthe RPA back to the identity address when it stores it, so the identity is\nwhat goes out. Storing the identity is right when the controller\ntranslates it on the way to the radio; without LL Privacy, or with this\npeer absent from the resolving list, nothing does.\n\nA peer advertising an RPA cannot answer its identity address, so the\nattempt burns a full create-connection timeout. That is not merely a slow\nconnect: a controller without extended scanning cannot scan while it is\ninitiating, so every dead attempt also takes the scanner off the air for\nthe whole timeout.\n\nMeasured on a CYW43438, which reports neither LL Privacy nor extended\nadvertising (LE features 3f 00 00 08 00 00 00 00), against a peer\nadvertising a resolvable private address the host holds the IRK for, with\nthe connection requested on the peer\u0027s identity address:\n\n before: LE Create Connection to the identity address, public type\n 1.61s -\u003e 22.07s, then LE Create Connection Cancel\n LE Connection Complete: Unknown Connection Identifier (0x02)\n after: LE Create Connection to the peer\u0027s RPA, random type\n LE Connection Complete: Success\n\nAdvertising reports reaching the host per second, same window, same five\nunrelated devices on the adapter:\n\n before 1s:2 [nothing from 2s through 21s] 22s:5 23s:3\n after 0s:11 1s:5 2s:2 3s:5 4s:3 5s:4 ... 21s:2 22s:1 23s:2\n\nOne dead connect costs twenty seconds of scanning for every device on the\nadapter, not just the one being dialled.\n\nKeep the RPA in conn-\u003edst unless the controller will translate the\nidentity address: address resolution enabled and the peer\u0027s identity\nactually programmed into the resolving list. Testing ll_privacy_capable()\nalone would not be enough: it reports the feature bit, not whether\nresolution is switched on and not whether this peer is in the list.\nResolution is cleared with the other volatile flags on power-off and\nswitched off again while suspend pauses scanning, and a peer\u0027s IRK is only\nprogrammed along the accept list path, so a direct-connect target, a peer\nwithout HCI_CONN_FLAG_ADDRESS_RESOLUTION, and one that did not fit in a\nfull list are all absent from it.\n\nWith the peer programmed, the identity address stays in conn-\u003edst and the\ncontroller translates it: measured on an Intel controller, the host dials\nthe identity and LE Enhanced Connection Complete reports Resolved Public\nwith the peer\u0027s RPA in the separate peer resolvable private address field.\nWith the peer absent from the list the same setup dials the RPA itself.\n\nEverything downstream already copes with an RPA in conn-\u003edst: it is what\nevery outgoing LE connection stored before 14b06c3a88f7, the connection\ncomplete event names the address that was dialled, and\nle_conn_complete_evt() resolves it back to the identity once the link is\nup. ISO links keep the unconditional conversion: they are created from an\nexisting ACL or a periodic sync and never dial this address themselves.\n\nKeeping the RPA is only right while the peer is still using it, which is\nwhy the preceding patch drops the cached RPA as soon as the peer is seen\nadvertising its identity address. Without that, a peer that turns privacy\noff would be dialled on the address it abandoned rather than the one it\nis answering on.\n\nFixes: 14b06c3a88f7 (\"Bluetooth: HCI: Always use the identity address when initializing a connection\")\nAssisted-by: Claude:claude-opus-5\nAssisted-by: Claude:claude-fable-5\nSigned-off-by: Radek Podgorny \u003cradek@podgorny.cz\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "fb3a817741b1134e59f413784e4f579466047e1c", "tree": "240ec17883244f4eee1537832ba4799203dc1c3b", "parents": [ "701ca71884b3d101fd25b7adbf972355056ef352" ], "author": { "name": "Radek Podgorny", "email": "radek@podgorny.cz", "time": "Wed Sep 09 00:29:36 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 09 12:28:59 2026 -0400" }, "message": "Bluetooth: forget a peer\u0027s RPA once it advertises its identity address\n\nhci_connect_le() dials the RPA cached in the peer\u0027s IRK whenever one is\nset, on the assumption that a peer holding an IRK is on air with a\nresolvable private address. A peer that stops using privacy breaks that\nassumption: it advertises its identity address, the cached RPA keeps the\nvalue it had before the change, and the host aims at an address the peer\nhas abandoned.\n\nNothing clears the cache. hci_find_irk_by_rpa() refreshes irk-\u003erpa each\ntime an advertisement resolves, so it tracks rotation, but a peer that\nstops sending RPAs stops producing the reports that would update it, and\nthe stale address then survives until the adapter is powered off.\n\nOn the path that creates the connection object this is currently masked:\n__hci_conn_add() resolves the cached RPA back to the identity address, so\nthat is what goes on air. It is not masked on the reuse branch, which\ncopies the swapped address straight into an existing conn-\u003edst, and the\nnext patch removes the conversion for the case where the controller\ncannot translate an identity address, so the stale RPA would be dialled\nthere too.\n\nClear the cached RPA when the peer is seen on its identity address.\nhci_find_irk_by_addr() only matches public and static random addresses,\nso an unresolved RPA belonging to some other device cannot reach this\npath.\n\nAssisted-by: Claude:claude-opus-5\nSigned-off-by: Radek Podgorny \u003cradek@podgorny.cz\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "701ca71884b3d101fd25b7adbf972355056ef352", "tree": "966eb9c3ea7ed992081fd1a107afef5f9e504825", "parents": [ "9c7071e63e87a6ee0f11b028a8ecfe639294af3a" ], "author": { "name": "Weiming Shi", "email": "bestswngs@gmail.com", "time": "Sun Sep 06 23:43:32 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 12:18:45 2026 -0400" }, "message": "Bluetooth: coredump: Quiesce dump work on unregister\n\nhci_devcd_handle_pkt_init() arms dump_timeout and coredump producers\nqueue dump_rx without holding an hdev reference. Unregister leaves both\nworks live, so disconnecting during an active dump lets them access hdev\nafter hci_release_dev() frees it.\n\nShut down coredump processing during unregister. Close the producer gate\nunder dump_q.lock before disabling both works, then free the active buffer\nand queued packets under hci_dev_lock. Serializing the gate with enqueue\nprevents controller-specific workers from adding packets after the final\npurge.\n\nFixes: 9695ef876fd1 (\"Bluetooth: Add support for hci devcoredump\")\nReported-by: syzbot+b170dbf55520ebf5969a@syzkaller.appspotmail.com\nCloses: https://syzkaller.appspot.com/bug?extid\u003db170dbf55520ebf5969a\nReported-by: Aby Sam Ross \u003cabysamross@gmail.com\u003e\nLink: https://lore.kernel.org/r/20260322210849.68743-1-abysamross@gmail.com\nSuggested-by: Aby Sam Ross \u003cabysamross@gmail.com\u003e\nReported-by: Tristan Madani \u003ctristan@talencesecurity.com\u003e\nLink: https://lore.kernel.org/r/20260814231248.3096377-1-tristmd@gmail.com\nReported-by: Xiang Mei \u003cxmei5@asu.edu\u003e\nAssisted-by: OpenAI Codex:gpt-5\nSigned-off-by: Weiming Shi \u003cbestswngs@gmail.com\u003e\nReported-by: Xiang Mei \u003cxmei5@asu.edu\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "9c7071e63e87a6ee0f11b028a8ecfe639294af3a", "tree": "e4a240b191545168960710085c53e8dc4744a1c7", "parents": [ "ea6d8993c9107e3389ccc7a2c44ba48748a37a62" ], "author": { "name": "Samuel Alhovuori", "email": "samuel.alhovuori@gmail.com", "time": "Sat Sep 05 22:57:46 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 12:18:24 2026 -0400" }, "message": "Bluetooth: btusb: Add device ID for MediaTek MT7925 (13d3:3631)\n\nAdd the USB ID 13d3:3631 for the MediaTek MT7925 Bluetooth module\nfound on AzureWave / Mercusys MA37BE PCIe Wi-Fi 7 cards.\n\nT: Bus\u003d01 Lev\u003d02 Prnt\u003d04 Port\u003d03 Cnt\u003d03 Dev#\u003d 7 Spd\u003d480 MxCh\u003d 0\nD: Ver\u003d 2.10 Cls\u003def(misc ) Sub\u003d02 Prot\u003d01 MxPS\u003d64 #Cfgs\u003d 1\nP: Vendor\u003d13d3 ProdID\u003d3631 Rev\u003d 1.00\nS: Manufacturer\u003dMediaTek Inc.\nS: Product\u003dWireless_Device\n\nReviewed-by: Paul Menzel \u003cpmenzel@molgen.mpg.de\u003e\nSigned-off-by: Samuel Alhovuori \u003csamuel.alhovuori@pm.me\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "ea6d8993c9107e3389ccc7a2c44ba48748a37a62", "tree": "52b73fe2cacf983c5ea421359b5ab5861d45c14f", "parents": [ "88906c2d5b21349b8621a634f4850f6dc48c282c" ], "author": { "name": "Kiran K", "email": "kiran.k@intel.com", "time": "Tue Sep 08 19:04:21 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 12:18:02 2026 -0400" }, "message": "Bluetooth: btintel_pcie: cap device debug regions at 1 MB\n\nValidate device-supplied debug-region boundaries during mailbox TLV\nparsing and convert start/end values to a validated region size. Cap\ndebug-region sizes to 1 MB to prevent out-of-bounds reads if firmware\nreports oversized memory ranges. Skip invalid or oversized regions\nprior to coredump capture.\n\nThis issue was reported by Claude Mythos.\n\nFixes: 87e8561bf73a (\"Bluetooth: btintel_pcie: unified decoder coredump format\")\nAssisted-by: Copilot:claude-opus-4.7\nSigned-off-by: Kiran K \u003ckiran.k@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "88906c2d5b21349b8621a634f4850f6dc48c282c", "tree": "e7f0660814454d1bb4292248c7c132f33b005763", "parents": [ "1d978753498a22e7b459cf42777e86fd408374ce" ], "author": { "name": "Chandrashekar Devegowda", "email": "chandrashekar.devegowda@intel.com", "time": "Tue Sep 08 15:26:58 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 12:17:41 2026 -0400" }, "message": "Bluetooth: btintel_pcie: validate TX skb length in send_sync\n\nbtintel_pcie_prepare_tx() copies skb-\u003elen bytes into a fixed\nBTINTEL_PCIE_BUFFER_SIZE (4096) DMA slot via an unchecked memcpy.\nOversized packets are currently rejected only in\nbtintel_pcie_send_frame(); any future caller of\nbtintel_pcie_send_sync() would silently overflow the DMA buffer.\n\nAdd the bounds check in btintel_pcie_send_sync() itself, right\nbefore skb_push() and the DMA copy.\n\nAssisted-by: Copilot:claude-sonnet-5 code-review code-generation\nFixes: 6e65a09f9275 (\"Bluetooth: btintel_pcie: Add *setup* function to download firmware\")\nSigned-off-by: Chandrashekar Devegowda \u003cchandrashekar.devegowda@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "1d978753498a22e7b459cf42777e86fd408374ce", "tree": "63fb296688c0528511c2a12b06aa48224c83ff45", "parents": [ "676cc47454c4cabe3b27fce0fb3ee06f023490c5" ], "author": { "name": "Xuhua Zhang", "email": "zhangxuhua@kylinsec.com.cn", "time": "Mon Sep 07 23:12:45 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 12:01:52 2026 -0400" }, "message": "Bluetooth: hci_ll: Sleep while waiting for the controller to power up\n\nll_setup() busy-waits for 100 ms after asserting the controller enable\nGPIO on each firmware download attempt. With retries this can occupy\nthe CPU for up to 400 ms.\n\nThe setup callback runs in sleepable context and already uses msleep(),\ngpiod_set_value_cansleep() and synchronous firmware commands. Replace\nmdelay(100) with msleep(100) so the CPU can run other work during the\npower-up delay. Keep the requested delay and subsequent CTS wait.\n\nSigned-off-by: Xuhua Zhang \u003czhangxuhua@kylinsec.com.cn\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "676cc47454c4cabe3b27fce0fb3ee06f023490c5", "tree": "9ac94f39b4c08809b03de913f51e150585b438be", "parents": [ "0010ea1bd14d1253505b6d6213a91e9bc02c09df" ], "author": { "name": "Xuhua Zhang", "email": "zhangxuhua@kylinsec.com.cn", "time": "Mon Sep 07 23:08:08 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 12:01:47 2026 -0400" }, "message": "Bluetooth: hci_h5: Avoid clearing the escape bit for ordinary bytes\n\nh5_unslip_one_byte() calls test_and_clear_bit() for every byte other than\nan initial SLIP escape byte, even when H5_RX_ESC is already clear. This\nperforms an unnecessary atomic read-modify-write on the ordinary-byte\nreceive path. On x86, it emits a locked btr instruction for each such\nbyte.\n\nTest H5_RX_ESC first and clear it only when consuming an escaped byte.\nHandle an initial SLIP escape byte in the alternative branch. The HCI\nUART receive callbacks are serialized by the TTY layer, and H5_RX_ESC\nis only changed by receive processing and initialization, so there is\nno need to atomically test and clear it in one operation.\n\nKeep set_bit() and clear_bit() atomic because other bits in h5-\u003eflags\ncan be updated by the transmit path concurrently. Escape decoding and\ninvalid-escape recovery remain unchanged.\n\nSigned-off-by: Xuhua Zhang \u003czhangxuhua@kylinsec.com.cn\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "0010ea1bd14d1253505b6d6213a91e9bc02c09df", "tree": "465031863d80c85845a06797676470da2cea508b", "parents": [ "30962c917c475fb78a45573386c57f84db540232" ], "author": { "name": "ThangNN99", "email": "ngocthang2710.1999@gmail.com", "time": "Sun Sep 06 22:21:27 2026 +0700" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 12:01:43 2026 -0400" }, "message": "Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained\n\nhci_send_acl(), hci_send_sco() and hci_send_iso() queue hdev-\u003etx_work\nunconditionally. They can run from the L2CAP/SCO/ISO socket send path\nwhile hci_dev_close_sync() is draining hdev-\u003eworkqueue (HCIDEVDOWN\nracing with a socket write). Since that queue_work() is not chained\nwork from the tx_work worker itself, __queue_work() sees the queue\nmarked __WQ_DRAINING, warns \"cannot queue %ps on wq %s\", and drops\nthe work:\n\n WARNING: CPU: 1 PID: 5985 at kernel/workqueue.c:2352 __queue_work\n Call Trace:\n queue_work_on\n l2cap_chan_send\n l2cap_sock_sendmsg\n ...\n\nhci_dev_close_sync() already sets HCI_CMD_DRAIN_WORKQUEUE before\ndraining, but only hci_cmd_work() and handle_cmd_cnt_and_timer()\ncheck it before queuing. Route the tx_work producers through the\nsame guard via a shared hci_sched_tx() helper.\n\nFixes: 525daaea459f (\"Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close\")\nReported-by: syzbot+b6919040d9958e2fc1ae@syzkaller.appspotmail.com\nCloses: https://syzkaller.appspot.com/bug?extid\u003db6919040d9958e2fc1ae\nSigned-off-by: ThangNN99 \u003cngocthang2710.1999@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "30962c917c475fb78a45573386c57f84db540232", "tree": "4707e50d2c0fd21b6211dbacccc4d35eeb650a2b", "parents": [ "334ddae615d8fd91fdd958c5cfede2596ad0568e" ], "author": { "name": "Xuhua Zhang", "email": "zhangxuhua@kylinsec.com.cn", "time": "Mon Sep 07 23:10:15 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 12:01:38 2026 -0400" }, "message": "Bluetooth: hci_bcsp: Use the shared CRC-CCITT byte helper\n\nbcsp_crc_update() processes each byte as two nibbles, requiring two\ndependent table lookups for every header and payload byte when CRC is\nenabled.\n\nThe existing crc_ccitt_byte() helper implements the same reflected\npolynomial with one lookup per byte. Use it instead of the private\nnibble-based implementation and select CRC_CCITT for BCSP-only UART\nconfigurations as well. The initial CRC value and final bit reversal\nremain unchanged.\n\nThis replaces the private 16-entry table with the shared 256-entry table,\ntrading table size for fewer dependent lookups. An exhaustive comparison\nof all 65536 CRC states and 256 input bytes matches both the old code and\na bitwise reference implementation.\n\nSigned-off-by: Xuhua Zhang \u003czhangxuhua@kylinsec.com.cn\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "334ddae615d8fd91fdd958c5cfede2596ad0568e", "tree": "14ccedd14103f78beb177f166d6436f909f6592d", "parents": [ "bd5e3aa5d35ac08126d0d7b80560ebb64a954110" ], "author": { "name": "Aamir Ahmed", "email": "elb12345@hotmail.co.uk", "time": "Mon Sep 07 00:37:43 2026 +0100" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 12:01:33 2026 -0400" }, "message": "Bluetooth: eir: validate service data length before reading UUID\n\neir_get_service_data() reads a 16-bit UUID from the service data using\nget_unaligned_le16() without first checking that the data is long enough\nto hold a UUID16 (2 bytes). If a malformed EIR entry has a service data\nfield with only 1 byte of payload (field_len\u003d2), eir_get_data() returns\ndlen\u003d1. The subsequent get_unaligned_le16() then reads 1 byte past the\nfield boundary.\n\nAdditionally, if the corrupted UUID happens to match, the length\ncalculation \"dlen - 2\" underflows to SIZE_MAX since dlen is size_t.\nCurrent callers either pass NULL for the length parameter or bounds-check\nthe returned length, but future callers may not.\n\nAdd a check that dlen \u003e\u003d sizeof(u16) and skip fields that are too short\nto contain a valid UUID16.\n\nFixes: 8f9ae5b3ae80 (\"Bluetooth: eir: Add helpers for managing service data\")\nCc: stable@vger.kernel.org\nSigned-off-by: Aamir Ahmed \u003celb12345@hotmail.co.uk\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "bd5e3aa5d35ac08126d0d7b80560ebb64a954110", "tree": "b6828fc58bceb222c72124d75460c1a051243e7d", "parents": [ "76b8d73b706e2b00787c835b87c658adba1391ba" ], "author": { "name": "Nicolas Thibert", "email": "nithibert@gmail.com", "time": "Tue Sep 08 10:01:08 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 12:01:29 2026 -0400" }, "message": "Bluetooth: btusb: fix NXP IW610 composite device handling\n\nThe NXP IW610 module exposes itself as a composite USB device\n(0471:0215) with three interfaces: two real Bluetooth HCI interfaces\n(class 0xe0) and one vendor-specific WiFi interface (class 0xff) used\nby mwifiex-nxp.\n\nThe composite device\u0027s whole USB descriptor reports class 0xe0/01/01\n(Bluetooth), so btusb_table\u0027s generic USB_DEVICE_INFO(0xe0, 0x01, 0x01)\nentry matches every interface, not just the two real HCI ones -- btusb\nends up binding the WiFi interface too, and mwifiex-nxp never gets it.\n\nFix:\n1. In btusb_table (the table the USB core actually matches against),\n explicitly ignore the WiFi interface via BTUSB_IGNORE, ahead of the\n generic entry.\n2. In quirks_table, scope the existing BTUSB_MARVELL entry to the BT\n interface class instead of matching the whole device by VID/PID\n (harmless either way since quirks_table isn\u0027t consulted for initial\n binding, but keep it correct).\n\nNot upstream anywhere: checked NXP\u0027s own i.MX kernel fork\n(nxp-imx/linux-imx), no IW610 references in btusb.c on any branch --\ntheir reference designs wire this chip differently (WiFi over SDIO\nper their release notes), so they never hit this.\n\nSigned-off-by: Nicolas Thibert \u003cnithibert@gmail.com\u003e\nCc: stable@vger.kernel.org\nAssisted-by: LLM (Claude Sonnet 5, Anthropic)\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "76b8d73b706e2b00787c835b87c658adba1391ba", "tree": "87ed40ed8ab80044ccc96133e9668819b498d1a1", "parents": [ "87e8561bf73a426f1c4ac63ddc76f63bb035585e" ], "author": { "name": "Nikolaj Klitlund Børty", "email": "nbn@sj.dk", "time": "Sat Sep 05 14:05:12 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 12:01:24 2026 -0400" }, "message": "Bluetooth: btusb: Add device ID for Realtek RTL8761BUE (StarTech AV53C1)\n\nAdd the USB ID 0x14b0:0x047a for the StarTech AV53C1-USB-BLUETOOTH\nadapter, a Realtek RTL8761BUE based Bluetooth 5.3 dongle.\n\nWithout this entry btusb treats the device as a generic Bluetooth\nadapter and never loads the Realtek firmware, leaving the controller on\nits ROM firmware. In that state it advertises and scans actively, but\nnever reports advertisements during passive scanning. LE connections\ninitiated by the kernel wait for a passive-scan report before issuing\nLE Create Connection, so connecting and pairing from BlueZ time out\nwithout any error from the controller.\n\nThe same product is also sold with the ID 0x2c0a:0x8761, which is\nalready supported.\n\nlsusb -v output for the device:\n\nBus 001 Device 010: ID 14b0:047a StarTech.com Ltd. Bluetooth Radio\nDevice Descriptor:\n bcdUSB 1.10\n bDeviceClass 224 Wireless\n bDeviceSubClass 1 Radio Frequency\n bDeviceProtocol 1 Bluetooth\n idVendor 0x14b0 StarTech.com Ltd.\n idProduct 0x047a\n bcdDevice 2.00\n iManufacturer 1 Realtek\n iProduct 2 Bluetooth Radio\n iSerial 3 00E04C239987\n bNumInterfaces 2\n Interface Descriptor:\n bInterfaceClass 224 Wireless\n bInterfaceSubClass 1 Radio Frequency\n bInterfaceProtocol 1 Bluetooth\n\nCc: stable@vger.kernel.org\nSigned-off-by: Nikolaj Klitlund Børty \u003cnbn@sj.dk\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "87e8561bf73a426f1c4ac63ddc76f63bb035585e", "tree": "591ea5cd750bdf670f7e44f52c425d04841a1bf4", "parents": [ "d59cac13c57128c2e5de4c4bef144ed52ed3b1da" ], "author": { "name": "Chandrashekar Devegowda", "email": "chandrashekar.devegowda@intel.com", "time": "Fri Sep 04 05:59:38 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 11:58:43 2026 -0400" }, "message": "Bluetooth: btintel_pcie: unified decoder coredump format\n\nReplace the legacy TLV-based coredump with a unified INI-format dump\ncompatible with the iwlwifi decoder so a single decoder can parse\ncoredumps across all Intel BT PCIe controller variants.\n\nThe dump is emitted via dev_coredumpsg() as structured regions built\nfrom firmware-advertised addresses: DRAM monitor buffers (single or\nMDBGC multi-buffer), SMEM monitor, exception event buffer, DCCM, SDS,\nSDS IOSF, ECL and dump info metadata. Regions are collected only when\nfirmware advertises a valid address and size, and only collected\nregions are advertised in regions_mask.\n\nAdd INTEL_CNVX_TOP_DASH() and INTEL_CNVX_TOP_FLAVOR() helpers to\nbtintel.h for RfIdDash/RfIdFlavor extraction.\n\nAssisted-by: Copilot:gemini-3.6-flash\nSigned-off-by: Chandrashekar Devegowda \u003cchandrashekar.devegowda@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "d59cac13c57128c2e5de4c4bef144ed52ed3b1da", "tree": "5bc5388b311943c4bfd23714c9fd695f34ef3aab", "parents": [ "eacbfff1623773e5f13ca30b7e31d7bfa175f9c7" ], "author": { "name": "Chandrashekar Devegowda", "email": "chandrashekar.devegowda@intel.com", "time": "Fri Sep 04 05:59:37 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 09:17:22 2026 -0400" }, "message": "Bluetooth: btintel_pcie: add MDBGC multi-buffer DBGC allocation\n\nNewer Intel BT PCIe variants (Nova Lake SCP2 and PTL FMP2) require\nthree independent DRAM debug (DBGC) buffer pools instead of the\nsingle pool used by existing controllers.\n\nFactor the per-pool buffer allocation into a common helper and add\na multi-DBGC (MDBGC) setup path that allocates three pools using\nthe fragment context format. MDBGC is used when the device reports\nan MDBGC-capable variant; otherwise the existing single-pool DBGC\npath is retained.\n\nAssisted-by: Copilot:claude-opus-4.7 sparse\nSigned-off-by: Chandrashekar Devegowda \u003cchandrashekar.devegowda@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "eacbfff1623773e5f13ca30b7e31d7bfa175f9c7", "tree": "a809ae1a5f118bf1bdde5c19200fddd0bae302ca", "parents": [ "6d437db48c7816d94a7c22e797667751877d0d5d" ], "author": { "name": "Jiajia Liu", "email": "liujiajia@kylinos.cn", "time": "Fri Sep 04 16:03:51 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 09:17:17 2026 -0400" }, "message": "Bluetooth: btusb: Fix leaked runtime PM reference in btusb_reset\n\nbtusb_reset calls usb_autopm_get_interface to resume the device\nbefore queuing a reset of it, but never calls the matching\nusb_autopm_put_interface.\n\nusb_queue_reset_device ends up in usb_reset_device(), and since\nbtusb provides no pre_reset/post_reset callbacks the interface is\nmerely unbound and rebound: the interface device object survives\nthis cycle, and so does its PM usage count, which is not cleared\nwhen the driver is unbound.\n\nAs a result every reset permanently leaks a PM usage reference,\npreventing the interface from being runtime suspended again until\nit is unbound.\n\nSet BTUSB_RESET flag before usb_queue_reset_device so that\nbtusb_disconnect drops the reference. If the flag is already set,\ndrop one reference.\n\nFixes: c9209b269afd (\"Bluetooth: btusb: Introduce generic USB reset\")\nAssisted-by: Claude:qwen3.8-max\nSigned-off-by: Jiajia Liu \u003cliujiajia@kylinos.cn\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "6d437db48c7816d94a7c22e797667751877d0d5d", "tree": "3332fdb1fe72aa53fa113ba62ce7e6535ebc2b5e", "parents": [ "088ef4eaad98aa3a6a6feb49c5fb6d9f8bf79ede" ], "author": { "name": "Jiajia Liu", "email": "liujiajia@kylinos.cn", "time": "Fri Sep 04 16:03:50 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 09:17:10 2026 -0400" }, "message": "Bluetooth: btusb: mediatek: Fix leaked runtime PM reference in reset\n\nMT7925 on HP Pro Mini 260 sometimes timed out during reloading driver\nand reset usb device. btusb_suspend is not called again after closing\nbluetooth interface.\n\n usbcore: registered new interface driver btusb\n Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20260605184935\n Bluetooth: hci0: Execution of wmt command timed out\n Bluetooth: hci0: Failed to send wmt patch dwnld (-110)\n Bluetooth: hci0: Failed to set up firmware (-110)\n usb 3-10: reset high-speed USB device number 4 using xhci_hcd\n Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20260605184935\n Bluetooth: hci0: Device setup in 1856545 usecs\n Bluetooth: hci0: AOSP extensions version v1.00\n Bluetooth: hci0: AOSP quality report is supported\n Bluetooth: MGMT ver 1.23\n\nbtusb_mtk_reset calls usb_autopm_get_interface to resume the device\nbefore driving the hardware reset, but never calls the matching\nusb_autopm_put_interface. Every hardware reset therefore leaks a PM\nusage reference of the interface, preventing the device from being\nruntime suspended again until it is unbound.\n\nAdd the BTUSB_RESET flag. It is set before usb_queue_reset_device\nand is cleared in btusb_disconnect, which drops the reference as well.\nIf the flag is already set when a new reset is requested, drop one\nreference.\n\nAlso clear BTMTK_HW_RESET_ACTIVE if usb_autopm_get_interface fails,\notherwise no further reset could ever be attempted.\n\nFixes: 25b6d7593a3a (\"Bluetooth: btmtk: introduce btmtk reset work\")\nAssisted-by: Claude:qwen3.8-max\nSigned-off-by: Jiajia Liu \u003cliujiajia@kylinos.cn\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "088ef4eaad98aa3a6a6feb49c5fb6d9f8bf79ede", "tree": "d6cd8a6e90513ce8537d3dd60211ff5ce79c4743", "parents": [ "5e3e6617e6f18cbbca4e3b8e237f49ec2b0a1520" ], "author": { "name": "Xu Rao", "email": "raoxu@uniontech.com", "time": "Fri Sep 04 10:54:57 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 09:17:04 2026 -0400" }, "message": "Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev\n\nThe command and ACL RPMsg endpoints store struct btqcomsmd as their\ncallback private data. The receive callbacks dereference btq-\u003ehdev\nwithout taking an hci_dev reference.\n\nThe current teardown order frees the hci_dev before destroying the RPMsg\nendpoints in both the hci_register_dev() error path and the driver remove\npath. If WCNSS delivers data in that window, the endpoint callback can\nrun with an already freed hci_dev and pass it to the Bluetooth core.\n\nFor qcom_smd endpoints, rpmsg_destroy_ept() closes the channel and clears\nthe callback under the channel recv_lock. The receive path holds the same\nlock while invoking the callback, so destroying the endpoints first both\nprevents new callbacks and serializes with any callback already running.\n\nDestroy the command and ACL endpoints before hci_free_dev(). Keep\nhci_unregister_dev() first during remove so the HCI core stops issuing\noperations before the transport endpoints are shut down. In the full\nregistration-error cleanup path, return directly after freeing the hci_dev\nto avoid falling through to the partial-construction labels and destroying\nthe endpoints twice.\n\nFixes: 5052de8deff5 (\"soc: qcom: smd: Transition client drivers from smd to rpmsg\")\nFixes: 9a39a927be01 (\"Bluetooth: btqcomsmd: Fix a resource leak in error handling paths in the probe function\")\nCc: stable@vger.kernel.org\nAcked-by: Bartosz Golaszewski \u003cbartosz.golaszewski@oss.qualcomm.com\u003e\nReviewed-by: Dmitry Baryshkov \u003cdmitry.baryshkov@oss.qualcomm.com\u003e\nSigned-off-by: Xu Rao \u003craoxu@uniontech.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "5e3e6617e6f18cbbca4e3b8e237f49ec2b0a1520", "tree": "04da6f75165b211ca724322798b34d14b19275ff", "parents": [ "13e96569bf6a44664803614f938863488525dd29" ], "author": { "name": "Chandrashekar Devegowda", "email": "chandrashekar.devegowda@intel.com", "time": "Fri Sep 04 05:59:36 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 09:16:58 2026 -0400" }, "message": "Bluetooth: btintel_pcie: remove duplicate BTINTEL_PCIE_MAGIC_NUM definition\n\nTwo identical definitions of BTINTEL_PCIE_MAGIC_NUM were present in\nbtintel_pcie.c, one indented with spaces and one with a tab. Remove the\nspace-indented duplicate and the surrounding blank lines. Kernel coding\nstyle requires tabs for indentation, so keep the tab-indented copy.\n\nNo functional change.\n\nAssisted-by: Copilot:claude-opus-4.7 sparse\nFixes: 6ed83047389c (\"Bluetooth: btintel_pcie: Setup buffers for firmware traces\")\nSigned-off-by: Chandrashekar Devegowda \u003cchandrashekar.devegowda@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "13e96569bf6a44664803614f938863488525dd29", "tree": "beef992c6e92252bf9cac715a65dcaa1ea8768c6", "parents": [ "b361e99dd3fbdb09d1be8650bb52af8bacb43b1f" ], "author": { "name": "Krystian Kaniewski", "email": "krystianmkaniewski@gmail.com", "time": "Fri Sep 04 12:24:22 2026 +0000" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 09:16:50 2026 -0400" }, "message": "Bluetooth: hci_sysfs: Fix NULL pointer dereference in device_del()\n\nA NULL pointer dereference in klist_put() occurs when a child device (such\nas a BNEP network device in bnep_session) is concurrently being\nunregistered while hci_conn_del_sysfs() reparents child devices.\n\nThis is caused by a race condition between hci_conn_del_sysfs() and\nconcurrent child device unregistration (e.g. bnep_session calling\nunregister_netdev()). During device unregistration, device_del() snapshots\na non-NULL parent pointer. Concurrently, hci_conn_del_sysfs() finds the\nchild device using device_find_any_child() and calls device_move() to\nreparent it to NULL, which removes the node from its parent\u0027s klist and\nclears knode_parent. Subsequently, device_del() calls\nklist_del(\u0026dev-\u003ep-\u003eknode_parent) using the stale parent snapshot, causing\nklist_put() to dereference knode_klist(n)-\u003eput on an already removed node,\nresulting in a NULL pointer dereference.\n\nThis race was introduced by commit 27aabf27fd01 (\"Bluetooth: fix\nuse-after-free in device_for_each_child()\"), which replaced\ndevice_find_child(..., __match_tty) with device_find_any_child() in\nhci_conn_del_sysfs(). That change was intended to avoid a use-after-free\nwhere conn-\u003edev outlived its parent hdev-\u003edev when child devices held\nreferences to conn-\u003edev, because conn-\u003edev only held a reference to\nhdev-\u003edev while registered in sysfs.\n\nFix the issue properly by taking an explicit reference to the parent device\nwith get_device(\u0026hdev-\u003edev) in hci_conn_init_sysfs() and dropping it with\nput_device(parent) in bt_link_release() when the conn device is freed. This\nensures that hdev-\u003edev remains valid for the entire lifecycle of conn-\u003edev,\nresolving the underlying use-after-free. With the parent reference held\nproperly, restore the __match_tty filter in hci_conn_del_sysfs() so that\ndevice_move() is only invoked on persistent RFCOMM TTY devices as\noriginally intended, eliminating the race condition with unregistering\nnetwork devices.\n\nFixes: 27aabf27fd01 (\"Bluetooth: fix use-after-free in device_for_each_child()\")\nAssisted-by: Gemini:gemini-3.7-flash syzbot\nReported-by: syzbot+6df45dd3d03e1a9aca96@syzkaller.appspotmail.com\nCloses: https://syzkaller.appspot.com/bug?extid\u003d6df45dd3d03e1a9aca96\nLink: https://syzkaller.appspot.com/ai_job?id\u003df1c0e740-db21-40af-a9ff-84db0fd8b8bd\nSigned-off-by: Krystian Kaniewski \u003ckrystianmkaniewski@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "b361e99dd3fbdb09d1be8650bb52af8bacb43b1f", "tree": "ca01e16d6fc880078e1ef4ff26a7590a3eedcbb1", "parents": [ "8a6461651e912d3009a587d73ee6f4b7a51db826" ], "author": { "name": "Ivan Hu", "email": "ivan.hu@canonical.com", "time": "Fri Sep 04 13:30:07 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 09:16:39 2026 -0400" }, "message": "Bluetooth: btmtk: Declare MT7920 (MT7961 1a) Bluetooth firmware\n\nbtmtk_fw_get_filename() constructs the firmware name at runtime, so for\nthe MT7920 variant (dev_id 0x7961 with fw_flavor set) it requests\n\"mediatek/BT_RAM_CODE_MT7961_1a_2_hdr.bin\" without ever declaring it via\nMODULE_FIRMWARE(). Tools that select firmware from module metadata (e.g.\n\"modinfo -F firmware\") therefore omit this blob, so request_firmware()\nfails and Bluetooth does not initialise on MT7920, even though the file\nis present in linux-firmware.\n\nDeclare it with MODULE_FIRMWARE(), as the mt76 driver already does for\nthe corresponding MT7920 wifi firmware.\n\nFixes: 1cb63d80fff6 (\"Bluetooth: btusb: Add support Mediatek MT7920\")\nSigned-off-by: Ivan Hu \u003civan.hu@canonical.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "8a6461651e912d3009a587d73ee6f4b7a51db826", "tree": "e750d52d8920a75651d8aa7a69677678ccebea1f", "parents": [ "4a3d0a687de9ab6e333d588e85a25c187b1dcc89" ], "author": { "name": "Andy Chang", "email": "Andy.Chang@synaptics.com", "time": "Thu Sep 03 20:18:24 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 09:16:32 2026 -0400" }, "message": "Bluetooth: btbcm: Add Synaptics 4384 chip support\n\nAdd support for the Synaptics 4384 Bluetooth controller\nby adding the corresponding chip IDs.\n\nTested on the VIM3 platform. Verified that the controller initializes\nsuccessfully and that firmware loading and basic Bluetooth operation\nwork as expected.\n\nThe VIM3 is a Khadas single-board computer that I used as the host\nplatform for testing the BCM4384 Bluetooth controller.\n\nTest log:\n\n Bluetooth: hci0: BCM: chip id 206\n Bluetooth: hci0: BCM: features 0x0f\n Bluetooth: hci0: BCM4384B0\n Bluetooth: hci0: BCM4384B0 (002.001.025) build 0000\n Bluetooth: hci0: BCM4384B0 \u0027brcm/BCM4384B0.hcd\u0027 Patch\n Bluetooth: hci0: BCM: features 0x0f\n Bluetooth: hci0: BCM4384B0 AP6684P CN iPA [Version: 1030.1021]\n Bluetooth: hci0: BCM4384B0 (002.001.025) build 1021\n Bluetooth: hci0: BCM: Using default device address (43:84:b0:00:76:93)\n\nSigned-off-by: Andy Chang \u003cAndy.Chang@synaptics.com\u003e\nReviewed-by: Paul Menzel \u003cpmenzel@molgen.mpg.de\u003e\nReviewed-by: Linus Walleij \u003clinusw@kernel.org\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "4a3d0a687de9ab6e333d588e85a25c187b1dcc89", "tree": "91486641e3a3efe490a799b46d23ac93e573fa20", "parents": [ "88a8184cb44c8952e6a6fd21e250445300d1c7aa" ], "author": { "name": "Andy Chang", "email": "Andy.Chang@synaptics.com", "time": "Thu Sep 03 20:18:23 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 08 09:16:22 2026 -0400" }, "message": "Bluetooth: dt-bindings: net: bluetooth: add BCM4384\n\nAdd the brcm,bcm4384-bt compatible string to support the\nSynaptics BCM4384 Bluetooth controller.\n\nA fallback compatible is not suitable here because any operating system\nmust discern the proper firmware to drive this specific hardware\nrevision, and the compatible string fulfills that purpose.\n\nSigned-off-by: Andy Chang \u003cAndy.Chang@synaptics.com\u003e\nReviewed-by: Paul Menzel \u003cpmenzel@molgen.mpg.de\u003e\nReviewed-by: Linus Walleij \u003clinusw@linaro.org\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "88a8184cb44c8952e6a6fd21e250445300d1c7aa", "tree": "9f064ea94eb24002be68cf86fed1c0f03df09a76", "parents": [ "fe87a0e402c503c20f7063c7ac49feaa6e2edcbd" ], "author": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 02 13:16:26 2026 -0400" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Sep 03 15:33:03 2026 -0400" }, "message": "Bluetooth: hci_sync: Fix not setting CE length properly\n\nBoth hci_le_set_def_rate_sync() and hci_le_conn_rate_request_sync() were\nleaving Min_CE_Length and Max_CE_Length set to 0x0000, but the connection\nevent length recommended in requests by a Peripheral has a valid range of\n0x0001 to 0x7CFF (Time \u003d N * 125 us, Time Range: 0.125 ms to 3.999875 s),\nso 0x0000 cannot be used.\n\nSet both to the minimum valid value, which is safe since the Controller\nis not required to use these values:\n\nBLUETOOTH CORE SPECIFICATION Version 6.2 | Vol 4, Part E\n7.8.157. LE Connection Rate Request command\n7.8.158. LE Set Default Rate Parameters command\n\nThe Min_CE_Length and Max_CE_Length parameters provide the Controller\nwith the expected minimum and maximum length of the connection events.\nThe Controller is not required to use these values.\n\nFixes: 2f8784cfe8a9 (\"Bluetooth: Add support for Shorter Connection Interval (SCI) feature\")\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "fe87a0e402c503c20f7063c7ac49feaa6e2edcbd", "tree": "bb53b3587d403d525d9be696a6c1c09548c67d6c", "parents": [ "a8bfcece8b49a9d0c97b19c0101a1eb17a2bd6f8" ], "author": { "name": "Catherine L", "email": "catherine.l@intel.com", "time": "Wed Sep 02 19:00:37 2026 +0000" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Sep 03 15:32:59 2026 -0400" }, "message": "Bluetooth: btusb: Add support for Intel Otter Peak2 (OrP2)\n\n$ lsusb\nBus 003 Device 003: ID 8087:0043 Intel Corp.\n\n$ cat /sys/kernel/debug/usb/devices\nT: Bus\u003d03 Lev\u003d01 Prnt\u003d01 Port\u003d09 Cnt\u003d02 Dev#\u003d 3 Spd\u003d12 MxCh\u003d 0\nD: Ver\u003d 2.01 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 MxPS\u003d64 #Cfgs\u003d 1\nP: Vendor\u003d8087 ProdID\u003d0043 Rev\u003d 0.00\nC:* #Ifs\u003d 2 Cfg#\u003d 1 Atr\u003de0 MxPwr\u003d100mA\nI:* If#\u003d 0 Alt\u003d 0 #EPs\u003d 3 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 Driver\u003dbtusb\nE: Ad\u003d81(I) Atr\u003d03(Int.) MxPS\u003d 64 Ivl\u003d1ms\nE: Ad\u003d02(O) Atr\u003d02(Bulk) MxPS\u003d 64 Ivl\u003d0ms\nE: Ad\u003d82(I) Atr\u003d02(Bulk) MxPS\u003d 64 Ivl\u003d0ms\nI:* If#\u003d 1 Alt\u003d 0 #EPs\u003d 2 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 Driver\u003dbtusb\nE: Ad\u003d03(O) Atr\u003d01(Isoc) MxPS\u003d 0 Ivl\u003d1ms\nE: Ad\u003d83(I) Atr\u003d01(Isoc) MxPS\u003d 0 Ivl\u003d1ms\n\nSigned-off-by: Catherine L \u003ccatherine.l@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "a8bfcece8b49a9d0c97b19c0101a1eb17a2bd6f8", "tree": "e33c0902a9d0726d0bdf56809e6f107ad91e7ff6", "parents": [ "de8d29ede6f32e38c470ce53e1509e0a3d118546" ], "author": { "name": "Kiran K", "email": "kiran.k@intel.com", "time": "Thu Sep 03 20:21:02 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Sep 03 15:32:55 2026 -0400" }, "message": "Bluetooth: btintel_pcie: fix tx_handle bounds off-by-one\n\nValid indices into txq-\u003eurbd0s/tfds/bufs are 0..txq-\u003ecount-1, so\ntfd_index \u003d\u003d txq-\u003ecount is already out of range. Change the guard in\nbtintel_pcie_msix_tx_handle() from \u0027\u003e txq-\u003ecount\u0027 to \u0027\u003e\u003d txq-\u003ecount\u0027.\n\nThis issue was reported by Claude Mythos.\n\nFixes: c2b636b3f788 (\"Bluetooth: btintel_pcie: Add support for PCIe transport\")\nSigned-off-by: Kiran K \u003ckiran.k@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "de8d29ede6f32e38c470ce53e1509e0a3d118546", "tree": "ec808ce8085ab98db7e73064df43b768f9994acc", "parents": [ "88a6bc5607e2608368a08d5117b2e155069a51fa" ], "author": { "name": "Kiran K", "email": "kiran.k@intel.com", "time": "Thu Sep 03 20:21:01 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Sep 03 15:32:51 2026 -0400" }, "message": "Bluetooth: btintel_pcie: validate packet_len before skb_put_data\n\nbtintel_pcie_submit_rx_work() reads packet_len from rfh_hdr without\nchecking if it exceeds the RX buffer size. An oversized packet_len\ncan lead to an out-of-bounds read in skb_put_data().\n\nValidate packet_len to ensure it is non-zero and does not exceed\nBTINTEL_PCIE_BUFFER_SIZE - sizeof(*rfh_hdr), logging an error when\ninvalid.\n\nThis issue was reported by Claude Mythos. It can be simulated either by\nusing customized firmware configured to return an invalid packet_len or\nby modifying rfh_hdr-\u003epacket_len in the driver before calling\nbtintel_pcie_submit_rx_work().\n\nFixes: c2b636b3f788 (\"Bluetooth: btintel_pcie: Add support for PCIe transport\")\nSigned-off-by: Kiran K \u003ckiran.k@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "88a6bc5607e2608368a08d5117b2e155069a51fa", "tree": "fb57b0dc11ee1213a570551017cf8ae8bd7e3627", "parents": [ "0aab041d532fc9bd0056f4e450c525ae8b49d1d8" ], "author": { "name": "Aritra Das", "email": "aritra.rohit2003@gmail.com", "time": "Thu Sep 03 10:03:22 2026 -0700" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Sep 03 15:32:48 2026 -0400" }, "message": "Bluetooth: btusb: Add USB ID 13d3:3556 for RTL8821CE\n\nThe onboard Realtek RTL8821CE combo card on the ASUS PRIME B550-PLUS\nAC-HES presents its Bluetooth function as USB ID 13d3:3556. This ID is\nmissing from quirks_table, so btusb matches the device only through the\ngeneric Bluetooth class entry in btusb_table and driver_info stays zero.\nBTUSB_REALTEK is therefore never set, btrtl never runs, and the\ncontroller keeps executing its on-chip ROM firmware instead of loading\nrtl_bt/rtl8821c_fw.bin and rtl_bt/rtl8821c_config.bin.\n\nIn that state BLE HID peripherals are unusable. A HHKB Hybrid keyboard\npairs and enumerates as a HID device, then the link drops within 10-30\nseconds, repeatedly. The same keyboard is stable on the same host under\nother operating systems.\n\nAdding the ID lets btusb run the Realtek setup path:\n\n Bluetooth: hci0: RTL: examining hci_ver\u003d08 hci_rev\u003d000c lmp_ver\u003d08 lmp_subver\u003d8821\n Bluetooth: hci0: RTL: rom_version status\u003d0 version\u003d1\n Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_fw.bin\n Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_config.bin\n Bluetooth: hci0: RTL: cfg_sz 10, total sz 34926\n Bluetooth: hci0: RTL: fw version 0x75b8f098\n\nWith the firmware loaded the same keyboard has stayed connected for over\n11 hours without a single drop.\n\nDevice descriptor:\n\nT: Bus\u003d01 Lev\u003d01 Prnt\u003d01 Port\u003d04 Cnt\u003d02 Dev#\u003d 2 Spd\u003d12 MxCh\u003d 0\nD: Ver\u003d 1.10 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 MxPS\u003d64 #Cfgs\u003d 1\nP: Vendor\u003d13d3 ProdID\u003d3556 Rev\u003d01.10\nS: Manufacturer\u003dRealtek\nS: Product\u003dBluetooth Radio\nS: SerialNumber\u003d00e04c000001\nC: #Ifs\u003d 2 Cfg#\u003d 1 Atr\u003de0 MxPwr\u003d500mA\nI: If#\u003d 0 Alt\u003d 0 #EPs\u003d 3 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 Driver\u003dbtusb\nE: Ad\u003d02(O) Atr\u003d02(Bulk) MxPS\u003d 64 Ivl\u003d0ms\nE: Ad\u003d81(I) Atr\u003d03(Int.) MxPS\u003d 16 Ivl\u003d1ms\nE: Ad\u003d82(I) Atr\u003d02(Bulk) MxPS\u003d 64 Ivl\u003d0ms\nI: If#\u003d 1 Alt\u003d 0 #EPs\u003d 2 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 Driver\u003dbtusb\nE: Ad\u003d03(O) Atr\u003d01(Isoc) MxPS\u003d 0 Ivl\u003d1ms\nE: Ad\u003d83(I) Atr\u003d01(Isoc) MxPS\u003d 0 Ivl\u003d1ms\n\nSigned-off-by: Aritra Das \u003caritra.rohit2003@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "0aab041d532fc9bd0056f4e450c525ae8b49d1d8", "tree": "764697a7b78be59ce1524376cab2839307463a26", "parents": [ "ee16dd607ff49420bdda513976cd7bd73d849ff7" ], "author": { "name": "Rong Zhang", "email": "i@rong.moe", "time": "Thu Sep 03 03:18:59 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Sep 03 15:32:44 2026 -0400" }, "message": "Bluetooth: btrtl: Don\u0027t leak return code when parsing firmware format v2\n\nWhen key_id from chip is zero, rtlbt_parse_firmware_v2() intentionally\nignores all security headers. However, the implementation simply breaks\nfrom a switch statement and leaks uninitialized return code `rc\u0027 (if the\nfirst section is a security one) or the previous section\u0027s `rc\u0027.\n\nFix it by really skipping a loop with `continue\u0027. For consistency and\nreadability, also do the same for the default case.\n\nFixes: 9a24ce5e29b1 (\"Bluetooth: btrtl: Firmware format v2 support\")\nCc: stable@vger.kernel.org\nSigned-off-by: Rong Zhang \u003ci@rong.moe\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "ee16dd607ff49420bdda513976cd7bd73d849ff7", "tree": "0d895e38bcd0eb9051fd302a557f27727019adbe", "parents": [ "37521ec2f55f3bb32f99ce2e19c73ecba89a8c9c" ], "author": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Fri Aug 28 16:10:25 2026 -0400" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 02 17:41:19 2026 -0400" }, "message": "Bluetooth: btusb: Add support for Bulk Serialization Mode\n\nThis adds support for Bulk Serialization Mode introduced in 6.2:\n\nhttps://www.bluetooth.com/bluetooth-core-6-2-feature-overview/#5-bluetooth-hci-usb-le-isochronous-support\nhttps://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/host-controller-interface/usb-transport-layer.html#UUID-c1a65395-29e9-87d3-2981-8bed625d0459\n\nIt works by detecting if alternate setting 1 is supported for the\ninterface and then switches to use it as it serializes all the frames\nin a single Bulk endpoint using H4 headers and it considerable more\nrobust then legacy one while allowing the transport of ISO packets:\n\n \u0027In addition to enabling Bluetooth® LE Audio, the new mode resolves a\n persistent race condition in the legacy USB transport layer. In Legacy\n Mode, different endpoint types are serviced in a specific order within\n a USB frame, which can result in out-of-order delivery of data and\n events. For example, a Host might receive a data packet before the\n event signaling its arrival. This behavior can disrupt critical\n processes such as connection setup, disconnection, and data encryption,\n adversely affecting the user experience.\u0027\n\nSigned-off-by: Johann Fischer \u003cjohann.fischer@nordicsemi.no\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "37521ec2f55f3bb32f99ce2e19c73ecba89a8c9c", "tree": "7aa8fc83b5c1baac915b820a73a0b6ab368dea6c", "parents": [ "83a1797b2020f460486a00a10ff4fce84bd77d3e" ], "author": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Fri Aug 28 16:04:30 2026 -0400" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 02 17:30:36 2026 -0400" }, "message": "Bluetooth: Move H:4 reassembly into the Bluetooth core\n\nh4_recv_buf() is currently implemented in hci_h4.c which is only built as\npart of the hci_uart module, and only when CONFIG_BT_HCIUART_H4 is\nenabled. That makes the H:4 reassembly logic unusable by drivers which do\nnot depend on hci_uart, e.g. btusb which needs it to implement Bulk\nSerialization Mode.\n\nMove the transport agnostic part into the Bluetooth core as\nh4_recv_skb(), which takes a struct hci_dev instead of a struct hci_uart,\nalong with struct h4_recv_pkt and the H4_RECV_* helpers, and keep\nh4_recv_buf() as a thin wrapper for the hci_uart protocols.\n\nSince every Bluetooth driver already depends on the bluetooth module this\nintroduces no new module dependency and no new Kconfig symbol.\n\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "83a1797b2020f460486a00a10ff4fce84bd77d3e", "tree": "d04f9e756239cdb7484483bec2ea0f302d24d268", "parents": [ "6696072ffe07205255cf83621a95a1aa2f9f6e62" ], "author": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 31 12:13:10 2026 -0400" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 02 17:30:17 2026 -0400" }, "message": "Bluetooth: btusb: Fix UAF of btusb_data by rx_work\n\nbtusb_close() and btusb_flush() cancel data-\u003erx_work with the\nasynchronous cancel_delayed_work(), so if btusb_rx_work() is already\nrunning on another CPU it keeps running after the cancel returns.\n\nbtusb_disconnect() calls hci_unregister_dev(), which invokes\nbtusb_close(), and then frees the btusb_data. A still running\nbtusb_rx_work() then dereferences the freed data:\n\n\twhile ((skb \u003d skb_dequeue(\u0026data-\u003eacl_q)))\n\t\tdata-\u003erecv_acl(data-\u003ehdev, skb);\n\nUse cancel_delayed_work_sync() instead. In btusb_close() the cancel also\nhas to happen after btusb_stop_traffic(), otherwise an URB completion\nracing with the cancel can requeue the work right after it has been\nwaited for.\n\nFixes: 800fe5ec302e (\"Bluetooth: btusb: Add support for queuing during polling interval\")\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "6696072ffe07205255cf83621a95a1aa2f9f6e62", "tree": "01476d5180640a02bf0c1f176ad35c72cd730090", "parents": [ "4149ba2a806c46853122d1a7063748429d8fc415" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Wed Sep 02 00:04:36 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 02 15:55:23 2026 -0400" }, "message": "Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn\n\nl2cap_chan may be linked to l2cap_conn at most once. This is assumed in\nseveral places, eg l2cap_chan_del cleanup.\n\nThere is a TOCTOU race where the invariant is violated:\n\n [Task 1] [Task 2]\n l2cap_chan_connect l2cap_sock_bind\n l2cap_chan_lock lock_sock\n l2cap_state_change if (sk-\u003esk_state !\u003d BT_OPEN)\n chan-\u003estate \u003d BT_CONNECT\n l2cap_sock_state_change_cb chan-\u003estate \u003d BT_BOUND\n sk-\u003esk_state \u003d BT_BOUND\n lock_sock \u003c------------------ release_sock\n sk-\u003esk_state \u003d BT_CONNECT\n\nl2cap_sock_connect() does not check sk-\u003esk_state, so since chan-\u003estate\nis now BT_BOUND, subsequent connect() ends up with second\n__l2cap_chan_add.\n\nExplicitly document and check the invariant in __l2cap_chan_add with\nWARN_ON_ONCE. The only callsite where it could be hit is\nl2cap_chan_connect, so add pre-check there to avoid relying on\nchan-\u003estate. chan-\u003estate read/write is not properly guarded currently so\nthere can be other TOCTOUC problems.\n\nAdd l2cap_lock_chan in l2cap_sock_bind() to guard chan-\u003estate write.\n\nFixes: b66774b48dd9 (\"Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref\")\nAssisted-by: deepseek-4-flash # finding the race condition\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "4149ba2a806c46853122d1a7063748429d8fc415", "tree": "875c349bd41c6f56e4a2be6725654948b6b40b03", "parents": [ "6873eb51dcdd9ae01f8c682e482c8915dbbb138f" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Wed Sep 02 00:04:35 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 02 15:55:02 2026 -0400" }, "message": "Bluetooth: L2CAP: annotate locking for l2cap_ops callbacks\n\nAnnotate current locking context for l2cap_ops callbacks.\n\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "6873eb51dcdd9ae01f8c682e482c8915dbbb138f", "tree": "0a23b363fd6e9a4dec0549bd7cc602400dbe3841", "parents": [ "c6d60c24cd7b3d74d1f7ad5db5651cb581801cc4" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Wed Sep 02 00:04:34 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 02 15:54:40 2026 -0400" }, "message": "Bluetooth: L2CAP: annotate locking for l2cap_chan_del()\n\nAdd context analysis annotations for chan-\u003elock and chan-\u003econn-\u003elock\ninvolving l2cap_chan_del() usage.\n\nAdd necessary annotations and related lockdep_assert_held to callers.\n\nMove struct l2cap_ops definition after struct l2cap_conn, so that the\ncallbacks can be annotated.\n\nIn l2cap_chan_close_unlocked() we consider chan-\u003econn-\u003elock as locked\neven if chan-\u003econn \u003d\u003d NULL, to avoid needing to define separate\n__l2cap_chan_close/del for this NULL case.\n\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "c6d60c24cd7b3d74d1f7ad5db5651cb581801cc4", "tree": "010952a620907cef83040d66cfc067b5c351c549", "parents": [ "512bf44847667f5b11276747d578990e3033e585" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Wed Sep 02 00:04:33 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Sep 02 15:51:19 2026 -0400" }, "message": "Bluetooth: L2CAP: take lock for l2cap_chan_del in l2cap_ecred_rsp_defer\n\nl2cap_ecred_rsp_defer() calls l2cap_chan_del without holding chan-\u003elock,\nwhich ends up calling ops-\u003eteardown() with wrong lock context.\n\nFix by taking chan-\u003elock in l2cap_ecred_rsp_defer(). AB-BA deadlocks\nbetween sibling l2cap_chan are avoided here via requiring l2cap_conn::lock\nto serialize all nested l2cap_chan locking on same nesting level.\n\nIn current code, there is no nested l2cap_chan locking on same nesting\nlevel, so we can add this new requirement.\n\nAlso return early from __l2cap_ecred_conn_rsp_defer() if chan did not\nhave FLAG_DEFER_SETUP, as then no RSP shall be sent for it, to make sure\nSMP channels are excluded.\n\nAlso hold chan reference over l2cap_chan_del(), in case chan_l reference\nwas the last.\n\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "512bf44847667f5b11276747d578990e3033e585", "tree": "b38091d30000e95f9f8ba3a56d8214086812bd71", "parents": [ "2c127ee79a0b260fa4a4042c36542e772f7c20f5" ], "author": { "name": "Rong Zhang", "email": "i@rong.moe", "time": "Wed Sep 02 02:19:18 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 15:54:17 2026 -0400" }, "message": "Bluetooth: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform\n\nIt is reported that a remote wakeup could cause MT7922/MT7925\u0027s btusb\ninterface completely unresponsive. Resetting the xHCI root hub doesn\u0027t\nhelp at all, and recovering from such a state needs a power cycle.\n\nAll reports seen to be relevant to Ryzen-based laptops. These NICs are\nusually used as OEM components thanks to some sort of reference designs.\nTheir popularity on other platforms is unclear. While there is still a\nchance that the quirk may exist on other platforms, be cautious and only\napply the quirk to direct children of Ryzen platforms\u0027s root hubs for\nthe time being. In most cases the root hub is on the SoC or PCH, which\nneeds the quirk. Unfortunately, this can\u0027t distinguish root hubs on PCIe\nadd-in cards. Such roughness should be acceptable, as PCIe USB\ncontroller add-in cards are less commonly used nowadays. On the other\nhand, applying the quirk doesn\u0027t hurt any functionalities either, as the\ndevice can still be used as a wakeup source if desired. Theoretically,\nwe could retrieve the root hub\u0027s PCI vendor ID with some hierarchy\nmagic, but that\u0027s too intrusive...\n\nMeanwhile, though device_set_wakeup_capable(false) is the correct fix\nfor other NICs with fake remote wakeup capabilities, doing so for\nMT7922/MT7925 effectively prevents it from being used as wakeup\nsources as per userspace requests. Hence, return -EBUSY on runtime\nsuspend to prevent the interface from being autosuspended while it\u0027s\nstill opened, which has the same effect as\ndevice_set_wakeup_capable(false), since disabling remote wakeup simply\ncauses the USB core to gate runtime autosuspend as well due to\nneeds_remote_wakeup \u003d\u003d 1. The interface can be safely autosuspended as\nlong as remote wakeup is disabled, i.e., after closing the HCI device.\n\nSpecifically, the interface may still take the advantage of remote\nwakeup in order to wake up the system from sleep if userspace has\nenabled it as a wakeup source.\n\nFixes: e31d761628ad (\"Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925\")\nTested-by: Rafael Passos \u003crafael@rcpassos.me\u003e\nSigned-off-by: Rong Zhang \u003ci@rong.moe\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "2c127ee79a0b260fa4a4042c36542e772f7c20f5", "tree": "80c5cd14eb44b7734683c422f110dda84b7fc76e", "parents": [ "761224d13f8a5d84a9c06b9948a37b1b1dbc7837" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 29 17:20:10 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 13:38:14 2026 -0400" }, "message": "Bluetooth: L2CAP: remove conditional locking from l2cap_connect()\n\nContext analysis does not understand conditional locking.\n\nRestructure l2cap_connect() by removing conditional locking at the cost\nof some code duplication, so that static analysis can see its content.\n\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "761224d13f8a5d84a9c06b9948a37b1b1dbc7837", "tree": "f63053f303befba8d6e911d879983f77d0e58a73", "parents": [ "26836086682ac9017a53b6bd3be1bb7e37dcec2c" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 29 17:20:09 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 13:38:11 2026 -0400" }, "message": "Bluetooth: L2CAP: make concurrent l2cap_set_timer() refcounting safe\n\nSince l2cap_set_timer() does not check return value of\nschedule_delayed_work(), two concurrent calls may result to l2cap_chan\nrefcount leak.\n\nChange the refcounting by using mod_delayed_work() and checking its\nreturn value.\n\nCode paths aside from l2cap_chan_busy() hold chan-\u003elock, so this has\nlittle correctness impact.\n\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "26836086682ac9017a53b6bd3be1bb7e37dcec2c", "tree": "6f8b002fda43717bc8624cbcd7b2117aa8d8e297", "parents": [ "886931f0c7e6fb6b3f596fe2397eb3a309da2755" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 29 17:20:06 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 13:37:58 2026 -0400" }, "message": "Bluetooth: L2CAP: hold chan in l2cap_ecred_conn_rsp()\n\nl2cap_chan_del() calls l2cap_chan_put() to drop the conn-\u003echan_l\nreference. If this was the last reference, UAF follows.\n\nl2cap_ecred_conn_rsp() iterates chan_l list and calls l2cap_chan_del()\non some members, without holding chan reference.\n\nFix by holding refcount while using chan after l2cap_chan_del().\n\nSince orig is looked up by dcid provided by remote, it\u0027s also possible\norig \u003d\u003d chan, so reference needs to be held also after orig use.\n\nFixes: 41c2713b204e (\"Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp\")\nAssisted-by: deepseek-v4-flash\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "886931f0c7e6fb6b3f596fe2397eb3a309da2755", "tree": "67dfa8b8a800ca762816e204842100499be597d5", "parents": [ "604e2f6d1e9588dc7b1d34409895fdb04b44b558" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 29 17:20:04 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 13:30:53 2026 -0400" }, "message": "Bluetooth: L2CAP: add annotations for l2cap_chan list locking\n\nAdd context analysis annotations for l2cap_conn::chan_l and chan_list\nlocking.\n\nAdd corresponding required annotations to accessors and callers.\n\nThis is not complete chan_l annotation, l2cap_chan::list and\nl2cap_chan_del() locking is currently not fully correct, and needs\nseparate fix + annotations.\n\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "604e2f6d1e9588dc7b1d34409895fdb04b44b558", "tree": "47cae1a351658253481f80ad130dcaa32866b587", "parents": [ "62df59925278d0c09424ffa3ef7044922e40ddcc" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 29 17:20:03 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 13:30:50 2026 -0400" }, "message": "Bluetooth: L2CAP: hold l2cap_conn::lock in l2cap_connect_cfm()\n\nl2cap_new_connection() -\u003e __l2cap_chan_add() modifies\nl2cap_conn::chan_l, which is guarded by l2cap_conn::lock. The lock is\nnot held in l2cap_connect_cfm().\n\nFix by holding conn-\u003elock in l2cap_connect_cfm() to make the locking\nsystematic.\n\nFixes: ab4eedb790ca (\"Bluetooth: L2CAP: Fix corrupted list in hci_chan_del\")\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "62df59925278d0c09424ffa3ef7044922e40ddcc", "tree": "a23493cabb798491cbc03a57deb9687df65128e6", "parents": [ "02122fd8002984b963c38a7c743934748d25214a" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 29 17:20:02 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 13:30:47 2026 -0400" }, "message": "Bluetooth: L2CAP: hold conn-\u003elock for __l2cap_ecred_conn_rsp_defer\n\n__l2cap_ecred_conn_rsp_defer() \u003e __l2cap_chan_list_id() accesses\nconn-\u003echan_l which is guarded by conn-\u003elock. The lock fails to be held\nwhen calling from l2cap_sock.c.\n\nFix by using l2cap_chan_conn_lock(), and taking the locks in required\norder l2cap_conn::lock \u003e l2cap_chan::lock \u003e sk. Leave fast path with\nsk-\u003esk_state precheck. Move the L2CAP defer handling to\nl2cap_sock_defer().\n\nThe code should also take l2cap_chan_lock() for sibling channels, but\nthat needs separate fix due to lock nesting.\n\nFixes: ab4eedb790ca (\"Bluetooth: L2CAP: Fix corrupted list in hci_chan_del\")\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "02122fd8002984b963c38a7c743934748d25214a", "tree": "9f7dcf9dfb421352de97f740bc40226775596b11", "parents": [ "c5123fddfef12f97a2a897fee339130944c95b38" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 29 17:20:01 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 13:30:43 2026 -0400" }, "message": "Bluetooth: 6lowpan: avoid concurrent peer_del() in bt_6lowpan_disconnect\n\nbt_6lowpan_disconnect() looks up and accesses peer-\u003echan, without\nholding locks guaranteeing peer_del() cannot free the peer concurrently.\n\nTake devices_lock to ensure peer can be dereferenced safely.\n\nFixes: 15f32cabf426 (\"Bluetooth: 6lowpan: add missing l2cap_chan_lock()\")\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "c5123fddfef12f97a2a897fee339130944c95b38", "tree": "3850aa8bbc6ddbb008699d623f1edb96022545a5", "parents": [ "4e64bd587b64561deb4ce014af521d8ba9db5898" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 29 17:20:00 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 13:30:40 2026 -0400" }, "message": "Bluetooth: L2CAP: remove unused l2cap_chan_close()\n\nl2cap_chan_close() is now unused, and l2cap_chan_close_unlocked() should\nbe used instead.\n\nRemove l2cap_chan_close().\n\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "4e64bd587b64561deb4ce014af521d8ba9db5898", "tree": "2f28d3be0e0d10f811d9d2e02a292fc07efeddbc", "parents": [ "86b3773598263417b00fd6563c01561a6cebaf64" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 29 17:19:59 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 13:30:37 2026 -0400" }, "message": "Bluetooth: 6lowpan: use l2cap_chan_close_unlocked()\n\n6lowpan.c is using l2cap_chan_close() without taking chan-\u003econn-\u003elock,\nso it may modify conn-\u003echan_l without holding the guarding lock.\n\nFix the locking by using the l2cap_chan_close_unlocked() helper that\nacquires the necessary locks.\n\nFixes: 15f32cabf426 (\"Bluetooth: 6lowpan: add missing l2cap_chan_lock()\")\nLink: https://syzkaller.appspot.com/bug?extid\u003d0e4ebcc970728e056324\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "86b3773598263417b00fd6563c01561a6cebaf64", "tree": "30113c579af70ac5a86e02b7cba53626bf8ef0ca", "parents": [ "368dc7fcaced7635f5c444240e24bd882963e8ad" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 29 17:19:58 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 13:30:34 2026 -0400" }, "message": "Bluetooth: L2CAP: fix race condition in l2cap_sock_shutdown()\n\nl2cap_sock_shutdown() has the race condition\n\n [Task 1] [Task 2]\n l2cap_sock_shutdown l2cap_sock_connect\n l2cap_chan_lock l2cap_chan_connect\n conn \u003d ... /* \u003d\u003d NULL*/\n l2cap_chan_unlock ------------\u003e l2cap_chan_lock\n if (conn) /* false */\n __l2cap_chan_add(conn, chan)\n l2cap_chan_lock \u003c-------------- l2cap_chan_unlock\n l2cap_chan_close /* chan-\u003econn-\u003elock not held! */\n\nconn-\u003elock protects conn-\u003echan_l and is not properly held here.\n\nUse the l2cap_chan_close_unlocked() helper that ensures conn-\u003elock is\nheld for l2cap_chan_close().\n\nFixes: ab4eedb790ca (\"Bluetooth: L2CAP: Fix corrupted list in hci_chan_del\")\nReported-by: Eulgyu Kim \u003ceulgyukim@snu.ac.kr\u003e\nReported-by: Jaeyoung Chung \u003cjjy600901@snu.ac.kr\u003e\nLink: https://lore.kernel.org/linux-bluetooth/20260824153908.2327306-1-jjy600901@snu.ac.kr/\nLink: https://syzkaller.appspot.com/bug?extid\u003d0e4ebcc970728e056324\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "368dc7fcaced7635f5c444240e24bd882963e8ad", "tree": "fd2b0387e09f6973ff2d7c1a2c99f9094a521b09", "parents": [ "ca52f4764c8754d006e53cd7be3f2cb1a2b98fa4" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 29 17:19:57 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 13:30:32 2026 -0400" }, "message": "Bluetooth: L2CAP: add l2cap_chan_close_unlocked() and locking helpers\n\nl2cap_chan_close() requires holding chan-\u003elock and chan-\u003econn-\u003elock if\nassociated chan-\u003econn exists, to guard eg. conn-\u003echan_l. Taking the\nlocks with right ordering requires handling a race condition.\n\nAdd helper function l2cap_chan_(un)lock_conn that do the locking right.\n\nAdd l2cap_chan_close_unlocked() that does not require locks to be held,\nas all callsites do this lock -\u003e close -\u003e unlock pattern.\n\nLink: https://syzkaller.appspot.com/bug?extid\u003d0e4ebcc970728e056324\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "ca52f4764c8754d006e53cd7be3f2cb1a2b98fa4", "tree": "2765fb8b366c2495b8a48821afd9a66cbbc750fe", "parents": [ "870187be2362118ce51f6d583881d381f2ffde81" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 29 17:19:56 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Sep 01 13:30:29 2026 -0400" }, "message": "Bluetooth: L2CAP: take chan-\u003elock for l2cap_chan_add/ready/del\n\nchan-\u003elock must be held for __l2cap_chan_add as eg. calls to\nl2cap_chan_close assume chan-\u003econn writes are guarded by it.\n\nIt must be held for l2cap_chan_del() due to\nl2cap_sock.c:l2cap_chan_conn, l2cap_monitor_timeout, etc.\n\nSimilarly it should be held for l2cap_ops::ready (assumed in 6lowpan.c).\nAlso teardown usually has chan-\u003elock held, it should always have it held\nto have the same locking context.\n\nThe lock is not correctly held by l2cap_core in several places.\n\nAdd the missing locks for l2cap_chan_del/add/ready(), except in\nl2cap_ecred_rsp_defer() which needs separate fix as it needs lock\nnesting.\n\nFixes: 6fef032af009 (\"Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()\")\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nReported-by: Eulgyu Kim \u003ceulgyukim@snu.ac.kr\u003e\nReported-by: Jaeyoung Chung \u003cjjy600901@snu.ac.kr\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "870187be2362118ce51f6d583881d381f2ffde81", "tree": "f06f300bc2cd5ab9a44c3b645a5f6e067f261a09", "parents": [ "af04b0e3176e55baaf2c080401486cfc7eb957af" ], "author": { "name": "Gongwei Li", "email": "ligongwei@kylinos.cn", "time": "Tue Aug 25 10:01:45 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 31 12:50:35 2026 -0400" }, "message": "Bluetooth: hci_mrvl: Fix wrong return value check of wait_on_bit_timeout()\n\nwait_on_bit_timeout() returns 0 if the bit was cleared, -EINTR if the\nprocess received a signal and the mode permitted wake up on that signal,\nor -EAGAIN if the timeout elapsed. It never returns 1.\n\nHence the check \"err \u003d\u003d 1\" in mrvl_load_firmware() is dead code: when\nthe waiting task is interrupted by a signal (-EINTR), the code falls\ninto the \"else if (err)\" branch and misreports it as \"Firmware request\ntimeout\" with -ETIMEDOUT instead of propagating -EINTR.\n\nFix this by testing for -EINTR so that an interrupted firmware load is\nproperly detected and reported.\n\nFixes: 162f812f23ba (\"Bluetooth: hci_uart: Add Marvell support\")\nSigned-off-by: Gongwei Li \u003cligongwei@kylinos.cn\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "af04b0e3176e55baaf2c080401486cfc7eb957af", "tree": "5005b785ec5ff7b4af746cca86b80b62efbfcef7", "parents": [ "ddaccd985bb01da7384af3f0524c29fa551c10e2" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sun Aug 30 15:04:02 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 31 12:50:11 2026 -0400" }, "message": "Bluetooth: L2CAP: clear FLAG_DEFER_SETUP only for same PID/PSM\n\nl2cap_ecred_defer_connect() clears FLAG_DEFER_SETUP also for channels\nwith different PID/PSM, which will not be added to the same\nECRED_CONN_REQ in any case. Consequently, only one ECRED connection\ngroup can work at a time although it appears intended they would be\nseparate for each PID/PSM combination.\n\nFix by clearing FLAG_DEFER_SETUP only for the connections that could be\nadded in the request. Retain test_bit(FLAG_DEFER_SETUP) before calling\nget_peer_pid as it may be NULL otherwise.\n\nFixes: da49b602f7f7 (\"Bluetooth: L2CAP: Use DEFER_SETUP to group ECRED connections\")\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "ddaccd985bb01da7384af3f0524c29fa551c10e2", "tree": "5e7ad2fab7b79616570c27f1ff26ce20f3f4b625", "parents": [ "b1f1766ef7691f6ae7478b9613e978adaaf693ae" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sun Aug 30 15:04:01 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 31 12:49:49 2026 -0400" }, "message": "Bluetooth: L2CAP: fix out-of-bounds write in l2cap_ecred_connect\n\nl2cap_chan_connect() tries to ensure there are no more than\nL2CAP_ECRED_CONN_SCID_MAX pending ECRED channels, so they fit in the\nsame L2CAP_ECRED_CONN_REQ that l2cap_ecred_connect() constructs.\n\nHowever, the check only counts deferred channels. If 6 L2CAP sockets\nare connected at the same time in order DDDDND (D\u003ddeferred,\nN\u003dnon-deferred), the last can bump the total to max+1. It results to\none __le16 written out of bounds of the scid array, and an invalid\nECRED_CONN_REQ being sent.\n\nFix by leaving room for the non-deferred pending ECRED channels in the\ncounting in l2cap_chan_connect(), so the limit can\u0027t be exceeded.\n\nMove counting under same critical section where the channel is added.\nAlthough race conditions involving this appear unreachable, it\u0027s easier\nto see.\n\nAlso add WARN_ON_ONCE check in l2cap_ecred_defer_connect() to make this\nless brittle.\n\nFixes: da49b602f7f7 (\"Bluetooth: L2CAP: Use DEFER_SETUP to group ECRED connections\")\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "b1f1766ef7691f6ae7478b9613e978adaaf693ae", "tree": "72d6c260d5da6cbd11608d44fdafb013d11776b7", "parents": [ "78f08df9649c18804ea935b9226395c97aac4a99" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sun Aug 30 20:11:36 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 31 12:49:27 2026 -0400" }, "message": "Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan\n\nl2cap_new_connection() sets default value of channel mode to match the\nparent channel. l2cap_le_connect_req() left this at the default, and\ncreated L2CAP_MODE_EXT_FLOWCTL channels if listening pchan has that\nmode. This causes FLAG_DEFER_SETUP channels to reply to\nL2CAP_LE_CONN_REQ with L2CAP_ECRED_CONN_RSP, which is incorrect.\n\nIt can also result to stack OOB write (of l2cap_alloc_cid determined\nvalues) in l2cap_ecred_rsp_defer(), as l2cap_le_connect_req() does not\nlimit maximum number of deferred channels or check for duplicate ident.\n\nFix by setting chan-\u003emode correctly in l2cap_le_connect_req().\n\nAlso check channel mode in l2cap_ecred_rsp_defer(), and do WARN_ON_ONCE\ninstead of OOB write to make it less brittle.\n\nFixes: 15f02b910562 (\"Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode\")\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "78f08df9649c18804ea935b9226395c97aac4a99", "tree": "2342dafa58048a036e73e6b3d85f0863cd2aec6a", "parents": [ "afe439f355464725801cde732446e0007f63d303" ], "author": { "name": "Aleksandr Nogikh", "email": "nogikh@google.com", "time": "Fri Aug 28 08:55:09 2026 +0000" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 31 12:49:06 2026 -0400" }, "message": "Bluetooth: hci_core: Fix race condition during device registration\n\nIn hci_register_dev(), the power_on work item is queued to\nhdev-\u003ereq_workqueue before initializing hdev-\u003eadv_monitors_idr and\nregistering the MSFT extension via msft_register(). For devices marked with\nquirks such as HCI_QUIRK_RAW_DEVICE, the HCI_UNCONFIGURED flag is set on\nthe device. When the power_on work item runs concurrently on another CPU,\nhci_power_on() detects that the device is unconfigured and immediately\ninvokes hci_dev_do_close(), which calls msft_do_close().\n\nConcurrently, msft_register() allocates the msft structure and exposes it\nto hdev-\u003emsft_data prior to calling mutex_init(\u0026msft-\u003efilter_lock). If\nmsft_do_close() executes while hdev-\u003emsft_data is already assigned but the\nmutex has not yet been initialized, mutex_lock(\u0026msft-\u003efilter_lock) operates\non an uninitialized mutex, triggering a DEBUG_LOCKS warning:\n\nDEBUG_LOCKS_WARN_ON(lock-\u003emagic !\u003d lock)\nWARNING: kernel/locking/mutex.c:625 at __mutex_lock_common\nkernel/locking/mutex.c:625 [inline]\nWARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550\nkernel/locking/mutex.c:821\n...\nCall Trace:\n \u003cTASK\u003e\n msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693\n hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522\n hci_dev_do_close net/bluetooth/hci_core.c:499 [inline]\n hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937\n process_one_work kernel/workqueue.c:3322 [inline]\n process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405\n worker_thread+0x92d/0xe10 kernel/workqueue.c:3486\n kthread+0x388/0x470 kernel/kthread.c:436\n ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \u003c/TASK\u003e\n\nFix this by moving the queue_work() call in hci_register_dev() to after\nidr_init(\u0026hdev-\u003eadv_monitors_idr) and msft_register(hdev) so that device\nstructures and extensions are fully initialized before asynchronous tasks\ncan access them. Additionally, assign hdev-\u003emsft_data in msft_register()\nonly after mutex_init(\u0026msft-\u003efilter_lock) has completed.\n\nFixes: 9e14606d8f38 (\"Bluetooth: msft: Extended monitor tracking by address filter\")\nAssisted-by: Gemini:gemini-3.7-flash Gemini:gemini-3.1-pro-preview syzbot\nReported-by: syzbot+14ce1b05b7d5a989abbe@syzkaller.appspotmail.com\nCloses: https://syzkaller.appspot.com/bug?extid\u003d14ce1b05b7d5a989abbe\nLink: https://syzkaller.appspot.com/ai_job?id\u003d2bc9e8aa-ca6d-43e2-be2c-fd5d9f649d7e\nSigned-off-by: Aleksandr Nogikh \u003cnogikh@google.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "afe439f355464725801cde732446e0007f63d303", "tree": "6429114b6c0f9b05734081ed42fac6f5d538d6e2", "parents": [ "4988456a75ea31a367a73b6e519158a0440036f5" ], "author": { "name": "Chris Lu", "email": "chris.lu@mediatek.com", "time": "Tue Aug 25 11:36:34 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 31 12:48:48 2026 -0400" }, "message": "Bluetooth: btmtksdio: Pass the hardware device id to mt79xx_setup()\n\nmt79xx_setup() passes a hardcoded 0 to btmtk_setup_firmware_79xx(),\ndiscarding the device id that btmtksdio_setup() has just read from register\n0x70010200. That argument only gates the section filtering for MT6639,\nwhich has no SDIO interface, so this is a no-op on supported hardware and\ncarries no Fixes: tag.\n\nPass the value that has already been read, matching the USB path. Declare\ndev_id as u32 while at it, since that is what btmtksdio_mtk_reg_read()\nwrites through the pointer.\n\nSigned-off-by: Chris Lu \u003cchris.lu@mediatek.com\u003e\nAssisted-by: Claude:claude-opus-5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "4988456a75ea31a367a73b6e519158a0440036f5", "tree": "fb9dc38aa581ef3156a8578f45f328ea52eb3f18", "parents": [ "f8c8fa407aa0f99f4b486aee9d1f5bec284f52c8" ], "author": { "name": "Chris Lu", "email": "chris.lu@mediatek.com", "time": "Tue Aug 25 11:36:33 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 31 12:48:30 2026 -0400" }, "message": "Bluetooth: btmtksdio: Remove redundant firmware filename override\n\nbtmtksdio_setup() derives the firmware filename with\nbtmtk_fw_get_filename() and then overwrites it with an snprintf() that\nopen-codes that helper\u0027s fallback format. Commit 7f935b21bee4 (\"Bluetooth:\nbtmtk: apply the common btmtk_fw_get_filename\") added the helper call\nwithout removing the snprintf() it was meant to replace.\n\nNone of the device ids the helper special-cases can appear here: 0x6639,\n0x7925 and the flavored 0x7961 belong to parts with no SDIO interface, and\nbtmtksdio_setup() passes a flavor of 0 accordingly. The helper always falls\nthrough to the snprintf()\u0027s own format, so both produce the same string and\nremoving it is a no-op.\n\nRemove it anyway, since it silently defeats the helper for any device id\nthe helper special-cases.\n\nSigned-off-by: Chris Lu \u003cchris.lu@mediatek.com\u003e\nAssisted-by: Claude:claude-opus-5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "f8c8fa407aa0f99f4b486aee9d1f5bec284f52c8", "tree": "f63f4eabaa7b596b8571bf6465c041ae64897b9d", "parents": [ "58c6f5ec1d22b52a0b667838c38a53842ffae0e5" ], "author": { "name": "Laxman Acharya Padhya", "email": "acharyalaxman8848@gmail.com", "time": "Mon Aug 31 15:44:23 2026 +0545" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 31 12:48:12 2026 -0400" }, "message": "Bluetooth: btintel: propagate version TLV parsing errors\n\nbtintel_read_version_tlv() ignores the parser return value, so setup\ncontinues with partially initialized version data after a malformed TLV\ncauses parsing to stop.\n\nReturn the parser error to the caller so an invalid response fails setup\ninstead of being treated as successful. Keep this behavioral change\nseparate from the bounds checks so it can be reverted independently if\nan existing controller sends malformed data.\n\nSigned-off-by: Laxman Acharya Padhya \u003cacharyalaxman8848@gmail.com\u003e\nReviewed-by: Ali Ahmet Memis \u003cali@iusegentoo.com\u003e\nTested-by: Kiran K \u003ckiran.k@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "58c6f5ec1d22b52a0b667838c38a53842ffae0e5", "tree": "ca554c1c528028d3fb5ecf879f1cfb769817417a", "parents": [ "eb656c5bb75434f89e87ea5c0321a0ec6eb7c67c" ], "author": { "name": "Laxman Acharya Padhya", "email": "acharyalaxman8848@gmail.com", "time": "Mon Aug 31 15:44:22 2026 +0545" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 31 12:47:52 2026 -0400" }, "message": "Bluetooth: btintel: bound firmware ID by TLV length\n\nThe firmware ID is treated as a NUL-terminated string even though the\nTLV length is its only boundary. If the value does not contain a NUL\nterminator, snprintf() can read beyond the received response.\n\nLimit the conversion to the advertised TLV value length.\n\nFixes: 164c62f958f8 (\"Bluetooth: btintel: Add firmware ID to firmware name\")\nReviewed-by: Ali Ahmet Memis \u003cali@iusegentoo.com\u003e\nSigned-off-by: Laxman Acharya Padhya \u003cacharyalaxman8848@gmail.com\u003e\nTested-by: Kiran K \u003ckiran.k@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "eb656c5bb75434f89e87ea5c0321a0ec6eb7c67c", "tree": "e66584235964e0ccaa904c33ea756107de4fa37f", "parents": [ "bcb621272aa04a116a74ab5fcc9324231ffa3acb" ], "author": { "name": "Laxman Acharya Padhya", "email": "acharyalaxman8848@gmail.com", "time": "Mon Aug 31 15:44:21 2026 +0545" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 31 12:44:12 2026 -0400" }, "message": "Bluetooth: btintel: validate version TLV value lengths\n\nbtintel_parse_version_tlv() verifies that a complete TLV is present in\nthe response, but it does not ensure that the value is long enough for\nthe specific TLV type. A short value can therefore cause an\nout-of-bounds read through get_unaligned_le16(), get_unaligned_le32(),\nor memcpy().\n\nReject values shorter than the minimum required by each known TLV type.\nAlso reject responses that do not contain the Command Complete Status\nfield.\n\nFixes: 57375beef71a (\"Bluetooth: btintel: Add infrastructure to read controller information\")\nReviewed-by: Ali Ahmet Memis \u003cali@iusegentoo.com\u003e\nSigned-off-by: Laxman Acharya Padhya \u003cacharyalaxman8848@gmail.com\u003e\nTested-by: Kiran K \u003ckiran.k@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "bcb621272aa04a116a74ab5fcc9324231ffa3acb", "tree": "0e1f915ca8fce3427e9b57e73ab50f3553474e92", "parents": [ "fe3897b4ab57b7c934532d86df79c129d6ac17a9" ], "author": { "name": "Kiran K", "email": "kiran.k@intel.com", "time": "Tue Aug 25 22:53:00 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Thu Aug 27 12:21:58 2026 -0400" }, "message": "Bluetooth: btintel_pcie: Clear automask on spurious interrupts\n\nOn spurious interrupt where the TX and RX causes are not set, driver was\nnot clearing the auto mask which can block all the interrupts. Driver\nneeds to clear the automask even if no causes are set.\n\nFixes: c2b636b3f788 (\"Bluetooth: btintel_pcie: Add support for PCIe transport\")\nSigned-off-by: Kiran K \u003ckiran.k@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "fe3897b4ab57b7c934532d86df79c129d6ac17a9", "tree": "e66b1cf4476cef34c6da3ddad301da8d6307996c", "parents": [ "aadb3cd4bbb4744ecb274c232d33947f77e45815" ], "author": { "name": "Chengfeng Ye", "email": "nicoyip.dev@gmail.com", "time": "Sat Aug 22 23:06:19 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 24 11:33:01 2026 -0400" }, "message": "Bluetooth: RFCOMM: serialize session teardown\n\nrfcomm_kill_listener() walks session_list and deletes every session\nwithout holding rfcomm_mutex, unlike the normal session processing and\nconnect error paths.\n\nUnder normal operation, an open RFCOMM socket pins rfcomm.ko, so\nrfcomm_kill_listener() does not run concurrently with rfcomm_dlc_open().\nHowever, forced module unload via delete_module(O_TRUNC) can stop\nkrfcommd while a failed connect is still unwinding.\n\n connect task forced unload / krfcommd\n ------------ ------------------------\n rfcomm_lock()\n rfcomm_session_add()\n delete_module(\"rfcomm\", O_TRUNC)\n rfcomm_kill_listener()\n fetch session from session_list\n kernel_connect() fails\n rfcomm_session_del()\n remove and free session\n rfcomm_session_del(session)\n\nThe final call then reads the freed session and may corrupt the list.\n\nKASAN reported with mdelay() to enlarge critical window:\n\n BUG: KASAN: slab-use-after-free in rfcomm_run+0x3802/0x3f00 [rfcomm]\n Read of size 8 at addr ffff888111058d40 by task krfcommd/79\n Tainted: [R]\u003dFORCED_RMMOD\n Allocated by task 86:\n rfcomm_session_add+0xa1/0x300 [rfcomm]\n rfcomm_dlc_open+0x8b2/0xf30 [rfcomm]\n rfcomm_sock_connect+0x34c/0x530 [rfcomm]\n Freed by task 86:\n kfree+0x121/0x3c0\n rfcomm_dlc_open+0xab7/0xf30 [rfcomm]\n rfcomm_sock_connect+0x34c/0x530 [rfcomm]\n\nHold rfcomm_mutex across the teardown traversal so every reachable\nsession_list walk uses the same serialization.\n\nReviewed-by: Ali Ahmet Memis \u003cali@iusegentoo.com\u003e\nTested-by: Ali Ahmet Memis \u003cali@iusegentoo.com\u003e\nReviewed-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Chengfeng Ye \u003cnicoyip.dev@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "aadb3cd4bbb4744ecb274c232d33947f77e45815", "tree": "cdc15829e6f5c1b2cc568c352a18dad265596543", "parents": [ "a6491451f8b8481d8ae0d4057fc046eaf7cb5ff1" ], "author": { "name": "Radek Podgorny", "email": "radek@podgorny.cz", "time": "Mon Aug 24 13:00:20 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 24 11:32:57 2026 -0400" }, "message": "Bluetooth: do not leak an hci_conn when a second LE connect is rejected\n\ncreate_le_conn_complete() decides whether the failed connection is\nstill pending by comparing it against hci_lookup_le_connect(), which\nreturns the first LE connection in BT_CONNECT. That is the same\nconnection only while at most one is pending.\n\nTwo can be pending. Connections created on the passive scan path sit\nin BT_CONNECT with HCI_CONN_SCANNING set and are invisible to\nhci_lookup_le_connect() until hci_le_create_conn_sync() clears the\nflag when their command is issued, so the -EBUSY guard in\nhci_connect_le() does not prevent a second connection from being\nqueued while the first is still on the scan path. Whenever two\nconnections are in BT_CONNECT at once, the lookup may return one\nconnection while create_le_conn_complete() is reporting the failure\nof the other; the early exit then drops the error and hci_conn_failed()\nnever runs on the connection that failed.\n\nThe controller also rejects a second HCI_OP_LE_CREATE_CONN issued\nwhile another connection creation is still outstanding, per Core Spec\nVol 4, Part E. The spec calls for Command Disallowed there; the\nbcm43438 observed here answers with an LMP/LL error code instead,\nwhich bt_to_errno() maps to the -EPROTO (-71) in the log below.\n\nThe leaked connection stays in BT_CONNECT forever, and because\nhci_connect_le() refuses to dial while hci_lookup_le_connect() finds\nanything, every subsequent attempt to reach any peer fails with\n-EBUSY and no command reaches the controller at all.\n\nSeen on a bcm43438 with two BLE peers polled on the same interval\n(state 5 is BT_CONNECT; both handles are UNSET ones, allocated from\nthe ida above HCI_CONN_HANDLE_MAX):\n\n Bluetooth: hci1: Opcode 0x2013 failed: -71\n\n # hcitool con\n \u003c LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL\n \u003c LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL\n\nA btmon capture across the next ten minutes of connect attempts\ncontains no HCI_OP_LE_CREATE_CONN at all; outgoing LE connections\ndo not recover until the adapter is reset. With this change the same\nscenario fails the rejected connection cleanly and further connects\nto both peers go through.\n\nAsk about the connection itself instead of about the device.\n\nFixes: c9f73a2178c1 (\"Bluetooth: hci_conn: Fix hci_connect_le_sync\")\nSigned-off-by: Radek Podgorny \u003cradek@podgorny.cz\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "a6491451f8b8481d8ae0d4057fc046eaf7cb5ff1", "tree": "6d59433ffb96f8204b94ced2348eecdc6ba5d563", "parents": [ "40c621391de9371bea89b2fe5c7a90129f5922cb" ], "author": { "name": "George Maraveyas", "email": "george.0xfff@gmail.com", "time": "Sat Aug 22 01:37:33 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 24 11:32:53 2026 -0400" }, "message": "Bluetooth: mt7925: trigger reset on WMT timeout\n\nThe MT7925 Bluetooth USB function can enumerate successfully after a warm\nreboot while the WMT function-control command remains unresponsive.\n\nWhen that command times out, btmtk_usb_setup() currently returns\n-ETIMEDOUT without entering the existing MediaTek reset path. The existing\nUSB reset and recovery machinery is therefore never reached.\n\nFor MT7925, call btmtk_reset_sync() when the WMT function-control command\ntimes out. This enters the existing reset path in btusb_mtk_reset(), which\nperforms the MediaTek subsystem reset and queues a USB device reset.\n\nRuntime tracing on the affected hardware showed the resulting path through\nusb_queue_reset_device(), usb_reset_device() and\nusb_reset_and_verify_device(). When reset and verification could not\nrestore the device, the USB core escalated to a logical disconnect and\nre-enumeration.\n\nRecovery succeeded in three controlled Windows-to-Linux tests. Runtime\ntracing showed the existing USB reset path escalating to logical disconnect\nand re-enumeration. In two of those tests, tracing continued through the\nsubsequent enumeration failures and directly captured\nusb_acpi_port_prr_reset(), after which the MT7925 re-enumerated and\nBluetooth recovered.\n\nThese tests were performed on top of Chia-Lin Kao\u0027s ACPI _PRR hub patch,\nwhich remains a prerequisite for this patch.\n\nA fourth Windows-to-Linux test was then performed with the diagnostic btusb\nblacklist removed and btusb binding normally during boot. The WMT timeout\nreproduced and Bluetooth recovered automatically without manual\nintervention.\n\nSigned-off-by: George Maraveyas \u003cgeorge.0xfff@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "40c621391de9371bea89b2fe5c7a90129f5922cb", "tree": "94b66ffd6b2b7d041156fa8b57b4b37612b487c0", "parents": [ "0c9d2588a514f8719ee84640a8ec65bdfcb75384" ], "author": { "name": "Chengfeng Ye", "email": "nicoyip.dev@gmail.com", "time": "Sun Aug 23 00:43:41 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 24 11:32:49 2026 -0400" }, "message": "Bluetooth: RFCOMM: serialize security confirmation handling\n\nrfcomm_security_cfm() looks up a session on session_list and then walks\nits DLC list without holding rfcomm_mutex. Since RFCOMM session teardown\nuses rfcomm_mutex, krfcommd can close and free the same session and DLCs\nconcurrently:\n\n hci_rx_work krfcommd\n ----------- ---------\n rfcomm_session_get()\n rfcomm_lock()\n rfcomm_session_close()\n rfcomm_dlc_unlink()\n rfcomm_session_del()\n kfree(s)\n rfcomm_unlock()\n walk s-\u003edlcs\n\nThe callback can then read a freed session list head and touch freed DLCs\nwhile updating their flags or timers.\n\nSerialize the session lookup and DLC traversal in rfcomm_security_cfm()\nwith rfcomm_mutex. This matches the existing RFCOMM session lifetime\nrules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink()\nfrom tearing the objects down while the callback is using them.\n\nKASAN reported:\n\n BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440\n Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89\n Workqueue: hci0 hci_rx_work\n Call Trace:\n rfcomm_security_cfm+0x41c/0x440\n hci_encrypt_cfm+0x139/0x590\n hci_encrypt_change_evt+0x37b/0xc40\n hci_event_packet+0x71b/0xb20\n hci_rx_work+0x293/0x730\n Allocated by task 69:\n rfcomm_session_add+0x9e/0x2f0\n rfcomm_run+0x44b/0x41e0\n Freed by task 69:\n kfree+0x131/0x3c0\n rfcomm_session_del+0x188/0x220\n rfcomm_run+0x1985/0x41e0\n\nFixes: 08c30aca9e698faddebd34f81e1196295f9dc063 (\"Bluetooth: Remove RFCOMM session refcnt\")\nCc: stable@vger.kernel.org\nSigned-off-by: Chengfeng Ye \u003cnicoyip.dev@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "0c9d2588a514f8719ee84640a8ec65bdfcb75384", "tree": "3bd0ddabc7c15bf1be0da299b80f41e7b3f99466", "parents": [ "b8d936018ce2b029cd307056078a7802e9420b93" ], "author": { "name": "Junjie Cao", "email": "junjie.cao@intel.com", "time": "Mon Aug 24 13:32:27 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 24 11:32:46 2026 -0400" }, "message": "Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN quirk to 0bda:a728\n\nCommit 5ead2063611a (\"Bluetooth: btrtl: fix RTL8761B/BU broken LE\nextended scan\") set HCI_QUIRK_BROKEN_EXT_SCAN for every CHIP_ID_8761B\ndevice to cure repeated 0x2042 failures on an 0bda:a728 dongle. The\nbrokenness is per-dongle, not per-chip: on a TP-Link UB500 (2357:0604,\nRTL8761BU, fw 0xdfc6d922) extended scan works, and the legacy scan\npath the quirk forces is what is broken -- LE Set Scan Enable (0x200c)\ntimes out with -110 about 30 s after firmware load, btusb resets the\ndevice, and the adapter re-enumerates in an endless loop (382 firmware\nreloads in one boot). 7.1.8, which predates the stable backport, runs\nclean on this unit; 7.1.9 loops.\n\nMove the quirk from btrtl\u0027s chip-wide switch to a btusb device-table\nflag on the USB id the original fix was verified against. Other 8761B\ndongles return to their earlier long-standing behaviour.\n\nLink: https://bugzilla.redhat.com/show_bug.cgi?id\u003d2521504\nFixes: 5ead2063611a (\"Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan\")\nCc: stable@vger.kernel.org\nSigned-off-by: Junjie Cao \u003cjunjie.cao@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "b8d936018ce2b029cd307056078a7802e9420b93", "tree": "f8081f28a548eb4d9579f7d259e7c0c76052bc5e", "parents": [ "1c08039e3887fafc17dad527333938a379d38f34" ], "author": { "name": "Gongwei Li", "email": "ligongwei@kylinos.cn", "time": "Fri Aug 21 10:45:55 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Fri Aug 21 15:47:19 2026 -0400" }, "message": "Bluetooth: hci_uart: Fix false success return in hci_uart_setup()\n\nWhen reading the local version information for vendor detection\nfails, the error is only printed and 0 is returned, which masks the\nsetup failure from the HCI core.\n\nReturn PTR_ERR(skb) instead.\n\nFixes: fb2ce8d11f039 (\"Bluetooth: hci_uart: Add support for vendor detection flag\")\nFixes: 82f5169bf3d3b (\"Bluetooth: hci_uart: add serdev driver support library\")\nCc: stable@vger.kernel.org\nSigned-off-by: Gongwei Li \u003cligongwei@kylinos.cn\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "1c08039e3887fafc17dad527333938a379d38f34", "tree": "95667aaf6c7342aaa1ef61a40ea28cda4fdba3b3", "parents": [ "486f8908aa587ab2a213bbef39311743e4f8f57a" ], "author": { "name": "Hyunwoo Kim", "email": "imv4bel@gmail.com", "time": "Fri Mar 20 00:14:58 2026 +0900" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Fri Aug 21 15:43:27 2026 -0400" }, "message": "Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loop\n\nrfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter\nNegotiation) frame without checking for zero. When the remote peer\nsends an MTU of zero, d-\u003emtu is set to 0. This causes the sendmsg\npath to enter an infinite loop when fragmenting data, as each fragment\nhas size \u003d\u003d min_t(size_t, len, 0) \u003d\u003d 0, so the remaining length never\ndecreases. The infinite allocation of zero-length skbs exhausts all\nsystem memory.\n\nFix by clamping d-\u003emtu to RFCOMM_DEFAULT_MTU when the negotiated\nvalue is zero, consistent with the initial value assigned in\nrfcomm_dlc_alloc().\n\nFixes: 1da177e4c3f4 (\"Linux-2.6.12-rc2\")\nSigned-off-by: Hyunwoo Kim \u003cimv4bel@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "486f8908aa587ab2a213bbef39311743e4f8f57a", "tree": "9f2480db6e0b0bbde4630eb439099d446173ff87", "parents": [ "52eff0428bf2729c65572b3c990611dc7b7b1f4e" ], "author": { "name": "Hang Nan", "email": "2122295973@qq.com", "time": "Wed Aug 19 08:57:58 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Aug 19 12:44:02 2026 -0400" }, "message": "Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_ready\n\niso_conn_ready() looks up the BIS listener socket with iso_get_sock(),\nwhich takes a reference, and then, without re-checking its state,\ncreates a child socket from it:\n\n parent \u003d iso_get_sock(hdev, ...);\n if (!parent)\n return;\n\n lock_sock(parent);\n sk \u003d iso_sock_alloc(sock_net(parent), NULL, BTPROTO_ISO, ...);\n ...\n iso_chan_add(conn, sk, parent);\n ...\n release_sock(parent);\n sock_put(parent);\n\nIf the listener socket is closed concurrently, between iso_get_sock()\nand lock_sock(), the reference taken by iso_get_sock() may be the last\none: the close path drops the link-list reference, and once\niso_conn_ready() drops its own reference at the end of the function the\nsocket is freed. The child socket, however, is already linked to the\nfreed parent, and a later disconnect of the child runs iso_chan_del()\n-\u003e bt_accept_unlink(), which dereferences the dangling parent pointer\ninto the freed accept queue (a use-after-free). The same dangling\npointer is also dereferenced through parent-\u003e***() in\niso_chan_del().\n\nFix it the same way the connected (non-BIS) path was fixed in commit\n0d255e63fcf3 (\"Bluetooth: ISO: hold sk properly in iso_conn_ready\"):\nafter taking the socket lock, re-check that the parent is still a\nlistening, alive socket, and bail out otherwise.\n\nFixes: ccf74f2390d60 (\"Bluetooth: Add BTPROTO_ISO socket type\")\nCc: stable@vger.kernel.org\nSigned-off-by: Hang Nan \u003c2122295973@qq.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "52eff0428bf2729c65572b3c990611dc7b7b1f4e", "tree": "22e1690f401f004b725b1eda088be15fc3ca30c7", "parents": [ "185b9b3869fa9eaae23a95e682ddecdaeb5a2988" ], "author": { "name": "Catherine L", "email": "catherine.l@intel.com", "time": "Wed Aug 19 20:02:19 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Aug 19 12:43:59 2026 -0400" }, "message": "Bluetooth: btintel_pcie: Route debug traces to WiFi DBGC by default\n\nSet dbg_output_mode to 0x06 (BTINTEL_PCIE_WIFI_DBGC) by default so\nfirmware debug traces are forwarded to the WiFi DBGC. In this mode:\n\n - Host DBGC fragment/data buffers are NOT allocated.\n - Context info publishes dbgc_addr/size as 0.\n\nAdd a small helper btintel_pcie_dbg_to_wifi() driven by a cached\ndbg_path_cache field in struct btintel_pcie_data, initialized to\nBTINTEL_PCIE_WIFI_DBGC in probe.\n\nSigned-off-by: Kiran K \u003ckiran.k@intel.com\u003e\nSigned-off-by: Catherine L \u003ccatherine.l@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "185b9b3869fa9eaae23a95e682ddecdaeb5a2988", "tree": "d62fcd7cde047104fcac8453837468fc6319dc15", "parents": [ "6f5f8dcf62444590a66c463a487892aa9cf0d971" ], "author": { "name": "Kiran K", "email": "kiran.k@intel.com", "time": "Wed Aug 19 20:02:18 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Aug 19 12:43:55 2026 -0400" }, "message": "Bluetooth: btintel_pcie: sync mbox tlv parsing with GP0 alive interrupt\n\nPerforming a target access to read the mbox TLV table while the driver\nis concurrently posting RX buffers to the firmware causes the hardware\nto return 0 for the target address, resulting in an invalid/empty TLV\nparse.\n\nAdd a synchronization handshake between the mbox TLV read operation\nperformed by the mbox worker and the GP0 (alive) MSI-X interrupt (which\nsignals completion of RX buffer posting). The worker now waits for the\nalive interrupt before initiating the target access, ensuring the\nhardware returns valid data.\n\nAssisted-by: Gemini:gemini-3.1-pro-preview\nSigned-off-by: Kiran K \u003ckiran.k@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "6f5f8dcf62444590a66c463a487892aa9cf0d971", "tree": "9d4f797b3b586e7b799f4efbea9eb25fa303483e", "parents": [ "be766d775060e0049e7ee798b968d3bd649eb553" ], "author": { "name": "Chandrashekar Devegowda", "email": "chandrashekar.devegowda@intel.com", "time": "Wed Aug 19 20:02:17 2026 +0530" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Aug 19 12:43:52 2026 -0400" }, "message": "Bluetooth: btintel_pcie: parse FW memory addresses via mailbox TLV\n\nImplement GP1 mailbox interrupt handling to receive memory region\naddresses from firmware via a TLV-based protocol. When firmware sends\na BUILD_SPECIFIC_RESOURCES_MAPPING mailbox message, the driver reads\na TLV table from device memory containing addresses and sizes of\ndebug memory regions (exception dump, DCCM, SDS, ECL, SMEM).\n\nThis enables the driver to dynamically discover dump region locations\ninstead of using hardcoded addresses, supporting current and future\nIntel BT PCIe controller variants.\n\nReplace per-device hardcoded exception memory address and size\nconstants in btintel_pcie_read_hwexp() with the dynamically populated\nvalues from dump_info, making exception dump handling consistent with\nother dump regions.\n\nKey changes:\n- Rewrite GP1 handler to parse mailbox registers and queue TLV work\n- Add btintel_parse_mbox_tlv() for parsing FW-provided TLV data\n- Add mbox_work workqueue for deferred TLV processing\n- Store parsed region addresses in btintel_pcie_dump_mem_info\n- Add cnvi_bt field to btintel_data for HW variant identification\n- Rename fw_git_sha1 to fw_sha for consistency\n- Remove hardcoded HWEXP address/size macros and use dump_info\n\nAssisted-by: GitHub-Copilot:claude-opus-4.7\nSigned-off-by: Chandrashekar Devegowda \u003cchandrashekar.devegowda@intel.com\u003e\nSigned-off-by: Kiran K \u003ckiran.k@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "be766d775060e0049e7ee798b968d3bd649eb553", "tree": "41b9a6a293a75f3bdabd00c5ce9db3ca42b3c4fa", "parents": [ "e4d6d16f1be19752f1119555b8cdb388ef2964c9" ], "author": { "name": "Xin Chen", "email": "xin.chen2@oss.qualcomm.com", "time": "Wed Aug 19 21:53:21 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Wed Aug 19 12:43:48 2026 -0400" }, "message": "Bluetooth: hci_core: use skb_get() instead of skb_clone() for req_skb\n\nBT enable fails intermittently with -ETIMEDOUT (-110). The kernel log\nshows the HCI Read Local Version command was sent and the firmware\nreplied with status 0x00 (logged by hci_req_cmd_complete() BT_DBG),\nbut the waiter in __hci_cmd_sync_sk() never woke up and timed out\nafter 10 s:\n\n bluetooth hci0: Opcode 0xfc00 // __hci_cmd_sync_sk\n bluetooth hci0: opcode 0xfc00 plen 1 // hci_cmd_sync_add\n bluetooth hci0: skb len 4 // hci_cmd_sync_alloc\n bluetooth hci0: length 1 // hci_req_sync_run\n Bluetooth: hci0 cmd_cnt 1 cmd queued 1 // hci_cmd_work\n Bluetooth: hci0 type 1 len 4 // hci_send_frame\n Bluetooth: opcode 0xfc00 status 0x00 // hci_req_cmd_complete\n \u003c-- req_skb NULL: req_complete_skb not set,\n hci_cmd_sync_complete() never called,\n req_status stays HCI_REQ_PEND --\u003e\n \u003c-- 10 s later: wait_event_interruptible_timeout expires --\u003e\n bluetooth hci0: end: err -110 // __hci_cmd_sync_sk\n\nThe root cause is that hci_send_cmd_sync() clones the sent command\ninto hdev-\u003ereq_skb so that hci_req_cmd_complete() can locate the\nregistered completion callback. Under memory pressure this\nskb_clone() fails, leaving hdev-\u003ereq_skb NULL. The firmware reply\nis received and processed, but hci_req_cmd_complete() finds NULL\nreq_skb, so hci_cmd_sync_complete() is never called, req_status\nstays HCI_REQ_PEND, and the waiter times out with -ETIMEDOUT.\n\nreq_skb is only used to read bt_cb(skb)-\u003ehci callbacks and opcode --\nit is never modified. Replace skb_clone() with skb_get(), which\nsimply increments the reference count of hdev-\u003esent_cmd without\nallocating new memory and therefore cannot fail.\n\nThis issue was first observed as a use-after-free in ttyport_close()\nwhen ttyport_open() failed, which was investigated in an earlier\npatch series [1]. That investigation led to the discovery of the\ntrue root cause described above.\n\n[1] https://lore.kernel.org/all/20250430111617.1151390-1-quic_cxin@quicinc.com/\n\nFixes: 2615fd9a7c25 (\"Bluetooth: hci_sync: Fix overwriting request callback\")\nCc: stable@vger.kernel.org\nSigned-off-by: Xin Chen \u003cxin.chen2@oss.qualcomm.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "e4d6d16f1be19752f1119555b8cdb388ef2964c9", "tree": "6adad7e91d03660938d9a6114e50c0396750759d", "parents": [ "d2d1c215ce1170b219fff16e7c0471b316b97685" ], "author": { "name": "Valentin Kindschi", "email": "valentin.kindschi@fiveco.ch", "time": "Tue Aug 18 15:29:35 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Aug 18 16:01:12 2026 -0400" }, "message": "Bluetooth: hci_event: clear HCI_LE_ADV only on a created connection\n\nle_conn_complete_evt() clears HCI_LE_ADV before looking at the event\nstatus, on the premise stated in its comment that all controllers stop\nadvertising when a connection is created.\n\nThat premise only holds when a connection was actually created. On a\nnon-zero status none was, and the controller is still advertising: after\nthe host issues LE Create Connection Cancel the event arrives with\nUnknown Connection Identifier (0x02), and a connection timeout behaves\nthe same way. Clearing the flag there leaves the host believing\nadvertising is off while the controller has it on.\n\nIt is also wrong for extended advertising, where several sets can be\nadvertising at once. hci_cc_le_set_ext_adv_enable() is careful about\nthis - on disabling one set it walks hdev-\u003eadv_instances and only clears\nHCI_LE_ADV once no instance is still enabled. The unconditional clear\nhere discards that bookkeeping, so one set connecting drops the flag\nwhile the others keep advertising.\n\nThe direction of the error matters. A flag left set is self-correcting:\nhci_disable_advertising_sync() sends LE Set Advertising Enable(0) and\nthe command complete puts the state back. A flag left clear is not,\nbecause that same function returns early without sending anything while\nthe flag is clear:\n\n - LE Set Advertising Parameters is then sent to a controller that is\n still advertising, and is correctly rejected with Command Disallowed\n (0x0c);\n - hci_enable_advertising_sync() returns at that point, before the\n LE Set Advertising Enable that would set HCI_LE_ADV again.\n\nOn a controller without LE Extended Advertising that is reachable from\nhere: hci_schedule_adv_instance_sync() re-arms adv_instance_expire every\nHCI_DEFAULT_ADV_DURATION (2 s) and its \"already advertising\" shortcut\ntests HCI_LE_ADV, which can no longer become true, so the parameter\nwrite is retried for as long as advertising is configured:\n\n Bluetooth: hci0: Opcode 0x2006 failed: -16\n\nOnly clear the flag when a connection was established.\n\nNote this is not on its own sufficient to stop that retry loop - the\nredundant enable queued by hci_le_conn_failed() clears HCI_LE_ADV itself\nand recreates the same mismatch, which patch 1 addresses. This patch\nfixes the event handler reporting a state the controller is not in.\n\nVerified on the affected device (BCM43455, legacy advertising only) with\nthis patch and patch 1 applied. A 221 s btmon capture with an out-of-range\npeer at -90 dBm contains two outgoing connection attempts that the host\ncancelled, each producing exactly the event this patch changes:\n\n \u003c LE Set Advertising Parameters 0x2006 Success\n \u003c LE Set Advertising Enable 0x200a Success\n \u003c LE Create Connection Cancel 0x200e Success\n \u003e LE Connection Complete Unknown Connection Identifier (0x02), central\n\nNothing follows either one; the next command is an unrelated scan restart\n70 ms later. Over the whole capture: 7 LE Set Advertising Parameters sent,\nall Success; 10 LE Set Advertising Enable, all Success; no Command\nDisallowed of any opcode, and no 2 s cadence anywhere. Two central\nconnections to other peers completed normally afterwards, with feature\nexchange and a connection parameter update, so advertising was still live\nacross the cancelled attempts.\n\nThe extended advertising case above is a code argument, not a measurement:\nthis controller has no LE Extended Advertising, so that path is not\nexercised by the capture.\n\nFixes: fbd96c151cdc (\"Bluetooth: Fix clearing HCI_LE_ADV for LE connections\")\nCc: stable@vger.kernel.org\nAssisted-by: Claude:claude-opus-5 btmon\nSigned-off-by: Valentin Kindschi \u003cvalentin.kindschi@fiveco.ch\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "d2d1c215ce1170b219fff16e7c0471b316b97685", "tree": "d5ba0fe8bf9ad83905328113d31dd52621722fd0", "parents": [ "b03f74d42e24970bb20a3044ad8ccfe04ead61a7" ], "author": { "name": "Valentin Kindschi", "email": "valentin.kindschi@fiveco.ch", "time": "Tue Aug 18 15:29:34 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Aug 18 16:01:09 2026 -0400" }, "message": "Bluetooth: hci_conn: re-enable advertising only for peripheral role\n\nhci_le_conn_failed() unconditionally calls hci_enable_advertising(),\nalthough its own comment states advertising should be re-enabled only\nwhen the failed attempt was made as a peripheral.\n\nhci_le_conn_failed() is reached from hci_conn_failed() for every failed\nLE connection, including outgoing central connections. For a central\nattempt this enable is redundant: hci_le_create_conn_sync() already\nrestores advertising via hci_resume_advertising_sync() in its done:\nblock. Because hci_enable_advertising() only queues the work on\ncmd_sync_work, it runs *after* that resume has already succeeded and\nset HCI_LE_ADV.\n\nThe resulting HCI sequence, captured on a BCM43455 (no LE Extended\nAdvertising, so legacy advertising is used):\n\n LE Create Connection Status Success\n ... 13.8 s, peer never answers ...\n LE Set Advertising Parameters (0x2006) Success \u003c- done: resume,\n LE Set Advertising Enable (0x200a) Success HCI_LE_ADV set\n LE Create Connection Cancel (0x200e) Success\n LE Connection Complete Unknown Conn Id\n LE Set Advertising Parameters (0x2006) Command Disallowed (0x0c)\n\nThe last command is the queued enable from hci_le_conn_failed() running\nas a second hci_enable_advertising_sync() pass. It clears HCI_LE_ADV\n(hci_sync.c, \"Clear the HCI_LE_ADV bit temporarily\"), then sends\nLE Set Advertising Parameters while the controller is still advertising,\nwhich the controller correctly rejects with Command Disallowed.\n\nThe disable-first call at the top of hci_enable_advertising_sync()\ncannot prevent this: hci_disable_advertising_sync() returns early\nwithout sending anything when HCI_LE_ADV is clear, so it is a no-op\nexactly when the flag is wrong.\n\nhci_enable_advertising_sync() then returns without sending LE Set\nAdvertising Enable, so HCI_LE_ADV is never set again. The legacy\nsoftware rotation loop re-arms hci_schedule_adv_instance_sync() every\nHCI_DEFAULT_ADV_DURATION (2 s), and its \"already advertising\" shortcut\ntests HCI_LE_ADV, which can no longer become true. The command is\ntherefore retried every 2 s indefinitely:\n\n Bluetooth: hci0: Opcode 0x2006 failed: -16\n\nObserved on a gateway as 5326 occurrences over 3 hours, ending only when\nbluetoothd was restarted. Connection attempts that succeed do not call\nhci_le_conn_failed() and never trigger this.\n\nAdd the role test the comment already describes. Both other\nhci_enable_advertising() call sites reached from a failed/closed LE\nconnection (hci_cs_disconnect() and hci_disconn_complete_evt()) already\nguard on conn-\u003erole \u003d\u003d HCI_ROLE_SLAVE; this one was missed.\n\nReproducing needs legacy advertising (ext_adv_capable() false, so the\nsoftware rotation loop is used), simultaneous peripheral advertising and\noutgoing central connects, and a central connect that times out rather\nthan failing fast.\n\nThe Fixes tag points at the commit that introduced the advertising\nrestart into this path for the directed-advertising (peripheral) case;\nthe role test that the later commit 0b1db38ca26b (\"Bluetooth: Fix check\nfor direct advertising\") added to the sibling paths was never applied\nhere.\n\nFixes: 3c857757ef6e (\"Bluetooth: Add directed advertising support through connect()\")\nCc: stable@vger.kernel.org\nAssisted-by: Claude:claude-opus-5 btmon\nSigned-off-by: Valentin Kindschi \u003cvalentin.kindschi@fiveco.ch\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "b03f74d42e24970bb20a3044ad8ccfe04ead61a7", "tree": "9133642b109df57fd40ab27496a22c06fdbdd2df", "parents": [ "762385e8620095062238d5ce527905a68c552a85" ], "author": { "name": "Shuai Zhang", "email": "shuai.zhang@oss.qualcomm.com", "time": "Tue Aug 18 19:41:16 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Aug 18 14:13:10 2026 -0400" }, "message": "Bluetooth: mgmt: reply to cancelled mgmt commands instead of silently dropping\n\nThe kernel sets HCI_AUTO_OFF when a controller is first registered and\nstarts a 2-second timer. On slower boots bluetoothd and the HCI_AUTO_OFF\ntimer can race: hci_power_off() is already queued while bluetoothd is\nstill in the middle of its adapter setup sequence. hci_cmd_sync_clear()\nthen cancels any pending mgmt commands with -ECANCELED, including the\nMGMT_OP_REMOVE_ADV_MONITOR sent by reset_adv_monitors() early in the\nsetup sequence.\n\nWhen auto_off\u003d1, hci_dev_close_sync() skips __mgmt_power_off() entirely,\nso there is no fallback path to reply to the cancelled commands.\nmgmt_remove_adv_monitor_complete() silently returns on -ECANCELED, leaving\nthe command with no reply. Since bluez\u0027s mgmt queue is strictly serialised,\nthis stalls all subsequent commands indefinitely, leaving bluetoothd unable\nto register the adapter.\n\nFix by mapping -ECANCELED to MGMT_STATUS_CANCELLED in mgmt_errno_status()\nand replying to the cancelled command in mgmt_remove_adv_monitor_complete()\ninstead of returning early.\n\nSigned-off-by: Shuai Zhang \u003cshuai.zhang@oss.qualcomm.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "762385e8620095062238d5ce527905a68c552a85", "tree": "e291e1503d08befc614e2df2da4720f1f48812bd", "parents": [ "57f558cf1a3d333bd6c9601f48459c1f60ecf5bb" ], "author": { "name": "Lorenzo Stoakes (ARM)", "email": "ljs@kernel.org", "time": "Tue Aug 18 10:49:34 2026 +0100" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Aug 18 14:12:50 2026 -0400" }, "message": "Bluetooth: hci_bcm4377: Ignore reserved PHY in ext adv reports on BCM4378\n\nCommit ed2a2ef16a6b (\"Bluetooth: Add quirk to ignore reserved PHY bits in\nLE Extended Adv Report\") added a quirk to handle creative use of the\nreserved bits in the PHY fields for 4388 controllers in Apple silicon.\n\nI observed the same issue with the BCM4378 Bluetooth controller (14e4:5f69,\nrev 05) on an Apple MacBook Pro (13-inch, M2, 2022):\n\n\u003e HCI Event: LE Meta Event (0x3e) plen 51\n LE Extended Advertising Report (0x0d)\n Num reports: 1\n Entry 0\n Event type: 0x2513\n Props: 0x0013\n Connectable\n Scannable\n Use legacy advertising PDUs\n Data status: Complete\n Reserved (0x2500)\n Legacy PDU Type: Reserved (0x2513)\n Address type: Random (0x01)\n Address: EA:C1:82:F0:24:C6 (Static)\n Primary PHY: Reserved\n Secondary PHY: No packets\n SID: no ADI field (0xff)\n TX power: 127 dBm\n RSSI: -57 dBm (0xc7)\n Periodic advertising interval: 0.00 msec (0x0000)\n Direct address type: Public (0x00)\n Direct address: 00:00:00:00:00:00 (OUI 00-00-00)\n Data length: 25\n\nThis results in the firmware rejecting connection attempts with\n\"Unsupported Feature or Parameter Value\" (0x11).\n\nFix the issue by using the same quirk for BCM4378 devices too.\n\nI tested this locally and confirmed that the issue is resolved.\n\nThis was observed when attempting to connect a Kinesis Advantage 360\nkeyboard to the MacBook.\n\nAssisted-by: Claude:claude-fable-5\nFixes: 2e7ed5f5e69b (\"Bluetooth: hci_sync: Use advertised PHYs on hci_le_ext_create_conn_sync\")\nCc: stable@vger.kernel.org\nSigned-off-by: Lorenzo Stoakes (ARM) \u003cljs@kernel.org\u003e\nReviewed-by: Sven Peter \u003csven@kernel.org\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "57f558cf1a3d333bd6c9601f48459c1f60ecf5bb", "tree": "115a9b1f19f596e2fe3f96551c40b0c2333a7427", "parents": [ "14a97a38ba8f2208fd394cebaa3889566d6869f5" ], "author": { "name": "Ibrahim Abdelkader", "email": "iabdelka@qti.qualcomm.com", "time": "Mon Aug 17 22:50:16 2026 +0200" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Aug 18 14:10:33 2026 -0400" }, "message": "Bluetooth: hci_core: Return -ENOMEM when the sent_cmd clone fails\n\nhci_send_cmd_sync() returns -EINVAL when skb_clone() fails for sent_cmd,\nwhich describes an invalid argument rather than an allocation failure.\n\nReturn -ENOMEM instead. The only caller, hci_cmd_work(), tests the result\nfor zero, so there is no functional change.\n\nSigned-off-by: Ibrahim Abdelkader \u003ciabdelka@qti.qualcomm.com\u003e\nSigned-off-by: Hans de Goede \u003cjohannes.goede@oss.qualcomm.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "14a97a38ba8f2208fd394cebaa3889566d6869f5", "tree": "fab600d8bd822ca37d97831905afbeeb43c300a7", "parents": [ "1fcf216462ec38f634ca1955572fe01372513370" ], "author": { "name": "HyeongJun An", "email": "sammiee5311@gmail.com", "time": "Sat Aug 15 15:24:19 2026 +0900" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 17 14:24:39 2026 -0400" }, "message": "Bluetooth: eir: Fix OOB read in eir_get_service_data()\n\neir_get_service_data() walks the advertising data for a Service Data\nfield with a matching UUID. On a mismatch it advances:\n\n eir +\u003d dlen;\n eir_len -\u003d dlen;\n\neir_get_data() reports dlen as the field\u0027s data length, but the field\nspans dlen + 2 bytes once its length and type bytes count, and more\nwhen non-Service-Data fields were skipped to reach it. The pointer\nlands correctly on the next field. eir_len does not, and the shortfall\ncompounds across fields until eir_get_data() reads the length and type\nbytes of a \"field\" past the end of the buffer.\n\nFor an ISO broadcast sink that buffer is hcon-\u003ele_per_adv_data[], filled\nfrom the periodic advertising reports of a remote broadcaster. A PA\npayload packed with mismatching Service Data fields walks off the array\ninto the rest of struct hci_conn. A drifted field that matches the BAA\nUUID puts those bytes in iso_pi(sk)-\u003ebase, where user space reads them\nback with getsockopt(BT_ISO_BASE).\n\nRecompute eir_len from the end of the buffer each iteration.\n\nFixes: 8f9ae5b3ae80 (\"Bluetooth: eir: Add helpers for managing service data\")\nCc: stable@vger.kernel.org\nAssisted-by: Claude:claude-opus-5\nSigned-off-by: HyeongJun An \u003csammiee5311@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "1fcf216462ec38f634ca1955572fe01372513370", "tree": "0994dda65cbc74b22984b30db3c8ecba5e15c3fa", "parents": [ "c519ffc1e2c669296b976d11f5e7a79d2f82debb" ], "author": { "name": "Ali Ahmet Memis", "email": "ali@iusegentoo.com", "time": "Fri Aug 14 18:28:48 2026 +0000" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 17 14:24:20 2026 -0400" }, "message": "Bluetooth: btnxpuart: Validate the FW dump header length\n\nnxp_process_fw_dump() pulls the ACL header off the frame and then reads\nseq_num and buf_len from a struct nxp_fw_dump_hdr placed at skb-\u003edata,\nwithout checking that the ACL payload is long enough to contain it.\n\nh4_recv_buf() collects HCI_ACL_HDR_SIZE bytes of header followed by the\nnumber of payload bytes named in that header, so skb-\u003elen is 4 + dlen\nwith dlen supplied by the controller and possibly smaller than the 8\nbyte dump header, or zero. A short frame with connection handle 0xfff\ntherefore reads both fields from beyond the received data.\n\nBeyond the read itself, buf_len is what terminates a dump: a value of\nzero makes the driver call hci_devcd_complete() and reset the\ncontroller, so a truncated frame can end a dump early.\n\nUse skb_pull_data() to validate and pull the FW dump header before\naccessing its fields. Warn and reject the chunk if the header is\ntruncated.\n\nFixes: 998e447f443f (\"Bluetooth: btnxpuart: Add support for HCI coredump feature\")\nSigned-off-by: Ali Ahmet Memis \u003cali@iusegentoo.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "c519ffc1e2c669296b976d11f5e7a79d2f82debb", "tree": "4ba7b05ea00df62dc5ee871f04431b4fde0d0609", "parents": [ "a3dd57c495646a7b56f7b9e64f37a6d9b27e5254" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sun Aug 16 12:47:05 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 17 14:24:03 2026 -0400" }, "message": "Bluetooth: enable context analysis for headers\n\nRemove context analysis suppression for include/net/bluetooth/*, now\nthat previous commits have resolved the warnings.\n\nReviewed-by: Bart Van Assche \u003cbvanassche@acm.org\u003e\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "a3dd57c495646a7b56f7b9e64f37a6d9b27e5254", "tree": "438fd65445183c72b67014d6e3d44d7cb6dd05cf", "parents": [ "a7b612da9059f045103bad244a0adba9e233c63d" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sun Aug 16 12:47:04 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 17 14:23:44 2026 -0400" }, "message": "Bluetooth: L2CAP: add locking annotations for l2cap_chan_lock/unlock\n\nAdd minimal context analysis annotations to l2cap_chan_lock/unlock() and\ncallers required for no warnings.\n\nReviewed-by: Bart Van Assche \u003cbvanassche@acm.org\u003e\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "a7b612da9059f045103bad244a0adba9e233c63d", "tree": "024ea7e4e79ea68d3b5fa05f92178c664cf9c762", "parents": [ "26cf20d065b31a9a591ec01086e7661fbd80040c" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sun Aug 16 12:47:03 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 17 14:23:26 2026 -0400" }, "message": "Bluetooth: L2CAP: avoid maybe-return-locked in l2cap_get_chan_by_scid/dcid\n\nReplace the maybe-return-locked pattern in l2cap_get_chan_by_scid/dcid()\nby doing locking in the caller after NULL check. This allows adding\ncontext analysis annotations for the locking.\n\nReviewed-by: Bart Van Assche \u003cbvanassche@acm.org\u003e\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "26cf20d065b31a9a591ec01086e7661fbd80040c", "tree": "35b17d52c94f738c4f9f56225877da1f2fd258c9", "parents": [ "f4fe51177b82176080035025754d89f8e730f72f" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sun Aug 16 11:59:01 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 17 14:21:30 2026 -0400" }, "message": "Bluetooth: hci_sync: add conditional locking annotations\n\nAdd context analysis annotations to functions doing conditional locking,\nto suppress analysis warnings.\n\nFixes: cdc36db204ff (\"Bluetooth: hci_sync: Fix advertising data UAFs\")\nTested-by: Nathan Chancellor \u003cnathan@kernel.org\u003e # build\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "f4fe51177b82176080035025754d89f8e730f72f", "tree": "3258f91cf3c40f41340bd01f11a147565669db18", "parents": [ "f716a05f496718a7f70a7765291ad8e7858c81a2" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sun Aug 16 13:26:21 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 17 14:21:04 2026 -0400" }, "message": "Bluetooth: hci_core: add lockdep check to hci_conn lookups\n\nAdd lockdep check for RCU || hdev-\u003elock in hci_conn_hash lookups that\nreturn hci_conn pointer, as dereferencing that without locks can be\nTOCTOU issue. It used to be several callsites did not hold appropriate\nlocks.\n\nThe check is equivalent to removing rcu_read_lock() and doing instead\nlist_for_each_entry_rcu(c, \u0026h-\u003elist, list, lockdep_is_held(\u0026hdev-\u003elock))\nAlthough there should not be any remaining callsites without locks,\ndon\u0027t remove the rcu_read_lock() for now, and just add the warning here.\n\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "f716a05f496718a7f70a7765291ad8e7858c81a2", "tree": "9555594bcc563142ebb75fcde7d7f5a77cbda2ee", "parents": [ "262cb784c96cbcd4cb511466e492b2f077135341" ], "author": { "name": "Sherry Sun", "email": "sherry.sun@nxp.com", "time": "Mon Aug 17 10:27:39 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 17 14:19:46 2026 -0400" }, "message": "Bluetooth: btnxpuart: Check remote M.2 connector availability before pwrseq\n\nThe current code uses of_graph_is_present() to decide whether to enter\nthe pwrseq path. However, of_graph_is_present() only checks for the\nstructural presence of a port/ports sub-node and does not check the\nstatus property. This causes problems when a DT overlay disables the\nremote M.2 connector node (e.g., switching from PCIe WiFi to SDIO WiFi):\nthe port node still exists, so of_graph_is_present() returns true, but\nthe pwrseq provider never registers because the connector is disabled,\nleading to an infinite -EPROBE_DEFER loop.\n\nReplace of_graph_is_present() with a new helper that traverses the OF\ngraph to the remote port parent (the M.2 connector node) and checks\nof_device_is_available(). When the remote connector is disabled, the\npwrseq path is skipped, allowing the BT driver to fall through to the\ndirect bluetooth child node path.\n\nFixes: e48e332d84d8 (\"Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq\")\nSigned-off-by: Sherry Sun \u003csherry.sun@nxp.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "262cb784c96cbcd4cb511466e492b2f077135341", "tree": "8f4e8595717ad6559186f12e1895582c63e16afc", "parents": [ "951d9f743029bc73032aa32140ed3ca5af47de18" ], "author": { "name": "Chris Lu", "email": "chris.lu@mediatek.com", "time": "Mon Aug 17 17:53:32 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 17 14:12:00 2026 -0400" }, "message": "Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path\n\nbtmtksdio_tx_packet() rounds the transfer size up to the SDIO block size\nof 256 bytes, but hands the host controller the SKB buffer as is:\n\n\terr \u003d sdio_writesb(bdev-\u003efunc, MTK_REG_CTDR, skb-\u003edata,\n\t\t\t round_up(skb-\u003elen, MTK_SDIO_BLOCK_SIZE));\n\nOnly skb-\u003elen bytes hold packet data, so the controller reads up to 255\nbytes of uninitialised memory and sends it to the device over the SDIO\nbus. Depending on how much tailroom slack the SKB allocation happens to\ncarry, that read can also extend past the end of the buffer.\n\nCompute the padded length up front, ensure the SKB has tailroom for it,\nand zero-fill the padding with skb_put_zero(). skb-\u003elen then covers the\npadding, so sdio_writesb() no longer needs to round up. byte_tx keeps\ncounting the header and the payload only, and the error path restores the\nSKB so that the caller can requeue it.\n\nWriting behind skb-\u003etail is only safe because the driver owns the buffer,\nwhich \"Bluetooth: btmtksdio: Take exclusive ownership of the SKB before\nTX\" ensures.\n\nFixes: 9aebfd4a2200 (\"Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices\")\nSigned-off-by: Chris Lu \u003cchris.lu@mediatek.com\u003e\nAssisted-by: Claude:claude-opus-5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "951d9f743029bc73032aa32140ed3ca5af47de18", "tree": "97030d3dcc1ba23468b30827264aaf788865da41", "parents": [ "54c03e6bc71882a46f6f4fe2fd09409950c7c814" ], "author": { "name": "Chris Lu", "email": "chris.lu@mediatek.com", "time": "Mon Aug 17 17:53:31 2026 +0800" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 17 14:11:57 2026 -0400" }, "message": "Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX\n\nbtmtksdio_tx_packet() prepends the MediaTek SDIO header with skb_push()\nand writes into that space after only checking the headroom size. On a\ncloned SKB that headroom belongs to a buffer shared with the other owner,\nwhich the driver has no right to write to.\n\nCloned SKBs do reach this path: hci_send_cmd_sync() keeps a clone of every\nHCI command in hdev-\u003esent_cmd before handing the SKB to the driver, and\nl2cap_ertm_send() clones SKBs for retransmission.\n\nReplace the open-coded headroom check with skb_cow_head(), which both\nguarantees the headroom and reallocates a private buffer when the SKB is\ncloned. The cost is one reallocation and copy per cloned packet, the usual\nprice of this pattern in network drivers.\n\nThis has no observable effect on its own, as the driver only writes in\nfront of skb-\u003edata where no other owner looks. It is a prerequisite for\n\"Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path\", which\nwrites padding behind skb-\u003etail, and carries the same Fixes: tag so that\nboth are backported together.\n\nFixes: 9aebfd4a2200 (\"Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices\")\nSigned-off-by: Chris Lu \u003cchris.lu@mediatek.com\u003e\nAssisted-by: Claude:claude-opus-5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "54c03e6bc71882a46f6f4fe2fd09409950c7c814", "tree": "d17d49079fd85381e5df18205d6c57ecc7460c8c", "parents": [ "771e812f94b320614147b7cd64d0a7b1186933ea" ], "author": { "name": "Ismail Tarim", "email": "ismailtarim7@gmail.com", "time": "Sat Aug 15 14:56:24 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 17 14:11:55 2026 -0400" }, "message": "Bluetooth: btmtk: Do not discard the subsystem reset timeout\n\nWhen the MTK_BT_RST_DONE poll times out, btmtk_usb_subsys_reset() logs\n\"Reset timeout\" and keeps the error in err, but err is then overwritten\nby the return value of the following btmtk_usb_id_get() call, so the\ntimeout is never reported to the caller.\n\nCommit 25b6d7593a3a (\"Bluetooth: btmtk: introduce btmtk reset work\")\ndiscarded the return value of the chip id read, so the function returned\nthe timeout error as intended. Commit 3dcb122b3064 (\"Bluetooth: btusb:\nmediatek: return error for failed reg access\") started assigning err at\nthat call and silently dropped it.\n\nKeep the timeout in a separate variable and return it, restoring the\noriginal behaviour without changing the control flow.\n\nFixes: 3dcb122b3064 (\"Bluetooth: btusb: mediatek: return error for failed reg access\")\nSigned-off-by: Ismail Tarim \u003cismailtarim7@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "771e812f94b320614147b7cd64d0a7b1186933ea", "tree": "6541264d903e8ee1851d0caf7810d4f79bd81509", "parents": [ "d67f4a43e7ef8cff8aa8fe1df2f088390af41b6d" ], "author": { "name": "Ismail Tarim", "email": "ismailtarim7@gmail.com", "time": "Sat Aug 15 14:56:23 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Mon Aug 17 14:11:52 2026 -0400" }, "message": "Bluetooth: btmtk: Do not report success when subsys reset fails\n\nbtmtk_usb_subsys_reset() validates the subsystem reset by reading the\nchip id back. When that read succeeds at the bus level but yields an id\nof zero, the reset has demonstrably not taken effect: the function logs\n\"Can\u0027t get device id, subsys reset fail.\" and then returns the return\nvalue of btmtk_usb_id_get(), which in that case is zero, i.e. success.\n\nbtusb_mtk_reset() returns that value unchanged, so its caller cannot\ntell a completed reset from a failed one.\n\nReturn -ENODEV when the chip id reads back as zero, leaving the existing\nMT6639 exemption intact.\n\nObserved on an MT7902 [13d3:3579]. The path can be reached on demand by\nasking the controller for a coredump, since btmtk requests a reset once\nthe dump completes:\n\n # echo 1 \u003e /sys/class/bluetooth/hci0/device/coredump\n\n Bluetooth: hci0: Mediatek coredump end\n Bluetooth: hci0: Can\u0027t get device id, subsys reset fail.\n usb 3-10: reset high-speed USB device number 5 using xhci_hcd\n usb 3-10: device descriptor read/64, error -110\n usb usb3-port10: attempt power cycle\n usb usb3-port10: unable to enumerate USB device\n\nThe same sequence occurs unprompted when the controller firmware asserts\non its own.\n\nNote that this corrects the error reporting only; it does not by itself\nmake the controller recoverable in the case above.\n\nFixes: 25b6d7593a3a (\"Bluetooth: btmtk: introduce btmtk reset work\")\nSigned-off-by: Ismail Tarim \u003cismailtarim7@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "d67f4a43e7ef8cff8aa8fe1df2f088390af41b6d", "tree": "702e0bb7c516aaf6080fdfb41208f66240811ca8", "parents": [ "99672791e9c9f56257075ad95c285f03a6309720" ], "author": { "name": "Pauli Virtanen", "email": "pav@iki.fi", "time": "Sat Aug 08 12:08:45 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Aug 11 15:47:38 2026 -0400" }, "message": "Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan\n\nFor L2CAP sockets without owning sk-\u003esk_socket, reading\nl2cap_pi(sk)-\u003echan may race against concurrent l2cap_sock_kill() -\u003e\nl2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks,\nbut access in l2cap_sock_cleanup_listen() has unsafe lockless read.\n\n [Task 1] [Task 2 (hdev-\u003eworkqueue)]\n l2cap_sock_release(parent) l2cap_disconn_cfm\n l2cap_sock_cleanup_listen l2cap_conn_del\n bt_accept_dequeue l2cap_chan_del\n lock_sock(sk) l2cap_sock_teardown_cb\n bt_accept_unlink\n bt_sk(sk)-\u003eparent \u003d NULL\n release_sock(sk) ----------------\u003e lock_sock(sk)\n parent \u003d /* NULL */\n lock_sock(sk) \u003c--------------------- release_sock(sk)\n sock_set_flag(sk, SOCK_ZAPPED)\n l2cap_sock_close_cb\n l2cap_sock_kill(sk)\n l2cap_sock_put_chan\n chan \u003d READ l2cap_pi(sk)-\u003echan l2cap_pi(sk)-\u003echan \u003d NULL\n l2cap_chan_hold_unless_zero l2cap_put_chan(chan)\n kref_get_unless_zero(\u0026chan-\u003eref)\n\nTask 1 may observe NULL which causes null-ptr-deref.\n\nFix the race by taking lock_sock() in l2cap_sock_kill() to\nsynchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not\nneeded here, l2cap_pi(sk)-\u003echan owns reference if it is non-NULL.\n\nClarify code comments vs. locking.\n\nFixes: 6fef032af009 (\"Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()\")\nReported-by: syzbot+e6382a2f53f5fc7453ac@syzkaller.appspotmail.com\nCloses: https://syzkaller.appspot.com/bug?extid\u003de6382a2f53f5fc7453ac\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" }, { "commit": "99672791e9c9f56257075ad95c285f03a6309720", "tree": "a98e47ac81da542fdae72d71fa9ca7078e3fad81", "parents": [ "3ea6bd32027681ca83780fdad398804bdb5e3e4d" ], "author": { "name": "Pavel Shpakovskiy", "email": "pashpakovskii@salutedevices.com", "time": "Sat Aug 08 19:31:11 2026 +0300" }, "committer": { "name": "Luiz Augusto von Dentz", "email": "luiz.von.dentz@intel.com", "time": "Tue Aug 11 15:47:21 2026 -0400" }, "message": "Bluetooth: mgmt: fix \u0027hdev-\u003ediscovery.uuids\u0027 NULL dereference\n\n\u0027uuid_count\u0027 member of struct \u0027discovery_state\u0027 is assigned and read\nwithout any locks, so there is a chance of situation when\nuuid_count !\u003d 0, but uuids is NULL and there will be NULL pointer\ndereference.\n\nPossible race:\n\u0027hci_update_passive_scan_sync\u0027\n \u0027hci_discovery_filter_clear\u0027\n hdev-\u003ediscovery.uuid_count \u003d 0;\n \u003c----------------------preempted-----------------------------\u003e\n \u0027start_service_discovery\u0027\n // Set uuid_count to value !\u003d 0\n hdev-\u003ediscovery.uuid_count \u003d uuid_count;\n hdev-\u003ediscovery.uuids \u003d kmemdup(...);\n \u003c----------------------preempted-----------------------------\u003e\n spin_lock(\u0026hdev-\u003ediscovery.lock);\n kfree(hdev-\u003ediscovery.uuids);\n hdev-\u003ediscovery.uuids \u003d NULL;\n spin_unlock(\u0026hdev-\u003ediscovery.lock);\n\nNow uuids \u003d\u003d NULL and uuid_count !\u003d 0.\nSo \u0027mgmt_device_found\u0027 -\u003e \u0027is_filter_match\u0027 -\u003e \u0027eir_has_uuids\u0027 receives\nnon consistent discovery state, where NULL dereference of uuids happens.\n\nTo fix it let\u0027s add discovery.lock around every read/write of uuid_count,\nuuids pair of struct members. It is also important to assign uuid_count\nvalue only after success kmemdup() allocation in\nstart_service_discovery(), otherwise uuids is NULL, because kmemdup failed,\nbut uuid_count is already assigned to non zero value.\n\nThe following panic happens:\n\n[ ] ------------[ cut here ]------------\n[ ] Unable to handle kernel NULL pointer dereference at virtual\naddress 0000000000000000\n[ ] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP\n[ ] CPU: 0 PID: 15056 Comm: kworker/u9:2\n[ ] Workqueue: hci0 hci_rx_work\n[ ] pstate: 10400009 (nzcV daif +PAN -UAO -TCO -DIT -SSBS BTYPE\u003d--)\n[ ] pc : eir_has_uuids+0x2d8/0x590\n[ ] lr : is_filter_match+0x258/0x320\n...\n[ ] Call trace:\n[ ] eir_has_uuids+0x2d8/0x590\n[ ] is_filter_match+0x258/0x320\n[ ] mgmt_device_found+0x5b0/0xafc\n[ ] process_adv_report.part.0+0x8c8/0xf14\n[ ] hci_le_adv_report_evt+0x338/0x3f0\n[ ] hci_le_meta_evt+0x1f0/0x4c8\n[ ] hci_event_packet+0x440/0xc9c\n[ ] hci_rx_work+0x44c/0xaf8\n[ ] process_one_work+0x54c/0x103c\n[ ] worker_thread+0x6c4/0x10c4\n[ ] kthread+0x274/0x2ec\n[ ] ret_from_fork+0x10/0x20\n[ ] Code: 14000004 91004021 eb14003f 54000180 (f9400024)\n[ ] ---[ end trace 0000000000000000 ]---\n\nFixes: 2935e556850e (\"Bluetooth: hci_sync: fix double free in \u0027hci_discovery_filter_clear()\u0027\")\nSigned-off-by: Pavel Shpakovskiy \u003cpashpakovskii@salutedevices.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n" } ], "next": "3ea6bd32027681ca83780fdad398804bdb5e3e4d" }