)]}'
{
  "log": [
    {
      "commit": "27731ba091954eccddb2657053b590d2113e8d98",
      "tree": "4a9908151e413ba1286265f9831e147ae1ca69c4",
      "parents": [
        "185c11232d5f586489bb3b74e6bcc7a6560ddd40",
        "9b3b269829faa3a6264588cff6ef28da0ca5cee5"
      ],
      "author": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Tue Oct 20 14:11:14 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Tue Oct 20 14:11:14 2026 -0400"
      },
      "message": "Merge branch \u0027bluetooth\u0027 into bluetooth-next\n"
    },
    {
      "commit": "9b3b269829faa3a6264588cff6ef28da0ca5cee5",
      "tree": "4a9908151e413ba1286265f9831e147ae1ca69c4",
      "parents": [
        "f633dda3283bceb4927bb39aded249a7a2478ac1"
      ],
      "author": {
        "name": "Valentin Kindschi",
        "email": "valentin.kindschi@fiveco.ch",
        "time": "Tue Oct 20 12:51:50 2026 +0200"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Tue Oct 20 14:09:15 2026 -0400"
      },
      "message": "Bluetooth: hci_sync: pause advertising for the scan address update\n\nhci_active_scan_sync() programs a non-resolvable private address with LE\nSet Random Address on every active scan start.\n\nBLUETOOTH CORE SPECIFICATION Vol 4, Part E, 7.8.4 says the controller\nshall return Command Disallowed (0x0C) for that command while legacy\nadvertising or scanning is enabled. hci_pause_addr_resolution(), called\njust above, only stops advertising when LL privacy is in use, so on a\ncontroller without it the command is issued while advertising is still\non:\n\n  Bluetooth: hci0: Opcode 0x2005 failed: -16\n\nIt does not converge either. hdev-\u003erandom_addr is only set on a\nsuccessful command complete, so it stays BDADDR_ANY, and the deferral\nadded by commit c2994b008492 (\"Bluetooth: hci_sync: Fix not setting\nRandom Address when required\") requires it to be set. Unlike the\nresolvable address a few lines above, which is reused while rpa_valid(),\nthe non-resolvable one is regenerated and rewritten on every call, so a\ncontroller that refuses the write is asked again at the scan restart\nperiod of about 10 s, for as long as discovery keeps restarting.\nObserved on a BCM43455, which has no LL privacy and no extended\nadvertising, 190 rejections in one capture, every one retrying the same\naddress:\n\n  \u003c LE Set Random Address  Address: 02:16:91:90:F1:D4 (Non-Resolvable)\n  \u003e Command Complete       LE Set Random Address, Command Disallowed\n  \u003c LE Set Random Address  Address: 26:90:57:96:9A:3E (Non-Resolvable)\n  \u003e Command Complete       LE Set Random Address, Command Disallowed\n\nPause advertising for the address update, and resume it once the update\nis done and before the scan is started. The pause does not outlive the\nfunction: it is taken only when nothing else holds it, and every exit\nresumes advertising, which also releases the pause taken by\nhci_pause_addr_resolution(). A failed pause returns before marking\nanything paused, so the error path is a no-op.\n\nThe resume in the error path is no longer guarded by ll_privacy_capable().\nThat guard matched a pause taken only under LL privacy; the pause added\nhere is unconditional, and hci_resume_advertising_sync() returns early\nwhen nothing was paused.\n\nOne caveat this widens, raised on the previous posting. When\nHCI_ADVERTISING is set, hci_pause_advertising_sync() also clears\nHCI_DISCOVERABLE and HCI_LIMITED_DISCOVERABLE and zeroes discov_timeout,\nand hci_resume_advertising_sync() restores only HCI_ADVERTISING, so the\ndiscoverable state is lost. It reproduces today on an LL privacy\ncontroller through hci_pause_addr_resolution(); the unconditional pause\nmakes it reachable without LL privacy as well. hci_suspend_sync() also\npauses unconditionally, so a device that suspends loses the same state\non any controller today. That asymmetry is pre-existing and is left\nalone here rather than folded into a scan path fix.\n\nLegacy controllers have one random address register, shared by the\nscanner and the advertiser. Restoring the advertiser here can reprogram\nit when the advertiser is non-connectable, so the scan then uses that\naddress rather than the one generated for it. Both are non-resolvable\nand neither is linkable to the identity address. With privacy enabled\nboth roles already share one resolvable address the same way.\n\nWith the patch, on the same hardware:\n\n  \u003c LE Set Advertising Enable    Enable: 0x00              Success\n  \u003c LE Set Random Address                                  Success\n  \u003c LE Set Advertising Parameters                          Success\n  \u003c LE Set Advertising Enable    Enable: 0x01              Success\n  \u003c LE Set Scan Parameters                                 Success\n  \u003c LE Set Scan Enable           Enable: 0x01              Success\n\nThe address write is accepted, and advertising is restored before the\nscan is started.\n\nOver 119369 btmon records and about 12 minutes of the normal workload of\nthat device, alternating active and passive scanning with ten outgoing\nconnection attempts, every LE Set Random Address succeeded and there were\nno Command Disallowed responses of any opcode, against one per scan\nrestart before.\n\nPatch 1 is required: without it the resume added here returns -EPERM on\nthe controllers this fixes and leaves advertising disabled.\n\nFixes: 3c44a431d62b (\"Bluetooth: hci_sync: Resume adv with no RPA when active scan\")\nCc: stable@vger.kernel.org\nAssisted-by: Claude:claude-opus-5.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": "f633dda3283bceb4927bb39aded249a7a2478ac1",
      "tree": "0b029305c73bb1486919a07fda2cedb29a6b9356",
      "parents": [
        "fd0191d9375d3f9a775b1e77c1864c28dea5f097"
      ],
      "author": {
        "name": "Valentin Kindschi",
        "email": "valentin.kindschi@fiveco.ch",
        "time": "Tue Oct 20 12:51:49 2026 +0200"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Tue Oct 20 14:08:52 2026 -0400"
      },
      "message": "Bluetooth: hci_sync: re-enable legacy advertising on resume\n\nhci_resume_advertising_sync() never re-enables advertising on a\ncontroller without extended advertising.\n\nIt restores HCI_ADVERTISING from advertising_old_state, then calls\nhci_schedule_adv_instance_sync(), which starts with:\n\n  if (hci_dev_test_flag(hdev, HCI_ADVERTISING) \u0026\u0026 !ext_adv_capable(hdev))\n          return -EPERM;\n\nThe flag it tests was set a few lines earlier by the resume itself, so\nthe call returns -EPERM without sending anything. The return value is\ndiscarded by every caller, so the failure is silent: advertising_paused\nis cleared, HCI_ADVERTISING is set, and the controller is not\nadvertising.\n\nObserved on a BCM43455 (no extended advertising) after an active scan:\nbtmon shows the pause disabling advertising and no re-enable in the ten\nseconds that follow, the device does not appear in another controller\u0027s\nscan, and btmgmt info still reports \"advertising\" in current settings.\n\nEnable instance 0x00 directly in that case, the way reenable_adv_sync()\nalready does for the same situation. Instances continue to go through\nhci_schedule_adv_instance_sync() so the software rotation loop is\nrearmed.\n\nThis affects every caller of hci_resume_advertising_sync(), not only the\nscan path: address resolution changes, accept list updates, discovery\nstop, suspend/resume and the end of an LE connection attempt all leave\nadvertising disabled on such a controller today.\n\nThe resume does nothing when the controller is already advertising, as\nit is after directed advertising was started for a peripheral\nconnection, so it does not replace that advertising.\n\nerr is initialised because the extended branch leaves it unset when\nadv_instances is empty and HCI_LE_ADV_0 is clear.\n\nFixes: ad383c2c65a5 (\"Bluetooth: hci_sync: Enable advertising when LL privacy is enabled\")\nCc: stable@vger.kernel.org\nAssisted-by: Claude:claude-opus-5.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": "fd0191d9375d3f9a775b1e77c1864c28dea5f097",
      "tree": "dea0f94c9cc201844af5e5eeb1b4ac2d431646f8",
      "parents": [
        "153c30aec42d8bde1bc5ac826410d72baf52ffff"
      ],
      "author": {
        "name": "Binbin Deng",
        "email": "18983559317@163.com",
        "time": "Mon Oct 19 18:56:24 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Tue Oct 20 14:08:30 2026 -0400"
      },
      "message": "Bluetooth: hci_core: Initialize LTK before publication\n\nhci_add_ltk() publishes a newly allocated LTK on hdev-\u003elong_term_keys\nbefore initializing its address, type, value, authentication state,\nencryption size, EDIV, and random value.  hci_find_ltk() and the debugfs\nlong_term_keys_show() traverse this list under RCU and can therefore see\na zero or partially initialized key before those stores complete.\n\nThe race is reachable by racing an LTK addition with another CPU looking\nup or dumping long-term keys.  For example, userspace can issue\nMGMT_OP_LOAD_LONG_TERM_KEYS while another process reads the corresponding\ndebugfs file.\n\nInitialize all fields of a new LTK before list_add_rcu() makes it visible\nto RCU readers.  Existing LTKs remain published and continue to be updated\nin place.\n\nFound during a static-analysis-assisted audit: candidate sites were\nsurfaced by a Coccinelle rule, and the reader/writer paths were\nconfirmed by LLM-assisted (GLM-5.3) code inspection.  The issue was\nnot observed at runtime; it is identified by code inspection only.\n\nFixes: 970d0f1b2803 (\"Bluetooth: Convert LTK list to RCU\")\nAssisted-by: GLM-5.3 coccinelle\nSigned-off-by: Binbin Deng \u003c18983559317@163.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "153c30aec42d8bde1bc5ac826410d72baf52ffff",
      "tree": "f0e6bd5558f9b1af9128fd8449da49740a998d2d",
      "parents": [
        "7404cfafe3e218a4bfe1c5adcd11e05765a0025a"
      ],
      "author": {
        "name": "Binbin Deng",
        "email": "18983559317@163.com",
        "time": "Mon Oct 19 16:17:11 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Tue Oct 20 14:08:05 2026 -0400"
      },
      "message": "Bluetooth: hci_core: Initialize link key before publication\n\nhci_add_link_key() allocates a new link key with kzalloc(), inserts it into\nhdev-\u003elink_keys with list_add_rcu(), and only then initializes its address,\nvalue, type, and PIN length.  RCU readers such as hci_find_link_key()\nand the debugfs link_keys_show() do not take hci_dev_lock, so they can\ntraverse the new entry during that initialization window and observe\na zero or partially initialized key.\n\nThis can be triggered by racing a link-key update with another CPU looking\nup or dumping keys.  In particular, userspace can issue\nMGMT_OP_LOAD_LINK_KEYS while another process reads the corresponding\ndebugfs file.\n\nComplete all fields of a newly allocated key before publishing it with\nlist_add_rcu().  Existing keys remain visible and keep their current\nin-place update behavior.\n\nFound during a static-analysis-assisted audit: candidate sites were\nsurfaced by a Coccinelle rule, and the reader/writer paths were\nconfirmed by LLM-assisted (GLM-5.3) code inspection.  The issue was\nnot observed at runtime; it is identified by code inspection only.\n\nFixes: 0378b5977013 (\"Bluetooth: Convert link keys list to use RCU\")\nSigned-off-by: Binbin Deng \u003c18983559317@163.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "7404cfafe3e218a4bfe1c5adcd11e05765a0025a",
      "tree": "7449a07309f42d402df8335f149721bb6b9cc7dd",
      "parents": [
        "185c11232d5f586489bb3b74e6bcc7a6560ddd40"
      ],
      "author": {
        "name": "Binbin Deng",
        "email": "18983559317@163.com",
        "time": "Mon Oct 19 19:16:11 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Tue Oct 20 14:07:43 2026 -0400"
      },
      "message": "Bluetooth: hci_core: Initialize IRK before publication\n\nhci_add_irk() initializes the identity address and address type of a newly\nallocated IRK, publishes it on hdev-\u003eidentity_resolving_keys, and only then\ninitializes its value and RPA.  RCU readers such as hci_find_irk_by_rpa()\nand the debugfs identity_resolving_keys_show() can traverse the new entry\nduring that window and see a zero or partially initialized IRK.\n\nThe race is reachable by racing an IRK addition with another CPU resolving\nor dumping IRKs.  In particular, userspace can issue MGMT_OP_LOAD_IRKS\nwhile another process reads the corresponding debugfs file or triggers RPA\nresolution.\n\nInitialize the IRK value and RPA before publishing a newly allocated IRK.\nExisting IRKs remain published and continue to be updated in place.\n\nFound during a static-analysis-assisted audit: candidate sites were\nsurfaced by a Coccinelle rule, and the reader/writer paths were\nconfirmed by LLM-assisted (GLM-5.3) code inspection.  The issue was\nnot observed at runtime; it is identified by code inspection only.\n\nFixes: adae20cb2d20 (\"Bluetooth: Convert IRK list to RCU\")\nAssisted-by: GLM-5.3 coccinelle\nSigned-off-by: Binbin Deng \u003c18983559317@163.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "185c11232d5f586489bb3b74e6bcc7a6560ddd40",
      "tree": "69907c84c1c30283b1e93374f4f8f1117c7e3507",
      "parents": [
        "f600f753cc323b9cb95aaf9dfc3b7708bf806b1b"
      ],
      "author": {
        "name": "Eric Dumazet",
        "email": "edumazet@kernel.org",
        "time": "Fri Oct 16 17:03:14 2026 +0200"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Fri Oct 16 11:16:56 2026 -0400"
      },
      "message": "Bluetooth: hci_nokia: use skb_put_padto()\n\nskb_pad() does not change skb-\u003elen, callers have to follow it\nwith skb_put(), which is error prone.\n\nUse skb_put_padto() instead of the open-coded sequence in\nnokia_enqueue().\n\nSigned-off-by: Eric Dumazet \u003cedumazet@kernel.org\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "f600f753cc323b9cb95aaf9dfc3b7708bf806b1b",
      "tree": "48e77fb993dda35de0d1535571cd5638d3b71f23",
      "parents": [
        "09399227b038c239ef6fe574157dc664910658ca"
      ],
      "author": {
        "name": "Sai Teja Aluvala",
        "email": "aluvala.sai.teja@intel.com",
        "time": "Fri Oct 16 08:29:21 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Fri Oct 16 11:16:52 2026 -0400"
      },
      "message": "Bluetooth: btintel_pcie: add HW rfkill interrupt/doorbell flow\n\nAdd host-driven HW rfkill handling for Intel PCIe Bluetooth\ncontrollers and report state changes to the Bluetooth stack through\nhci_rfkill_set_hw_state(). The GP2 and HW_RFKILL MSI-X hardware\ncauses are enabled so that the host can detect a HW rfkill assertion\nand hand its acknowledgment back to firmware.\n\nOn a HW_RFKILL interrupt, a delayed worker reads the FUNC_CTRL and\nIPC_CONTROL registers to determine whether the switch is asserted or\nreleased. On assertion, the worker marks HW rfkill as active and\nreports a blocked state directly. On release, it clears the\nIPC_CONTROL HW rfkill doorbell bit, waits for the firmware\u0027s GP2\nacknowledgment that matches the requested transition, and reports\nan unblocked state to the stack only once that acknowledgment\narrives. A release is only handled once FUNC_CTRL shows the switch\nreleased, as IPC_CONTROL may still hold the acknowledgment sent by\nshutdown while the switch is asserted. IPC_CONTROL register\nread-modify-write updates and the wait state/done flags are\nserialized with a new ipc_lock, which the GP2 handler also takes, so\na late acknowledgment of a timed-out doorbell cannot complete the\nnext one. A new rfkill_doorbell_lock serializes the doorbell\ntransitions of the worker and shutdown.\n\nThe worker does nothing until setup has completed, as firmware is\nnot ready for the handshake before then. After a successful setup\nor resume, an initial state check is scheduled. That check reports\nan already-asserted HW rfkill state, and also reports a release if\nrfkill was asserted before suspend and cleared while the controller\nwas asleep; otherwise it is a no-op so it cannot suppress a later\ngenuine transition.\n\nThe HW_RFKILL MSI-X cause is masked before synchronizing interrupts\nand canceling or draining the worker across reset, probe failure,\nremove, and suspend, and is unmasked again after setup and resume\nsucceed. GP2 is left enabled throughout.\n\nMonitoring stays enabled across shutdown, so HW rfkill events are\nstill reported while HCI is down. On an active assertion, shutdown\nsets the doorbell bit and waits for the GP2 acknowledgment right\nbefore the HCI reset, since firmware accepts no other command after\nit. An assertion while HCI is down needs no doorbell, as the\ncontroller is already off. Firmware accepts HCI reset in any HW\nrfkill state, so shutdown relies on the cached state; an assertion\nthe worker has not seen yet is handled like one while HCI is down.\n\nSince a masked cause still latches, the MSI-X handler only queues the\nworker while HW_RFKILL is unmasked, and remove and probe failure\ndisable the worker so it cannot be requeued after data is freed.\n\nSigned-off-by: Sai Teja Aluvala \u003caluvala.sai.teja@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "09399227b038c239ef6fe574157dc664910658ca",
      "tree": "ad5564084181912bb728b954798c8c5d4db4cbbd",
      "parents": [
        "e3bb245b2daf1d7d9414027333e8a0a82052cbf4"
      ],
      "author": {
        "name": "Sai Teja Aluvala",
        "email": "aluvala.sai.teja@intel.com",
        "time": "Fri Oct 16 08:29:20 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Fri Oct 16 11:16:47 2026 -0400"
      },
      "message": "Bluetooth: Add HCI interface for HW rfkill events\n\nAdd hci_rfkill_set_hw_state() so that transport drivers can report\nhardware rfkill switch changes to the HCI stack through the same\npath used for software rfkill.\n\nhci_rfkill_set_hw_state() checks HCI_UNREGISTER under\nhdev-\u003eunregister_lock and schedules a new hdev-\u003erfkill_block work\nitem while still holding that lock, so hci_unregister_dev() cannot\ndestroy hdev-\u003erfkill before the work runs. The hardware state is\nenforced even when no rfkill device exists (e.g. CONFIG_RFKILL\u003dn).\nOn release, if not soft blocked, HCI_RFKILLED is cleared before\nrfkill core sends its async event, so a userspace power-on triggered\nby that event does not observe a stale flag.\n\nA new hdev-\u003erfkill_lock serializes hci_rfkill_set_hw_state(),\nhdev-\u003erfkill_block and the rfkill core\u0027s set_block callback. The\nrfkill state is read and HCI_RFKILLED updated under that lock, so a\nhardware rfkill event and a concurrent userspace soft block/unblock\ncannot leave a stale state applied. The reported hardware state is\ntracked in a new HCI_HW_RFKILLED flag, and a soft unblock keeps\nHCI_RFKILLED set while it is set, so the controller cannot be\npowered on under a hard block. The soft state accepted by set_block\nis tracked in a new HCI_SW_RFKILLED flag, and hdev-\u003erfkill_block\ncombines the two. The rfkill core state is not read, as around\nset_block it may still hold a change that is about to be reverted.\n\nWhile a user channel is open, the set_block callback still refuses\nsoft rfkill with -EBUSY. A HW rfkill block cannot be refused, so\nhdev-\u003erfkill_block sets HCI_RFKILLED but leaves the device up for the\nuser channel; once it is closed, the flag blocks the next power on.\n\nSigned-off-by: Sai Teja Aluvala \u003caluvala.sai.teja@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "e3bb245b2daf1d7d9414027333e8a0a82052cbf4",
      "tree": "1095f6a5aa6191d02b28d9183f6fba4124ce97ed",
      "parents": [
        "76e76945eb79014a89341af1bf5611f3e6173b24"
      ],
      "author": {
        "name": "Ton Sharp",
        "email": "66ton99@gmail.com",
        "time": "Thu Oct 15 14:49:01 2026 +0300"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Thu Oct 15 15:37:26 2026 -0400"
      },
      "message": "Bluetooth: hci_event: strip Broadcom vendor bits from legacy adv report type\n\nBroadcom controllers running ROM firmware on Apple T2 Macs (where no\nRAM patchram exists, e.g. BCM4364B3 on MacBookPro16,1) set vendor bits\n0x10/0x20/0x80 in the legacy LE Advertising Report Event_Type.\n\nAs a result, directed advertisements (ADV_DIRECT_IND) arrive as\n0x81/0x91/0xa1 instead of 0x01. Because process_adv_report() drops any\nlegacy report with type \u003e LE_ADV_SCAN_RSP (0x04) as an unknown advertising\npacket type, bonded LE peripherals (such as Apple Magic Mouse/Keyboard)\nand Chrome passkey proximity scans fail to discover or reliably reconnect\nto the host.\n\nThe valid legacy type is always located in the low nibble. Mask the type\nfield for Broadcom controllers (manufacturer 15) when it is out of range.\nValid legacy reports (0x00-0x04) remain untouched, low nibbles \u003e\u003d 5 remain\nout of range and will continue to be dropped, and controllers from other\nmanufacturers are unaffected.\n\nThe fix is based on the initial t2linux patch from Jose Miguel Ochoa.\n\nLink: https://lore.kernel.org/r/3352A23E-EA42-4366-BBAA-459CEAE6F51B@live.com\nSuggested-by: Jose Miguel Ochoa \u003cjosemiguelo.ochoa@gmail.com\u003e\nSigned-off-by: Ton Sharp \u003c66ton99@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "76e76945eb79014a89341af1bf5611f3e6173b24",
      "tree": "3153dfd5ce0c9b726f79c93de2809d4dd260ebf1",
      "parents": [
        "ff8b09806b7b18884ad8d3a2b3d702da534a4e21"
      ],
      "author": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Thu Oct 15 11:37:52 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Thu Oct 15 11:37:52 2026 -0400"
      },
      "message": "Bluetooth: hci_sync: Fix invalid Supervision_Timeout in LE Set Default Rate\n\nThe LE Set Default Rate Parameters command is rejected with Invalid HCI\nCommand Parameters (0x12) because the Supervision_Timeout of 120 ms is\nexactly the minimum recommended by HOGP v1.2:\n\n  Greater than or equal to (1 + Peripheral Latency) x Subrate max x\n  Connection Interval max x 2\n\nBut the Core spec treats the equality as invalid:\n\nBLUETOOTH CORE SPECIFICATION Version 6.3 | Vol 4, Part E\n7.8.158. LE Set Default Rate Parameters command\n\n  If Connection_Interval_Max x Subrate_Max x (Max_Latency + 1) is\n  greater than or equal to Supervision_Timeout x 40, the Controller\n  shall return the error code Invalid HCI Command Parameters (0x12).\n\nWith the current values 0x78 x 4 x 1 \u003d 480 \u003e\u003d 0x0c x 40 \u003d 480.\n\nFix this by using 2 s as the default Supervision_Timeout, which is 10x\nlower than the 20 s used for non-SCI connections while still well above\nthe minimum required, and make sure it remains above the minimum in\ncase interval_max is raised to match the controller\u0027s minimum supported\nconnection interval.\n\nFixes: 2f8784cfe8a9 (\"Bluetooth: Add support for Shorter Connection Interval (SCI) feature\")\nAssisted-by: OpenCode:claude-opus-5.5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "ff8b09806b7b18884ad8d3a2b3d702da534a4e21",
      "tree": "a8810fe1278d2745d1508b794b4319f0df643dd2",
      "parents": [
        "d52ecdd482cfa4cd4da448ada4fee4f864f98daa"
      ],
      "author": {
        "name": "Ajaykv",
        "email": "ajay.k.v@intel.com",
        "time": "Thu Oct 15 14:54:31 2026 +0300"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Thu Oct 15 09:33:39 2026 -0400"
      },
      "message": "Bluetooth: btintel_pcie: Configure YoYo DBGC buffer allocations\n\nParse DBGC buffer allocation TLVs for DBGC1 through DBGC3. Validate the\nallocation ID, DRAM location, fragment count, requested size, and\nminimum fragment size before storing each allocation.\n\nUse configured fragment counts and sizes for DMA buffers, firmware\ncontext descriptors, and coredump collection. On MDBGC devices, omit\nunconfigured buffer IDs when YoYo is enabled; retain legacy allocations\nwhen YoYo configuration is absent or invalid. Single-DBGC devices use\nDBGC1.\n\nSigned-off-by: Ajaykv \u003cajay.k.v@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "d52ecdd482cfa4cd4da448ada4fee4f864f98daa",
      "tree": "c38944eb8d42b4639e6afcd516d76e51e1aeb313",
      "parents": [
        "4268806901dca8351fc2f25dcbaa665701fd49bc"
      ],
      "author": {
        "name": "Ajaykv",
        "email": "ajay.k.v@intel.com",
        "time": "Thu Oct 15 14:54:30 2026 +0300"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Thu Oct 15 09:33:39 2026 -0400"
      },
      "message": "Bluetooth: btintel_pcie: Validate the YoYo DEBUG_INFO TLV\n\nRequire a DEBUG_INFO TLV in the YoYo firmware configuration. Validate\nits payload length, version, Bluetooth domain, external image type,\nand Bluetooth core type before accepting the configuration.\n\nReject missing or invalid metadata so the driver keeps legacy DBGC\ndefaults instead of enabling an incompatible configuration.\n\nSigned-off-by: Ajaykv \u003cajay.k.v@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "4268806901dca8351fc2f25dcbaa665701fd49bc",
      "tree": "a09e3c7349aba42d234e7f25719001da937a64e0",
      "parents": [
        "397464709a204da9b8dc3b01d6ea42539d951cd2"
      ],
      "author": {
        "name": "Ajaykv",
        "email": "ajay.k.v@intel.com",
        "time": "Thu Oct 15 14:54:29 2026 +0300"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Thu Oct 15 09:33:39 2026 -0400"
      },
      "message": "Bluetooth: btintel_pcie: Add initial YoYo debug support\n\nAdd an optional YoYo firmware configuration path to the Intel PCIe\nBluetooth driver. Read DBG_PATH and ENABLE_INI from\nibt_bt_dbg_cfg.ini, and load intel/ibt_debug_yoyo.bin only when YoYo\nis enabled and host DRAM routing is selected.\n\nIntroduce a runtime context and bounded TLV-stream validation helper.\nInitialize and clean up the context with PCI probe and removal, while\nfalling back to legacy debug behavior if optional YoYo data is missing\nor invalid.\n\nRuntime validation of the complete P1-P3 series produced:\n[    3.286504] Bluetooth: Core ver 2.22\n[    3.297359] Bluetooth: HCI device and connection manager initialized\n[    3.297373] Bluetooth: HCI socket layer initialized\n[    3.297376] Bluetooth: L2CAP socket layer initialized\n[    3.297384] Bluetooth: SCO socket layer initialized\n[    3.332848] Bluetooth: YoYo: configuration loaded and validated\n[3.360857-3.361712] Bluetooth: DBGC1-3: each 16 x 256 KiB (4 MiB)\n[3.361715] Bluetooth: MDBGC DBGC1-3: each 16 x 256 KiB\n[    3.397439] Bluetooth: hci0: Device revision is 0\n[    3.397442] Bluetooth: hci0: Secure boot is enabled\n[    3.397443] Bluetooth: hci0: OTP lock is disabled\n[    3.397444] Bluetooth: hci0: API lock is enabled\n[    3.397444] Bluetooth: hci0: Debug lock is disabled\n\nSigned-off-by: Ajaykv \u003cajay.k.v@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "397464709a204da9b8dc3b01d6ea42539d951cd2",
      "tree": "4dbdbb2ff6e1a467cfd5710dcc43e15d9cca6635",
      "parents": [
        "5874f8d03268d34189c6c12c56586b64d26a8bcc"
      ],
      "author": {
        "name": "Kyle Pepper",
        "email": "cochcoder@proton.me",
        "time": "Wed Oct 14 05:16:20 2026 +0000"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:29 2026 -0400"
      },
      "message": "Bluetooth: hci_sync: scan unfiltered for host-resolved RPAs\n\nRestore unfiltered scanning for pending IRK peers when the controller\ncannot resolve private addresses. Keep accept-list filtering while\nsuspended and when forced by periodic advertising synchronization.\n\nFixes: e209e5ccc5ac (\"Bluetooth: MGMT: Mark LL Privacy as stable\")\nAssisted-by: OpenCode:gpt-6.1-sol\nSigned-off-by: Kyle Pepper \u003ccochcoder@proton.me\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "5874f8d03268d34189c6c12c56586b64d26a8bcc",
      "tree": "80b19a8526b4aded7208982321793b6f420e1758",
      "parents": [
        "76a75454516831534f740bccf7b18f98753c67e2"
      ],
      "author": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Tue Oct 13 09:58:32 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:29 2026 -0400"
      },
      "message": "Bluetooth: Fix the LE Read Connection Interval response layout\n\nThe response to HCI_OP_LE_READ_CONN_INTERVAL carries a\nMinimum_Supported_Connection_Interval octet between the status and\nNum_Groups, which was missing from the structure. Without it the minimum\ninterval was read as the number of groups, and every group after it\nfrom one octet off.\n\nTake the minimum interval used to clamp the default rate parameters from\nthat field rather than the smallest group minimum, as the number of\ngroups can be zero, which left it unset.\n\nFixes: 2f8784cfe8a9 (\"Bluetooth: Add support for Shorter Connection Interval (SCI) feature\")\nAssisted-by: OpenCode:claude-opus-5.5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "76a75454516831534f740bccf7b18f98753c67e2",
      "tree": "49123db9fa0bcdbdd2a592ad8359aa3ad907c657",
      "parents": [
        "a518b9a9ef6ee3b18ecdf6ba5360c608aaf969e9"
      ],
      "author": {
        "name": "Siwei Zhang",
        "email": "oss@fourdim.xyz",
        "time": "Tue Oct 13 11:36:38 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:28 2026 -0400"
      },
      "message": "Bluetooth: L2CAP: Remove dead configuration state code\n\nCONF_EWS_RECV has not been set since commit\ne7b02296fb40 (\"Bluetooth: Remove BT_HS\"), which\nmade configuration requests with an EWS option\nbe refused. Remove the flag and the branch in\nl2cap_parse_conf_req() that tests it.\n\nA pending connection response no longer needs to\nset CONF_CONNECT_PEND, as connection responses are\nonly accepted while it is already set.\n\nNo functional change.\n\nAssisted-by: Claude:claude-opus-5-5\nSigned-off-by: Siwei Zhang \u003coss@fourdim.xyz\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "a518b9a9ef6ee3b18ecdf6ba5360c608aaf969e9",
      "tree": "cfb6de1edeca9167bb545721e2d99f3796cbb7a3",
      "parents": [
        "226fa3b676cbf2236f803bccd347462433ffc2c8"
      ],
      "author": {
        "name": "Siwei Zhang",
        "email": "oss@fourdim.xyz",
        "time": "Tue Oct 13 11:36:37 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:28 2026 -0400"
      },
      "message": "Bluetooth: L2CAP: Only accept connection responses to outstanding requests\n\nAn outgoing channel waits in BT_CONNECT until security\nand the feature mask exchange complete, and only then\nsends its connection request. A peer can answer it\nbefore that with a connection response matching our\nsource CID. The channel then moves to BT_CONFIG,\ncompletes configuration and becomes connected before\nsecurity has completed. If security then fails,\nl2cap_security_cfm() leaves the connected channel\nalone, so it stays up on a link that did not reach\nthe required security level.\n\nA connection response with a zero source CID is\nmatched by identifier. Another channel can hold the\nsame identifier for a response it still has to send,\nso the lookup can pick the wrong channel.\n\nOnly accept a connection response while our request\nis outstanding, and only look at such channels when\nmatching by identifier.\n\nFixes: 1da177e4c3f4 (\"Linux-2.6.12-rc2\")\nCc: stable@vger.kernel.org\nAssisted-by: Claude:claude-opus-5-5\nSigned-off-by: Siwei Zhang \u003coss@fourdim.xyz\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "226fa3b676cbf2236f803bccd347462433ffc2c8",
      "tree": "43facc48e5c7da9e65b64d1a47871e623963f0bd",
      "parents": [
        "c5ebb0245fe927cf5fa33510a9cb2799c4a2dd01"
      ],
      "author": {
        "name": "Siwei Zhang",
        "email": "oss@fourdim.xyz",
        "time": "Tue Oct 13 11:36:36 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:28 2026 -0400"
      },
      "message": "Bluetooth: L2CAP: Use default TxWindow for zero socket option\n\nL2CAP_OPTIONS accepts a txwin_size of zero and\nstores it in tx_win. The zero is then sent to the\npeer in our configuration request, and if the\nchannel ends up in ERTM mode it is passed to\nl2cap_seq_list_init().\n\nUse the default TxWindow instead, as the mode can\nstill be changed to ERTM during configuration.\n\nFixes: 14b5aa71ec50 (\"Bluetooth: Add sockopt configuration for txWindow on L2CAP\")\nCc: stable@vger.kernel.org\nSigned-off-by: Siwei Zhang \u003coss@fourdim.xyz\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "c5ebb0245fe927cf5fa33510a9cb2799c4a2dd01",
      "tree": "cf60eb5f59db8460be7aa122ec0a55d0e012a048",
      "parents": [
        "6320736af7dcb90da6ee9fd651ecc11c564d45b7"
      ],
      "author": {
        "name": "Siwei Zhang",
        "email": "oss@fourdim.xyz",
        "time": "Tue Oct 13 11:36:35 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:28 2026 -0400"
      },
      "message": "Bluetooth: L2CAP: Reject invalid TxWindow in configuration requests\n\nA peer can send an ERTM RFC option with a TxWindow\nof zero, which is out of spec. It is stored in\nremote_tx_win unchanged and later passed to\nl2cap_seq_list_init(), where roundup_pow_of_two(0)\nis undefined. On some architectures this results in\na ZERO_SIZE_PTR list and a remote kernel oops.\n\nA TxWindow above 63 is out of spec as well. With\n6-bit sequence numbers we would then send more\nunacknowledged frames than the sequence space can\ntell apart.\n\nReply with L2CAP_CONF_UNACCEPT and propose the\ndefault TxWindow instead of accepting the value, so\nremote_tx_win always stays within 1 to 63. Keep the\nparameters of an earlier request then, and do not\ntreat the request as done because an earlier one was.\n\nAlso refuse a zero size in l2cap_seq_list_init(), so\nany other path that reaches it with a zero TxWindow\nfails the channel instead of the kernel.\n\nFixes: f2fcfcd67025 (\"Bluetooth: Add configuration support for ERTM and Streaming mode\")\nCc: stable@vger.kernel.org\nAssisted-by: Claude:claude-opus-5-5\nSigned-off-by: Siwei Zhang \u003coss@fourdim.xyz\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "6320736af7dcb90da6ee9fd651ecc11c564d45b7",
      "tree": "a208674d7bcdf5c0a08067f586d494d9e61c1a1c",
      "parents": [
        "c1398cf11b31a94c27ed810ba69515e0df5ce379"
      ],
      "author": {
        "name": "Siwei Zhang",
        "email": "oss@fourdim.xyz",
        "time": "Tue Oct 13 11:36:34 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:27 2026 -0400"
      },
      "message": "Bluetooth: L2CAP: Reject signalling responses in invalid states\n\nA peer can send configuration messages while an\nincoming channel is in BT_CONNECT2, before the\nsecurity or deferred accept gate has completed. A\nconfiguration response can then promote the channel\nto BT_CONNECTED. Configuration responses can also\nact on channels that are closing, and a late connection\nresponse can move a disconnecting channel back to\nBT_CONFIG.\n\nAccept connection responses only while waiting in\nBT_CONNECT. Answer configuration requests in\nBT_CONNECT2, but defer our own request until\nBT_CONFIG so configuration cannot complete before\nthe gate. Ignore configuration responses outside\nBT_CONFIG and BT_CONNECTED, and only complete\nconfiguration in BT_CONFIG.\n\nFixes: 1da177e4c3f4 (\"Linux-2.6.12-rc2\")\nCc: stable@vger.kernel.org\nAssisted-by: Claude:claude-opus-5-5\nSigned-off-by: Siwei Zhang \u003coss@fourdim.xyz\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "c1398cf11b31a94c27ed810ba69515e0df5ce379",
      "tree": "e82d47271cc89a23ce16b962428a29a5a5ca1dc7",
      "parents": [
        "91638f53ff2b8234195ff27ec913e068269a28e9"
      ],
      "author": {
        "name": "Siwei Zhang",
        "email": "oss@fourdim.xyz",
        "time": "Tue Oct 13 11:36:33 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:27 2026 -0400"
      },
      "message": "Bluetooth: L2CAP: Reject mode changes on connected channels\n\nA peer can send a configuration response with an RFC\noption for another mode to a connected channel, for\nexample to switch it from Streaming to ERTM mode.\nl2cap_parse_conf_rsp() then changes chan-\u003emode, but\nl2cap_ertm_init() is not called again, so the ERTM\nsequence lists are never allocated. The next\nout-of-sequence I-frame makes l2cap_seq_list_clear()\nwrite through the NULL srej_list.list.\n\nRefuse the channel when a response tries to change\nthe mode of a connected channel.\n\nFixes: f2fcfcd67025 (\"Bluetooth: Add configuration support for ERTM and Streaming mode\")\nCc: stable@vger.kernel.org\nCloses: https://sashiko.dev/#/patchset/20261007144717.3832330-1-oss%40fourdim.xyz\nAssisted-by: Claude:claude-opus-5-5\nSigned-off-by: Siwei Zhang \u003coss@fourdim.xyz\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "91638f53ff2b8234195ff27ec913e068269a28e9",
      "tree": "ff788edcff1f8ceecc252b1112ad5a82a08c7582",
      "parents": [
        "5ba2dc0439c629c8e4c34c8ffa1ed35d862d9371"
      ],
      "author": {
        "name": "Kevin Dewald",
        "email": "kevin@simpleble.org",
        "time": "Tue Oct 13 00:16:15 2026 -0700"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:27 2026 -0400"
      },
      "message": "Bluetooth: hci_event: Fix LE link drop on remote features command status\n\nWhen the local controller supports peripheral-initiated features\nexchange, the LE Read Remote Features procedure also runs for incoming\nconnections, and it fails with Unsupported Remote Feature (0x1a) if the\ncentral does not support that feature. hci_le_remote_feat_complete_evt()\nand hci_le_read_all_remote_features_evt() handle this and let the\nconnection transition into connected state.\n\nA controller can also return that error in the Command Status event\ninstead. An Intel controller does so for a central that does not\nsupport peripheral-initiated features exchange, presumably because it\nalready has the features of the central. hci_cs_le_read_remote_features()\nand hci_cs_le_read_all_remote_features() then confirm the connection as\nfailed while it is still in BT_CONFIG, and the hci_conn_drop() in\nle_read_features_complete() disconnects it right away:\n\n  \u003e HCI Event: LE Meta Event (0x3e) plen 31\n      LE Enhanced Connection Complete (0x0a)\n        Status: Success (0x00)\n        Role: Peripheral (0x01)\n  \u003c HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2\n  \u003e HCI Event: Command Status (0x0f) plen 4\n      LE Read Remote Used Features (0x08|0x0016) ncmd 1\n        Status: Unsupported Remote Feature / Unsupported LMP Feature (0x1a)\n  \u003c HCI Command: Disconnect (0x01|0x0006) plen 3\n        Reason: Remote User Terminated Connection (0x13)\n\nData the central sends afterwards is reported as:\n\n  Bluetooth: hci0: ACL packet for unknown connection handle 3585\n\nHandle Unsupported Remote Feature in the command status the same way as\nin the complete events.\n\nFixes: 0fe29fd1cd77 (\"Bluetooth: Read LE remote features during connection establishment\")\nFixes: a106e50be74b (\"Bluetooth: HCI: Add support for LL Extended Feature Set\")\nAssisted-by: Claude:claude-opus-5.5\nSigned-off-by: Kevin Dewald \u003ckevin@simpleble.org\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "5ba2dc0439c629c8e4c34c8ffa1ed35d862d9371",
      "tree": "f890b622a94d8d10725b8fbe00611753b58952f3",
      "parents": [
        "de2077eb216c43087b396e3eb34921bdfe18ddfc"
      ],
      "author": {
        "name": "Catherine L",
        "email": "catherine.l@intel.com",
        "time": "Tue Oct 13 14:51:28 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:27 2026 -0400"
      },
      "message": "Bluetooth: btusb: annotate Intel Otter Peak 2 USB ID\n\nMove USB ID 0x0043 next to 0x0040 to keep the Intel entries in\nnumerical order, and annotate it as Otter Peak 2 (AX231) used on\nWildcat Lake.\n\nFixes: 69bf0c2b348f (\"Bluetooth: btusb: Add support for Intel Otter Peak2 (OrP2)\")\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": "de2077eb216c43087b396e3eb34921bdfe18ddfc",
      "tree": "1c196ee1946119e987de4d092191d1a7de2cf160",
      "parents": [
        "6747a37c3e2f4dced152974b277dbc0fc9dd4516"
      ],
      "author": {
        "name": "Catherine L",
        "email": "catherine.l@intel.com",
        "time": "Tue Oct 13 15:06:50 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:26 2026 -0400"
      },
      "message": "Bluetooth: btintel_pcie: Add PCI ID for Titan Lake\n\nAdd PCI ID 0x9329 for Titan Lake (Scorpius Peak2 C0).\n\nsudo lspci -v -k -d 8086:9329\n02:00.0 Bluetooth: Intel Corporation Device 9329\n        Subsystem: Intel Corporation Device 0012\n        Flags: bus master, fast devsel, latency 0, IRQ 16\n        Memory at fe000000 (32-bit, non-prefetchable) [size\u003d16K]\n        Capabilities: [c8] Power Management version 3\n        Capabilities: [d0] MSI: Enable- Count\u003d1/1 Maskable- 64bit+\n        Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00\n        Capabilities: [80] MSI-X: Enable+ Count\u003d5 Masked-\n        Kernel driver in use: btintel_pcie\n        Kernel modules: btintel_pcie\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": "6747a37c3e2f4dced152974b277dbc0fc9dd4516",
      "tree": "b937a14c6db4a3b9b62e0394bcf8d065b5f1ee83",
      "parents": [
        "56e20c3d8ad340bbfc90221c4aae1c870485fb57"
      ],
      "author": {
        "name": "Chris Lu",
        "email": "chris.lu@mediatek.com",
        "time": "Thu Oct 08 16:55:59 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:26 2026 -0400"
      },
      "message": "Bluetooth: btmtk: Add MT7928 support\n\nAdd support for MT7928 (internal device ID is MT7935) which requires\nadditional firmware (CBMCU firmware) loading before Bluetooth firmware.\n\nCBMCU is a new component on MT7928 to handle common part shared across\nthe combo chip, providing a better user experience through improved\ncoordination between subsystems.\n\nImplement two-phase CBMCU firmware download: Phase 1 loads section with\ntype 0x5 containing global descriptor, section maps and signature data;\nPhase 2 loads remaining firmware sections. The firmware is rejected if it\nhas no Phase 1 section.\n\nThe CBMCU is shared with the Wi-Fi driver, which may download the same\nfirmware concurrently, so the firmware reports a status per section and\nhands each one to a single driver. This driver downloads a section the\nfirmware reports as not downloaded, waits while the other driver holds\nit, and leaves alone one the firmware already has. This is the scheme\nbtmtk_setup_firmware_79xx() already uses for the ROM patch shared with\nWi-Fi, so no host side lock is needed.\n\nThe driver then continues to load the corresponding BT firmware based on\ndevice ID through fallthrough to case 0x7922/0x7925. A CBMCU failure is\nonly warned about and does not abort the setup, because the Wi-Fi driver\nmay finish the same download on its own. A CBMCU left unusable makes the\nBT firmware download fail instead, which triggers the existing one-shot\nbtmtk_reset_sync() recovery.\n\nThe CBMCU firmware layout and section-map bounds are validated by\nreusing btmtk_fw_validate_layout() and btmtk_fw_validate_section(),\nthe same helpers btmtk_setup_firmware_79xx() uses, instead of\nduplicating the overflow checks.\n\nAdd the MT7928 (0x7935) case to btmtk_usb_subsys_reset(), which triggers\nthe subsystem reset by setting BIT(31) of MTK_BT_RESET_REG_CONNV3.\n\nMT7928 bring-up kernel log:\n[ 6931.197167] usb 1-3: New USB device found, idVendor\u003d0e8d, idProduct\u003d7935, bcdDevice\u003d 1.00\n[ 6931.197212] usb 1-3: New USB device strings: Mfr\u003d5, Product\u003d6, SerialNumber\u003d7\n[ 6931.197237] usb 1-3: Product: Wireless_Device\n[ 6931.197258] usb 1-3: Manufacturer: MediaTek Inc.\n[ 6931.197279] usb 1-3: SerialNumber: 000000000\n[ 6931.213478] Bluetooth: hci1: Loading CBMCU firmware: mediatek/mt7928/CBMCU_CODE_MT7935_1_1.bin\n[ 6931.215214] Bluetooth: hci1: CBMCU HW ver: 0x7935, SW ver: 0x0000, Build Time: 20260601T161751+\n[ 6931.623962] Bluetooth: hci1: CBMCU firmware download completed\n[ 6931.643916] Bluetooth: hci1: Loading BT firmware: mediatek/mt7928/BT_RAM_CODE_MT7935_1_1_hdr.bin\n[ 6931.650467] Bluetooth: hci1: BT HW ver: 0x7935, SW ver: 0x0000, Build Time: 20260527000816\n[ 6935.039790] Bluetooth: hci1: Device setup in 3369644 usecs\n[ 6935.039833] Bluetooth: hci1: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.\n[ 6935.160654] Bluetooth: hci1: AOSP extensions version v2.00\n[ 6935.160710] Bluetooth: hci1: AOSP quality report is supported\n[ 6935.162954] Bluetooth: MGMT ver 1.23\n\nSigned-off-by: Chris Lu \u003cchris.lu@mediatek.com\u003e\nAssisted-by: LLM\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "56e20c3d8ad340bbfc90221c4aae1c870485fb57",
      "tree": "b5af09bea290d9fd36f9a7956b267e756c433068",
      "parents": [
        "47493e62e8a8522a250537ed2ce026dd7d9163b1"
      ],
      "author": {
        "name": "Cen Zhang",
        "email": "zzzccc427@gmail.com",
        "time": "Mon Oct 12 10:48:06 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:26 2026 -0400"
      },
      "message": "Bluetooth: MSFT: Serialize handle map cleanup with event processing\n\nMSFT monitor handle mappings must remain valid while vendor events look\nup and use them under hdev-\u003elock. msft_do_close() removes and frees the\nmappings without that lock.\n\nhci_dev_close_sync() clears HCI_UP and drains the RX workqueue before\nMSFT cleanup. However, a transport callback that already passed\nhci_recv_frame()\u0027s state check can queue a vendor event after the drain\nreturns, if no earlier shutdown callback has quiesced reception. The\ndriver close callback runs after MSFT cleanup, so event processing can\noverlap the unlocked removal. msft_monitor_device_evt() can then\ntraverse freed list entries or read handle_data-\u003emgmt_handle after it is\nfreed.\n\nTake hdev-\u003elock while resetting monitor states and removing handle\nmappings in msft_do_close(), as normal monitor cancellation already\ndoes. An active event reader then finishes before its mapping is freed,\nand later lookups see an empty handle map.\n\nAn instrumented kernel produced this KASAN report (timestamps removed\nand unrelated frames omitted):\n\n    BUG: KASAN: slab-use-after-free in msft_vendor_evt+0x1906/0x1990\n    Read of size 2 at addr ffff888104df3602 by task kworker/u17:2/502\n\n    Workqueue: hci0 hci_rx_work\n    Call Trace:\n      [...]\n      msft_vendor_evt+0x1906/0x1990\n      hci_vendor_evt+0x6f/0x90\n      hci_event_packet+0x894/0xc70\n      [...]\n      hci_rx_work+0x3f8/0xfa0\n      [...]\n\n    Allocated by task 499:\n      [...]\n      msft_add_monitor_sync+0x6a8/0x10a0\n      msft_add_monitor_pattern+0x7f/0xb0\n      hci_add_adv_monitor+0x1fa/0x2e0\n      [...]\n\n    Freed by task 499:\n      [...]\n      kfree+0x307/0x580\n      msft_do_close+0x238/0x750\n      hci_dev_close_sync+0x546/0x1380\n      [...]\n\n    The buggy address belongs to the object at ffff888104df3600\n      which belongs to the cache kmalloc-32 of size 32\n    The buggy address is located 2 bytes inside of\n      freed 32-byte region [ffff888104df3600, ffff888104df3620)\n    [...]\n\nFixes: 145373cb1b1f (\"Bluetooth: Add framework for Microsoft vendor extension\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "47493e62e8a8522a250537ed2ce026dd7d9163b1",
      "tree": "de81b1b1920109de7ce25ff3af473d8d84eb0b63",
      "parents": [
        "154a6e79ad38253d12078e40031cd05d54dac9be"
      ],
      "author": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Mon Oct 12 11:26:59 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:26 2026 -0400"
      },
      "message": "Bluetooth: MGMT: Allow connection rate request as peripheral\n\nLoad Connection Subrate only issues the LE Connection Rate Request when\nconnected as central, but either role can initiate the Connection Rate\nUpdate procedure, e.g. a HID device, which is the peripheral, does it\nonce the HID host requests a HID SCI mode with the HID Control Point.\n\nIssue it regardless of the role.\n\nFixes: 19129d7037be (\"Bluetooth: Add MGMT Load Connection Subrate command\")\nAssisted-by: OpenCode:claude-opus-5.5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "154a6e79ad38253d12078e40031cd05d54dac9be",
      "tree": "b9f814b7c2ff01845a23e5602dc83273b00caeeb",
      "parents": [
        "cf87709d7ff83b4de5d42b61e4a9806fe374cb9d"
      ],
      "author": {
        "name": "Kiran K",
        "email": "kiran.k@intel.com",
        "time": "Thu Oct 08 19:36:02 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:25 2026 -0400"
      },
      "message": "Bluetooth: btintel: load unlocker.sfi to allow unsigned firmware\n\nWhen an unsigned operational firmware image is needed for debug, the\ncontroller requires intel/unlocker.sfi to be loaded first. Without the\nunlocker image, the controller rejects the unsigned operational firmware.\n\nSupport both firmware download flows based on the unlock policy advertised\nin the version TLV:\n\n  BlazarI/BlazarIW/BlazarU/Gale Peak (unlock_policy \u003d\u003d 0):\n      Boot ROM -\u003e unlocker.sfi -\u003e IML -\u003e OPFW\n\n  Scorpius Peak onwards (unlock_policy \u003d\u003d 1):\n      Boot ROM -\u003e IML -\u003e unlocker.sfi -\u003e OPFW\n\nParse the new INTEL_TLV_UNLOCK_POLICY and INTEL_TLV_PLATFORM_ID TLVs\ninto struct intel_version_tlv, track the pending unlocker load through\na new btintel_data::unlocker flag, and pick intel/unlocker.sfi as the\nfirmware filename when that flag is set. If the unlocker image is not\npresent in the firmware search path, the driver silently falls through\nto the normal firmware download path. If the unlocker image is present\nbut fails to download to the controller, the driver logs the error and\naborts bootloader setup, since continuing would leave the controller in\nan inconsistent state.\n\n[  413.375247] Bluetooth: hci0: Found device firmware: intel/unlocker.sfi\n[  413.501051] Bluetooth: hci0: Waiting for firmware download to complete\n[  413.501058] Bluetooth: hci0: Firmware loaded in 122864 usecs\n[  413.501537] Bluetooth: hci0: Found device firmware: intel/ibt-02a2-01a1.sfi\n[  413.501547] Bluetooth: hci0: Boot Address: 0x10001000\n[  413.501548] Bluetooth: hci0: Firmware Version: 137-39.26\n[  414.103473] Bluetooth: hci0: Waiting for firmware download to complete\n[  414.103478] Bluetooth: hci0: Firmware loaded in 587841 usecs\n[  414.149576] Bluetooth: hci0: Applying Intel DDC parameters completed\n[  414.150089] Bluetooth: hci0: Firmware timestamp 2026.39 buildtype 3 build 86921\n[  414.150092] Bluetooth: hci0: Firmware SHA1: 0xeb2e0a4b\n[  414.150093] Bluetooth: hci0: Platform ID: 570c6ffbcbe6\n[  414.150094] Bluetooth: hci0: Fseq status: Success (0x00)\n[  414.150730] Bluetooth: hci0: Fseq executed: 15.255.00.98\n[  414.150734] Bluetooth: hci0: Fseq BT Top: 06.32.00.02\n\nAssisted-by: Copilot:Claude Opus 4.7\nSigned-off-by: Ravindra \u003cravindra@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": "cf87709d7ff83b4de5d42b61e4a9806fe374cb9d",
      "tree": "fceeac7a3e6166750043d5e467ddbd1a429fa2be",
      "parents": [
        "64aabf94ecccb1120a63b4ee5a6761871a181a41"
      ],
      "author": {
        "name": "Kiran K",
        "email": "kiran.k@intel.com",
        "time": "Thu Oct 08 19:36:01 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:25 2026 -0400"
      },
      "message": "Bluetooth: btintel: Zero version data before parsing TLVs\n\nFirmware may omit optional TLVs, leaving their corresponding fields\nunset in the caller-supplied struct intel_version_tlv. Since the\nstructure is typically stack-allocated and not cleared beforehand,\nfields for which no TLV is received retain uninitialized stack\nmemory. This stale data can be logged via btintel_version_info_tlv()\nand copied back to the caller, leaking kernel stack contents.\n\nClear the structure in btintel_read_version_tlv() before parsing so\nthat fields with no corresponding TLV are deterministically zero\ninstead of containing garbage.\n\nFixes: 57375beef71a (\"Bluetooth: btintel: Add infrastructure to read controller information\")\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": "64aabf94ecccb1120a63b4ee5a6761871a181a41",
      "tree": "69285974473c42b44362ad5a5d0d77e6c494a78c",
      "parents": [
        "4020751fd0df45ce5029a5dd69e1bb68a25cb4dd"
      ],
      "author": {
        "name": "Bui Viet Dung",
        "email": "dungvn2345@gmail.com",
        "time": "Thu Oct 08 12:18:03 2026 +0700"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:25 2026 -0400"
      },
      "message": "Bluetooth: selftest: Pin module for selftest debugfs file operations\n\nAn open debugfs file retains its file_operations pointer in the\ndebugfs proxy state. However, test_smp_fops in net/bluetooth/smp.c and\ntest_ecdh_fops in net/bluetooth/selftest.c have no .owner set to\nTHIS_MODULE.\n\nAs a result, full_proxy_open_regular() calls fops_get() which succeeds\nwithout taking a reference to the bluetooth module. When CONFIG_BT\u003dm\nand selftests are enabled, a userspace process can open either\n/sys/kernel/debug/bluetooth/selftest_smp or\n/sys/kernel/debug/bluetooth/selftest_ecdh and keep the file descriptor\nopen while the module is unloaded (rmmod bluetooth).\n\nWhen the userspace process subsequently closes the descriptor,\nfull_proxy_release() accesses the already unmapped file_operations\nstructure, triggering a kernel oops in full_proxy_release():\n\n  BUG: unable to handle page fault for address: fffffbfff8056f03\n  #PF: supervisor read access in kernel mode\n  Oops: 0000 [#1] SMP KASAN NOPTI\n  RIP: 0010:full_proxy_release+0x8e/0x140\n  Call Trace:\n   \u003cTASK\u003e\n   __fput+0x39f/0xa60\n   fput_close_sync+0xff/0x200\n   __x64_sys_close+0x8c/0xf0\n   do_syscall_64+0x115/0x6a0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n   \u003c/TASK\u003e\n\nThe issue was discovered via manual code audit of net/bluetooth/smp.c\nand net/bluetooth/selftest.c.\n\nSet .owner \u003d THIS_MODULE on test_smp_fops and test_ecdh_fops so that\ndebugfs keeps the module pinned until the file descriptors are closed.\n\nFixes: 64dd374eac15 (\"Bluetooth: Export SMP selftest result in debugfs\")\nFixes: 6de50f9fdb60 (\"Bluetooth: Export ECDH selftest result in debugfs\")\nCc: stable@vger.kernel.org\nSigned-off-by: Bui Viet Dung \u003cdungvn2345@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "4020751fd0df45ce5029a5dd69e1bb68a25cb4dd",
      "tree": "33add281c2050e58eb790c5a2602b4d91399d645",
      "parents": [
        "645ee6b176c958579cff1c783413d5cff65c8197"
      ],
      "author": {
        "name": "Cen Zhang",
        "email": "zzzccc427@gmail.com",
        "time": "Thu Oct 08 12:26:26 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:25 2026 -0400"
      },
      "message": "Bluetooth: L2CAP: Hold the listener while notifying child teardown\n\nA pending child\u0027s listener must remain alive until the child\u0027s teardown\ncallback finishes notifying it. l2cap_sock_teardown_cb() saves the raw\nbt_sk(sk)-\u003eparent pointer, calls bt_accept_unlink(), then invokes\nparent-\u003esk_data_ready(). The accept queue holds a reference to the\nchild, but the callback takes no reference to the listener across\nunlink.\n\nWhen an incoming child has not been accepted, HCI disconnection can\nreach l2cap_conn_del() and the child\u0027s teardown callback while another\ntask closes the listener. The listener channel has no connection, so the\nchild\u0027s connection and channel locks do not serialize listener release.\nThe following ordering is possible:\n\n  HCI child teardown                 Listener release\n  lock the child socket\n  save parent\n  bt_accept_unlink(sk)\n                                     drain the empty accept queue\n                                     bt_sock_unlink()\n                                     shut down the listener channel\n                                     sock_orphan()\n                                     l2cap_sock_kill()\n  parent-\u003esk_data_ready(parent)\n\nIf no other reference delays freeing the listener, the final\nnotification reads sk_data_ready through freed socket storage. The child\nlock cannot stop listener release once the child is no longer on the\naccept queue.\n\nTake a listener socket reference before unlinking the child and release\nit after sk_data_ready() returns. While the child remains queued, its\nsocket lock prevents listener cleanup from completing the dequeue, so\nthe listener is still alive when the reference is acquired. The\nreference then protects the notification after unlink without changing\nlock order or the ordering of queue removal and wakeup.\n\nKASAN report as below:\n\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n    BUG: KASAN: slab-use-after-free in l2cap_sock_teardown_cb+0x467/0x490\n    Read of size 8 at addr ffff88810b99b188 by task kworker/u17:3/516\n\n    Workqueue: hci1 hci_rx_work\n    Call Trace:\n     \u003cTASK\u003e\n     dump_stack_lvl+0x93/0xd0\n     print_report+0xce/0x630\n     ? l2cap_sock_teardown_cb+0x467/0x490\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __virt_addr_valid+0x20d/0x410\n     ? l2cap_sock_teardown_cb+0x467/0x490\n     kasan_report+0xe0/0x110\n     ? l2cap_sock_teardown_cb+0x467/0x490\n     l2cap_sock_teardown_cb+0x467/0x490\n     l2cap_chan_del+0x123/0x8f0\n     l2cap_conn_del+0x31b/0x740\n     ? hci_cmd_sync_submit+0x264/0x320\n     ? __pfx_l2cap_disconn_cfm+0x10/0x10\n     l2cap_disconn_cfm+0x87/0xd0\n     hci_disconn_complete_evt+0x30f/0x990\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     hci_event_packet+0x894/0xc70\n     ? __pfx_hci_disconn_complete_evt+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __pfx_hci_event_packet+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? free_zapped_rcu+0xd0/0x1e0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lockdep_hardirqs_on_prepare+0xea/0x1a0\n     ? __pfx_hci_cmd_sync_complete+0x10/0x10\n     ? trace_hardirqs_on+0x18/0x160\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     hci_rx_work+0x367/0xf00\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     process_one_work+0x908/0x19c0\n     ? __pfx_process_one_work+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lock_is_held_type+0x8f/0x100\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     worker_thread+0x65c/0xe40\n     ? __pfx_worker_thread+0x10/0x10\n     kthread+0x34f/0x460\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __pfx_kthread+0x10/0x10\n     ret_from_fork+0x659/0x940\n     ? __pfx_ret_from_fork+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __switch_to+0x74f/0xf80\n     ? __pfx_kthread+0x10/0x10\n     ret_from_fork_asm+0x1a/0x30\n     \u003c/TASK\u003e\n\n    Allocated by task 502:\n     kasan_save_stack+0x33/0x60\n     kasan_save_track+0x14/0x30\n     __kasan_kmalloc+0xaa/0xb0\n     __kmalloc_noprof+0x2d7/0x770\n     sk_prot_alloc+0x13e/0x260\n     sk_alloc+0x37/0xb40\n     bt_sock_alloc+0x40/0x3b0\n     l2cap_sock_create+0x116/0x310\n     bt_sock_create+0x171/0x330\n     __sock_create+0x2c4/0x730\n     __sys_socket+0x141/0x210\n     __x64_sys_socket+0x77/0xc0\n     do_syscall_64+0x115/0x6a0\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n    Freed by task 502:\n     kasan_save_stack+0x33/0x60\n     kasan_save_track+0x14/0x30\n     kasan_save_free_info+0x3b/0x60\n     __kasan_slab_free+0x5f/0x80\n     kfree+0x307/0x580\n     __sk_destruct+0x64f/0x790\n     sk_destruct+0xb3/0xd0\n     __sk_free+0xdd/0x370\n     sk_free+0x51/0x80\n     l2cap_sock_kill+0x17a/0x2a0\n     l2cap_sock_release+0x1d0/0x310\n     __sock_release+0xb8/0x270\n     sock_close+0x21/0x30\n     __fput+0x39f/0xa60\n     fput_close_sync+0xff/0x200\n     __x64_sys_close+0x8c/0xf0\n     do_syscall_64+0x115/0x6a0\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n    The buggy address belongs to the object at ffff88810b99b000\n                                                                which\n                                belongs to the cache kmalloc-2k of size\n                                2048\n    The buggy address is located 392 bytes inside of\n                                                                freed\n                                2048-byte region [ffff88810b99b000,\n                                ffff88810b99b800)\n\n    The buggy address belongs to the physical page:\n        page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0\n    pfn:0x10b998\n    head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n    flags: 0x200000000000040(head|node\u003d0|zone\u003d2)\n    page_type: f5(slab)\n        raw: 0200000000000040 ffff888100042f00 dead000000000100\n    dead000000000122\n        raw: 0000000000000000 0000000000080008 00000000f5000000\n    0000000000000000\n        head: 0200000000000040 ffff888100042f00 dead000000000100\n    dead000000000122\n        head: 0000000000000000 0000000000080008 00000000f5000000\n    0000000000000000\n        head: 0200000000000003 fffffffffffffe01 00000000ffffffff\n    00000000ffffffff\n        head: 0000000000000000 0000000000000000 00000000ffffffff\n    0000000000000000\n    page dumped because: kasan: bad access detected\n\n    Memory state around the buggy address:\n     ffff88810b99b080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ffff88810b99b100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n    \u003effff88810b99b180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                          ^\n     ffff88810b99b200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ffff88810b99b280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "645ee6b176c958579cff1c783413d5cff65c8197",
      "tree": "c95a05225998de4fe3d67bcaa9e0e9e5f6e05d32",
      "parents": [
        "4b76fa362110cf1b74a0263c14406b71de99894c"
      ],
      "author": {
        "name": "Bui Viet Dung",
        "email": "dungvn2345@gmail.com",
        "time": "Thu Oct 08 11:54:13 2026 +0700"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:24 2026 -0400"
      },
      "message": "Bluetooth: hci_vhci: Pin module for debugfs file operations\n\nAn open debugfs file retains its file_operations pointer in the\ndebugfs proxy state. However, force_suspend_fops, force_wakeup_fops,\naosp_capable_fops, and force_devcoredump_fops have no .owner set to\nTHIS_MODULE. As a result, full_proxy_open_regular() calls fops_get()\nwhich succeeds without taking a reference to the hci_vhci module.\n\nWhen userspace opens any of these debugfs files and later closes\nthe /dev/vhci file descriptor (triggering vhci_release() and\ndebugfs file removal), the open debugfs file descriptor remains valid\nin userspace. Because the module refcount was not incremented,\nthe hci_vhci module can be unloaded via delete_module (rmmod hci_vhci).\n\nWhen the userspace process subsequently closes the debugfs file\ndescriptor, full_proxy_release() accesses the already unmapped\nfile_operations structure, resulting in a kernel page fault / oops:\n\n  BUG: unable to handle page fault for address: fffffbfff846f18b\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  Oops: Oops: 0000 [#1] SMP KASAN NOPTI\n  RIP: 0010:full_proxy_release+0x8e/0x140\n  Call Trace:\n   \u003cTASK\u003e\n   __fput+0x39f/0xa60\n   fput_close_sync+0xff/0x200\n   __x64_sys_close+0x8c/0xf0\n   do_syscall_64+0xc3/0x590\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   \u003c/TASK\u003e\n  Modules linked in: ... [last unloaded: hci_vhci(E)]\n\nThe issue was discovered via manual code audit of\ndrivers/bluetooth/hci_vhci.c and verified on a Linux 7.3-rc6 test VM\nwith CONFIG_BT_VHCI\u003dm by keeping a debugfs file open across controller\nteardown and module unload.\n\nSet .owner \u003d THIS_MODULE on all four file_operations structures so that\ndebugfs pins the module until all file descriptors are closed.\n\nFixes: 28010791193a (\"Bluetooth: vhci: Prevent use-after-free by removing debugfs files early\")\nCc: stable@vger.kernel.org\nSigned-off-by: Bui Viet Dung \u003cdungvn2345@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "4b76fa362110cf1b74a0263c14406b71de99894c",
      "tree": "42a8d3c9cf6354809b6f3d8c029d9f077ff38d2d",
      "parents": [
        "2a3e2287877b1ee40ffb80b7d769b633866533f3"
      ],
      "author": {
        "name": "Cen Zhang",
        "email": "zzzccc427@gmail.com",
        "time": "Thu Oct 08 12:18:50 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:24 2026 -0400"
      },
      "message": "Bluetooth: hci_sync: Protect IRK identity reads with RCU\n\nhci_le_set_privacy_mode_sync() needs the IRK returned by\nhci_find_irk_by_addr() to remain allocated until its identity address\nand type have been copied into the command. The finder drops its RCU\nread lock before returning this borrowed pointer, leaving the later\nfield reads unprotected.\n\nWhen a privacy-capable controller has a pending peer with address\nresolution and device privacy enabled, accept-list programming can\nreach this helper while management reloads the IRKs. The request\nworker holds hdev-\u003ereq_lock, whereas load_irks() takes hdev-\u003elock,\nallowing the following ordering:\n\n  Request worker                     Management / RCU reclaim\n  hci_le_set_privacy_mode_sync()\n    hci_find_irk_by_addr()\n      rcu_read_lock()\n      find matching IRK\n      rcu_read_unlock()\n      return borrowed IRK\n                                     load_irks()\n                                       hci_dev_lock(hdev)\n                                       hci_smp_irks_clear()\n                                         list_del_rcu()\n                                         kfree_rcu()\n                                       hci_dev_unlock(hdev)\n                                     RCU grace period and IRK free\n    read irk-\u003eaddr_type\n    copy irk-\u003ebdaddr\n\nThe request then accesses a freed IRK. KASAN reports a one-byte\nuse-after-free read of addr_type on this path.\n\nKeep an outer RCU read-side critical section across the lookup and\nboth identity-field copies. The finder\u0027s nested unlock then leaves\nthe IRK protected until the caller finishes copying it. Release RCU\non a lookup miss and after copying the fields, before the synchronous\nHCI command can sleep.\n\nKASAN report as below:\n\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n        BUG: KASAN: slab-use-after-free in\n    hci_le_add_accept_list_sync+0x90f/0x940\n    Read of size 1 at addr ffff88810aa6072c by task kworker/u17:0/493\n\n    Workqueue: hci0 hci_cmd_sync_work\n    Call Trace:\n     \u003cTASK\u003e\n     dump_stack_lvl+0x93/0xd0\n     print_report+0xce/0x630\n     ? hci_le_add_accept_list_sync+0x90f/0x940\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __virt_addr_valid+0x20d/0x410\n     ? hci_le_add_accept_list_sync+0x90f/0x940\n     kasan_report+0xe0/0x110\n     ? hci_le_add_accept_list_sync+0x90f/0x940\n     hci_le_add_accept_list_sync+0x90f/0x940\n     ? __pfx_hci_le_add_accept_list_sync+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? conn_params_copy+0x3a0/0x650\n     hci_passive_scan_sync+0x8c9/0x1e80\n     ? __pfx_hci_passive_scan_sync+0x10/0x10\n     ? find_held_lock+0x2b/0x80\n     ? hci_lookup_le_connect+0x181/0x3c0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? find_held_lock+0x2b/0x80\n     ? hci_update_passive_scan_sync+0x437/0x950\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lock_release+0xc8/0x280\n     hci_update_passive_scan_sync+0x461/0x950\n     hci_cmd_sync_work+0x1b3/0x450\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     process_one_work+0x908/0x19c0\n     ? __pfx_process_one_work+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lock_is_held_type+0x8f/0x100\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     worker_thread+0x65c/0xe40\n     ? __pfx_worker_thread+0x10/0x10\n     kthread+0x34f/0x460\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __pfx_kthread+0x10/0x10\n     ret_from_fork+0x659/0x940\n     ? __pfx_ret_from_fork+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __switch_to+0x74f/0xf80\n     ? __pfx_kthread+0x10/0x10\n     ret_from_fork_asm+0x1a/0x30\n     \u003c/TASK\u003e\n\n    Allocated by task 507:\n     kasan_save_stack+0x33/0x60\n     kasan_save_track+0x14/0x30\n     __kasan_kmalloc+0xaa/0xb0\n     __kmalloc_cache_noprof+0x251/0x610\n     hci_add_irk+0xb6/0x220\n     load_irks+0x5ef/0x7e0\n     hci_sock_sendmsg+0x128b/0x22e0\n     __sys_sendto+0x425/0x470\n     __x64_sys_sendto+0xe5/0x1c0\n     do_syscall_64+0x115/0x6a0\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n    Freed by task 0:\n     kasan_save_stack+0x33/0x60\n     kasan_save_track+0x14/0x30\n     kasan_save_free_info+0x3b/0x60\n     __kasan_slab_free+0x5f/0x80\n     __rcu_free_sheaf_prepare+0x65/0x2a0\n     rcu_free_sheaf+0x1f/0xe0\n     rcu_core+0x661/0x1d10\n     handle_softirqs+0x201/0x930\n     __irq_exit_rcu+0x110/0x1e0\n     irq_exit_rcu+0xe/0x20\n     sysvec_apic_timer_interrupt+0x6c/0x80\n     asm_sysvec_apic_timer_interrupt+0x1a/0x20\n\n    The buggy address belongs to the object at ffff88810aa60700\n     which belongs to the cache kmalloc-64 of size 64\n    The buggy address is located 44 bytes inside of\n     freed 64-byte region [ffff88810aa60700, ffff88810aa60740)\n\n    The buggy address belongs to the physical page:\n        page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0\n    pfn:0x10aa60\n    flags: 0x200000000000000(node\u003d0|zone\u003d2)\n    page_type: f5(slab)\n        raw: 0200000000000000 ffff8881000428c0 dead000000000100\n    dead000000000122\n        raw: 0000000000000000 0000000000200020 00000000f5000000\n    0000000000000000\n    page dumped because: kasan: bad access detected\n\n    Memory state around the buggy address:\n     ffff88810aa60600: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n     ffff88810aa60680: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n    \u003effff88810aa60700: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n                                      ^\n     ffff88810aa60780: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n     ffff88810aa60800: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n    Disabling lock debugging due to kernel taint\n\nFixes: adae20cb2d20 (\"Bluetooth: Convert IRK list to RCU\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "2a3e2287877b1ee40ffb80b7d769b633866533f3",
      "tree": "6a7da15e2a8cfa15f844ae15010786d8b467fac7",
      "parents": [
        "491d2212ea0f0f6a3abbd67729df0c6a3ec9c58a"
      ],
      "author": {
        "name": "Bui Viet Dung",
        "email": "dungvn2345@gmail.com",
        "time": "Thu Oct 08 12:01:40 2026 +0700"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:24 2026 -0400"
      },
      "message": "Bluetooth: hci_debugfs: Pin module for debugfs file operations\n\nAn open debugfs file retains its file_operations pointer in the\ndebugfs proxy state. However, the file_operations defined in\nhci_debugfs.c (use_debug_keys_fops, sc_only_mode_fops,\nssp_debug_mode_fops, force_bredr_smp_fops, force_static_address_fops,\nforce_no_mitm_fops, dut_mode_fops, vendor_diag_fops, and the\nDEFINE_QUIRK_ATTRIBUTE macro) have no .owner set to THIS_MODULE.\n\nAs a result, full_proxy_open_regular() calls fops_get() which succeeds\nwithout taking a reference to the bluetooth module. When a userspace\nprocess opens any of these debugfs files, a subsequent controller removal\nand module unload (rmmod bluetooth) can succeed while the file descriptor\nremains open.\n\nWhen the userspace process subsequently closes the descriptor,\nfull_proxy_release() accesses the already unmapped file_operations\nstructure, triggering a kernel oops in full_proxy_release():\n\n  BUG: unable to handle page fault for address: fffffbfff8056f03\n  #PF: supervisor read access in kernel mode\n  Oops: 0000 [#1] SMP KASAN NOPTI\n  RIP: 0010:full_proxy_release+0x8e/0x140\n  Call Trace:\n   \u003cTASK\u003e\n   __fput+0x39f/0xa60\n   fput_close_sync+0xff/0x200\n   __x64_sys_close+0x8c/0xf0\n   do_syscall_64+0x115/0x6a0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n   \u003c/TASK\u003e\n\nThe issue was discovered via manual code audit of\nnet/bluetooth/hci_debugfs.c and verified on a Linux 7.3-rc6 test VM\nwith CONFIG_BT\u003dm.\n\nSet .owner \u003d THIS_MODULE on all debugfs file_operations tables in\nhci_debugfs.c so that debugfs keeps the module loaded until close has\nfinished.\n\nFixes: 0886aea6acd2 (\"Bluetooth: Expose debug keys usage setting via debugfs\")\nCc: stable@vger.kernel.org\nSigned-off-by: Bui Viet Dung \u003cdungvn2345@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "491d2212ea0f0f6a3abbd67729df0c6a3ec9c58a",
      "tree": "7a0c7b428d9a4ad9df28924bb096ac071a3fb399",
      "parents": [
        "8368f0c2cde48c09ed70644059f24172b0c59f52"
      ],
      "author": {
        "name": "Eric Dumazet",
        "email": "edumazet@kernel.org",
        "time": "Fri Oct 09 10:35:25 2026 +0200"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:24 2026 -0400"
      },
      "message": "Bluetooth: btmtk: fix skb double free on ISO padding failure\n\nbtmtk_isopkt_pad() uses skb_pad(), which frees the skb on failure.\n\nThe error is propagated by alloc_mtk_intr_urb() and\nbtusb_send_frame_mtk() up to hci_send_frame(), which frees\nthe skb a second time:\n\n\terr \u003d hdev-\u003esend(hdev, skb);\n\tif (err \u003c 0) {\n\t\tbt_dev_err(hdev, \"sending frame failed (%d)\", err);\n\t\tkfree_skb(skb);\n\t\treturn err;\n\t}\n\nUse __skb_put_padto(skb, MTK_ISO_THRESHOLD, false) so that the skb\nis left to the caller on error. This also replaces the open-coded\nskb_pad() + __skb_put() sequence.\n\nFixes: ceac1cb0259d (\"Bluetooth: btusb: mediatek: add ISO data transmission functions\")\nSigned-off-by: Eric Dumazet \u003cedumazet@kernel.org\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "8368f0c2cde48c09ed70644059f24172b0c59f52",
      "tree": "a93f055cc5c39751469addb1190c3219dd7ff72c",
      "parents": [
        "ebba800d140b580540ad55f670d943e4a7edaffd"
      ],
      "author": {
        "name": "Bui Viet Dung",
        "email": "dungvn2345@gmail.com",
        "time": "Thu Oct 08 12:11:29 2026 +0700"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:23 2026 -0400"
      },
      "message": "Bluetooth: 6lowpan: Pin module for 6lowpan_control debugfs file\n\nAn open debugfs file retains lowpan_control_fops in the debugfs proxy\nstate. However, lowpan_control_fops has no .owner set to THIS_MODULE.\nAs a result, full_proxy_open_regular() calls fops_get() which succeeds\nwithout taking a reference to the bluetooth_6lowpan module.\n\nWith CONFIG_BT_6LOWPAN\u003dm, a userspace process can keep the debugfs file\ndescriptor for 6lowpan_control open across module unload\n(delete_module / rmmod bluetooth_6lowpan). When the process subsequently\ncloses the file descriptor, full_proxy_release() accesses the already\nfreed and unmapped lowpan_control_fops table, causing a kernel page fault\nor oops.\n\nThe issue was discovered via manual code audit of\nnet/bluetooth/6lowpan.c.\n\nSet .owner \u003d THIS_MODULE on lowpan_control_fops so that debugfs pins\nthe module until all open file descriptors have finished.\n\nFixes: 6b8d4a6a0314 (\"Bluetooth: 6LoWPAN: Use connected oriented channel instead of fixed one\")\nCc: stable@vger.kernel.org\nSigned-off-by: Bui Viet Dung \u003cdungvn2345@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "ebba800d140b580540ad55f670d943e4a7edaffd",
      "tree": "ce453f50eb126b4d2aa09ce9aa153e0243e75f9d",
      "parents": [
        "21895f20fedc4504474bcb1022850b532ea4358e"
      ],
      "author": {
        "name": "Cen Zhang",
        "email": "zzzccc427@gmail.com",
        "time": "Thu Oct 08 12:11:35 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:23 2026 -0400"
      },
      "message": "Bluetooth: 6lowpan: Drain RCU readers on registration failure\n\nA lowpan_btle_dev is embedded in its net_device allocation and must\nremain alive until readers of bt_6lowpan_devices have left their RCU\nsections. setup_netdev() publishes it before registration, but its\nerror path only unlinks it before calling free_netdev().\n\nIf a second controller\u0027s registration fails while multicast is sent\non an existing 6LoWPAN interface, send_mcast_pkt() can already have\nselected the new entry. It reads entry-\u003enetdev before checking which\ninterface owns it. An early failure, such as allocating the device\u0027s\nname node, leaves NETREG_UNINITIALIZED, so free_netdev() releases the\nstorage immediately.\n\nThe following ordering frees the selected entry before the reader\nloads its netdev field:\n\n  Adapter creation (controller B)       Multicast on controller A\n  setup_netdev()\n    list_add_rcu()\n                                       rcu_read_lock()\n                                       select B\u0027s entry\n    lowpan_register_netdev() fails\n    list_del_rcu()\n    free_netdev()\n                                       read entry-\u003enetdev\n                                       rcu_read_unlock()\n\nRemoving the list node does not wait for that reader, and\ndevices_lock does not serialize the multicast reader. The subsequent\nfield load is a use-after-free, reported by KASAN in bt_xmit().\n\nWait for an RCU grace period after dropping devices_lock and before\nfree_netdev(). This keeps the failed adapter allocated until traversals\nthat could have selected it complete. The callback is already sleepable,\nand the wait happens outside the list spinlock.\n\nKASAN report as below:\n\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n    BUG: KASAN: slab-use-after-free in bt_xmit+0x1d06/0x21e0\n    Read of size 8 at addr ffff88810ef45030 by task python3/556\n\n    Call Trace:\n     \u003cTASK\u003e\n     dump_stack_lvl+0x93/0xd0\n     print_report+0xce/0x630\n     ? bt_xmit+0x1d06/0x21e0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __virt_addr_valid+0x20d/0x410\n     ? bt_xmit+0x1d06/0x21e0\n     kasan_report+0xe0/0x110\n     ? bt_xmit+0x1d06/0x21e0\n     bt_xmit+0x1d06/0x21e0\n     ? __pfx_bt_xmit+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lock_acquire+0x17b/0x2f0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lock_is_held_type+0x8f/0x100\n     ? dev_hard_start_xmit+0x187/0x660\n     ? __pfx_bt_xmit+0x10/0x10\n     dev_hard_start_xmit+0x187/0x660\n     sch_direct_xmit+0x153/0x850\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __pfx_sch_direct_xmit+0x10/0x10\n     ? do_raw_spin_lock+0x130/0x270\n     ? __pfx_do_raw_spin_lock+0x10/0x10\n     ? lock_is_held_type+0x8f/0x100\n     __dev_queue_xmit+0x3111/0x3aa0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? look_up_lock_class+0x59/0x130\n     ? register_lock_class+0x41/0x790\n     ? __pfx___dev_queue_xmit+0x10/0x10\n     ? __lock_acquire+0x466/0x2260\n     ? find_held_lock+0x2b/0x80\n     ? ___neigh_create+0x1690/0x2540\n     ? __local_bh_enable_ip+0xa6/0x120\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lockdep_hardirqs_on_prepare+0xea/0x1a0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lock_acquire+0x17b/0x2f0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? find_held_lock+0x2b/0x80\n     ? ip6_finish_output2+0x8be/0x1840\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? neigh_connected_output+0x39f/0x4e0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     neigh_connected_output+0x33f/0x4e0\n     ip6_finish_output2+0x8be/0x1840\n     ip6_finish_output+0x424/0xd50\n     ip6_output+0x210/0x640\n     ? __pfx_ip6_mr_output+0x10/0x10\n     ip6_local_out+0x193/0x1c0\n     ip6_send_skb+0xfb/0x3e0\n     udp_v6_send_skb+0x6e1/0x1180\n     udpv6_sendmsg+0x1f9b/0x2a00\n     ? get_random_u32+0xaf/0x640\n     ? __pfx_udpv6_sendmsg+0x10/0x10\n     ? lock_release+0xc8/0x280\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lockdep_hardirqs_on_prepare+0xea/0x1a0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? trace_hardirqs_on+0x18/0x160\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __local_bh_enable_ip+0xa6/0x120\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __pfx_udpv6_sendmsg+0x10/0x10\n     ? inet6_sendmsg+0xff/0x140\n     inet6_sendmsg+0xff/0x140\n     __sys_sendto+0x320/0x470\n     ? __pfx___sys_sendto+0x10/0x10\n     ? exc_page_fault+0x5c/0xc0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lock_release+0xc8/0x280\n     ? handle_mm_fault+0x12e/0x580\n     __x64_sys_sendto+0xe5/0x1c0\n     ? lockdep_hardirqs_on_prepare+0xea/0x1a0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? trace_hardirqs_on+0x18/0x160\n     do_syscall_64+0x115/0x6a0\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n    Allocated by task 502:\n     kasan_save_stack+0x33/0x60\n     kasan_save_track+0x14/0x30\n     __kasan_kmalloc+0xaa/0xb0\n     __kvmalloc_node_noprof+0x353/0x930\n     alloc_netdev_mqs+0xa0/0x1250\n     chan_ready_cb+0x198/0x1110\n     l2cap_recv_frame+0x6dc0/0x8830\n     l2cap_recv_acldata+0xe9f/0x10e0\n     hci_rx_work+0x5a6/0xf00\n     process_one_work+0x908/0x19c0\n     worker_thread+0x65c/0xe40\n     kthread+0x34f/0x460\n     ret_from_fork+0x659/0x940\n     ret_from_fork_asm+0x1a/0x30\n\n    Freed by task 502:\n     kasan_save_stack+0x33/0x60\n     kasan_save_track+0x14/0x30\n     kasan_save_free_info+0x3b/0x60\n     __kasan_slab_free+0x5f/0x80\n     kfree+0x307/0x580\n     free_netdev+0x6ca/0x8f0\n     chan_ready_cb+0xd91/0x1110\n     l2cap_recv_frame+0x6dc0/0x8830\n     l2cap_recv_acldata+0xe9f/0x10e0\n     hci_rx_work+0x5a6/0xf00\n     process_one_work+0x908/0x19c0\n     worker_thread+0x65c/0xe40\n     kthread+0x34f/0x460\n     ret_from_fork+0x659/0x940\n     ret_from_fork_asm+0x1a/0x30\n\n    The buggy address belongs to the object at ffff88810ef44000\n                                                                which\n                                belongs to the cache kmalloc-8k of size\n                                8192\n    The buggy address is located 4144 bytes inside of\n                                                                freed\n                                8192-byte region [ffff88810ef44000,\n                                ffff88810ef46000)\n\n    The buggy address belongs to the physical page:\n        page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0\n    pfn:0x10ef40\n    head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n    flags: 0x200000000000040(head|node\u003d0|zone\u003d2)\n    page_type: f5(slab)\n        raw: 0200000000000040 ffff888100043180 dead000000000100\n    dead000000000122\n        raw: 0000000000000000 0000000000020002 00000000f5000000\n    0000000000000000\n        head: 0200000000000040 ffff888100043180 dead000000000100\n    dead000000000122\n        head: 0000000000000000 0000000000020002 00000000f5000000\n    0000000000000000\n        head: 0200000000000003 fffffffffffffe01 00000000ffffffff\n    00000000ffffffff\n        head: ffff88810ef41a80 0000000000000000 00000000ffffffff\n    0000000000000000\n    page dumped because: kasan: bad access detected\n\n    Memory state around the buggy address:\n     ffff88810ef44f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ffff88810ef44f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n    \u003effff88810ef45000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                                         ^\n     ffff88810ef45080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ffff88810ef45100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n    Disabling lock debugging due to kernel taint\n\nFixes: 5857d1dbae7d (\"Bluetooth: 6lowpan: Fix possible race\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "21895f20fedc4504474bcb1022850b532ea4358e",
      "tree": "182b1104298c2afe9857cf69fe301e5d22e10c34",
      "parents": [
        "213e7a99bea19e2f29f394321b86c792eec73a24"
      ],
      "author": {
        "name": "Cen Zhang",
        "email": "zzzccc427@gmail.com",
        "time": "Tue Oct 06 22:41:57 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:23 2026 -0400"
      },
      "message": "Bluetooth: msft: Lock failed probe cleanup against feature readers\n\nThe MSFT data must remain allocated while msft_get_features() reads\nits features. read_adv_mon_features() protects that access with\nhdev-\u003elock, but msft_do_open() clears hdev-\u003emsft_data and frees the\nobject without that lock when read_supported_features() fails.\n\nAfter a successful probe, the data survives a normal close. A later\nopen can fail the probe while a management feature request is running.\nhci_mgmt_cmd() permits requests during HCI_INIT, and the opener\u0027s\nhdev-\u003ereq_lock does not serialize the management reader:\n\n  Management feature request            HCI open\n                                        hold hdev-\u003ereq_lock\n                                        msft_do_open()\n  hold hdev-\u003elock\n  msft_get_features(): save msft\n                                        read_supported_features() fails\n                                        hdev-\u003emsft_data \u003d NULL\n                                        kfree(msft)\n  read msft-\u003efeatures\n  release hdev-\u003elock                     release hdev-\u003ereq_lock\n\nThe saved pointer then refers to freed memory, causing a use-after-free\nread. Advertisement reporting through mgmt_device_found() also reads\nthe features with hdev-\u003elock held.\n\nTake hdev-\u003elock around clearing and freeing msft_data in the failure\nbranch. An existing feature reader finishes before the free, while a\nreader starting after cleanup sees NULL. Keep the synchronous probe\noutside this critical section, following the existing req_lock to\nhdev-\u003elock ordering.\n\nKASAN report as below:\n\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n    BUG: KASAN: slab-use-after-free in msft_monitor_supported+0xa9/0xb0\n    Read of size 8 at addr ffff88811573ee00 by task mgmt-read-adv-m/532\n\n        CPU: 2 UID: 0 PID: 532 Comm: mgmt-read-adv-m Not tainted\n    7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy)\n        Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps\n    fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n    Call Trace:\n     \u003cTASK\u003e\n     dump_stack_lvl+0x93/0xd0\n     print_report+0xce/0x630\n     ? msft_monitor_supported+0xa9/0xb0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __virt_addr_valid+0x20d/0x410\n     ? msft_monitor_supported+0xa9/0xb0\n     kasan_report+0xe0/0x110\n     ? msft_monitor_supported+0xa9/0xb0\n     msft_monitor_supported+0xa9/0xb0\n     read_adv_mon_features+0xdf/0x640\n     ? trace_hardirqs_on+0x18/0x160\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __pfx_read_adv_mon_features+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? do_raw_read_unlock+0x49/0xe0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? _raw_read_unlock+0x23/0x40\n     hci_sock_sendmsg+0x12b5/0x2270\n     ? __pfx_hci_sock_sendmsg+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? selinux_socket_sendmsg+0x160/0x280\n     __sys_sendto+0x425/0x470\n     ? __pfx_hci_sock_sendmsg+0x10/0x10\n     ? __pfx___sys_sendto+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __sys_setsockopt+0x119/0x180\n     __x64_sys_sendto+0xe5/0x1c0\n     ? lockdep_hardirqs_on_prepare+0xea/0x1a0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? trace_hardirqs_on+0x18/0x160\n     do_syscall_64+0x115/0x6a0\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n    RIP: 0033:0x7f9ceb04a687\n        Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48\n    83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 \u003c5b\u003e\n    c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff\n    RSP: 002b:00007ffe6ab96a70 EFLAGS: 00000202 ORIG_RAX: 000000000000002c\n    RAX: ffffffffffffffda RBX: 00007f9ceafb8780 RCX: 00007f9ceb04a687\n    RDX: 0000000000000006 RSI: 00007ffe6ab96aea RDI: 0000000000000003\n    RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000\n    R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000003\n    R13: 00007ffe6ab96d50 R14: 00007f9ceb1f6000 R15: 00005625e427dd68\n     \u003c/TASK\u003e\n\n    Allocated by task 506:\n     kasan_save_stack+0x33/0x60\n     kasan_save_track+0x14/0x30\n     __kasan_kmalloc+0xaa/0xb0\n     __kmalloc_cache_noprof+0x251/0x610\n     msft_register+0x54/0x260\n     hci_register_dev+0x6b7/0xc80\n     __vhci_create_device+0x330/0x840\n     vhci_write+0x287/0x440\n     vfs_write+0x637/0x1010\n     ksys_write+0x111/0x200\n     do_syscall_64+0x115/0x6a0\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n    Freed by task 529:\n     kasan_save_stack+0x33/0x60\n     kasan_save_track+0x14/0x30\n     kasan_save_free_info+0x3b/0x60\n     __kasan_slab_free+0x5f/0x80\n     kfree+0x307/0x580\n     msft_do_open+0x604/0x9e0\n     hci_dev_open_sync+0x94a/0x2110\n     hci_dev_do_open+0x2f/0xb0\n     hci_dev_open+0x17d/0x300\n     hci_sock_ioctl+0x3c6/0x710\n     sock_do_ioctl+0x120/0x2b0\n     sock_ioctl+0x41b/0x670\n     __x64_sys_ioctl+0x163/0x1d0\n     do_syscall_64+0x115/0x6a0\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n    The buggy address belongs to the object at ffff88811573ee00\n     which belongs to the cache kmalloc-256 of size 256\n    The buggy address is located 0 bytes inside of\n     freed 256-byte region [ffff88811573ee00, ffff88811573ef00)\n\n    The buggy address belongs to the physical page:\n        page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0\n    pfn:0x11573e\n    head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n    flags: 0x200000000000040(head|node\u003d0|zone\u003d2)\n    page_type: f5(slab)\n        raw: 0200000000000040 ffff888100042b40 dead000000000100\n    dead000000000122\n        raw: 0000000000000000 0000000000100010 00000000f5000000\n    0000000000000000\n        head: 0200000000000040 ffff888100042b40 dead000000000100\n    dead000000000122\n        head: 0000000000000000 0000000000100010 00000000f5000000\n    0000000000000000\n        head: 0200000000000001 ffffffffffffff81 00000000ffffffff\n    00000000ffffffff\n        head: 0000000000000000 0000000000000000 00000000ffffffff\n    0000000000000000\n    page dumped because: kasan: bad access detected\n\n    Memory state around the buggy address:\n     ffff88811573ed00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n     ffff88811573ed80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n    \u003effff88811573ee00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                       ^\n     ffff88811573ee80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ffff88811573ef00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nFixes: 5031ffcc79b8 (\"Bluetooth: Keep MSFT ext info throughout a hci_dev\u0027s life cycle\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "213e7a99bea19e2f29f394321b86c792eec73a24",
      "tree": "12c9c3a8eb58a8d8fa6fb70706a7268905d23877",
      "parents": [
        "b4a00dedc5cc6f6f98c07ec1b54d24a817d9fc88"
      ],
      "author": {
        "name": "Cen Zhang",
        "email": "zzzccc427@gmail.com",
        "time": "Tue Oct 06 15:24:31 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:23 2026 -0400"
      },
      "message": "Bluetooth: MGMT: Reject quality report requests during unregister\n\nA quality report request must not call a driver callback after its\nmodule text has been released. hci_mgmt_cmd() holds an hci_dev reference\nthrough set_exp_feature(), but that reference only preserves the device\nallocation. set_quality_report_func() takes req_lock and invokes\nhdev-\u003eset_quality_report without checking HCI_UNREGISTER.\n\nThis is unsafe when a SET_EXP_FEATURE request for an Intel controller\nwould change HCI_QUALITY_REPORT and is delayed before taking req_lock\nwhile the controller is removed. With btintel_pcie and btintel built as\nmodules and no other btintel dependents, the following order is\npossible:\n\n  Management request                Removal and module unload\n  ------------------                -------------------------\n  hci_mgmt_cmd(): retain hdev\n                                    hci_unregister_dev():\n                                      set HCI_UNREGISTER\n                                      remove hdev from lookup\n                                      close under req_lock\n                                      release req_lock\n                                    btintel_pcie_remove(): return\n                                    unload btintel_pcie, then btintel\n  set_quality_report_func():\n    take req_lock\n    call hdev-\u003eset_quality_report\n\nWhen the request resumes after btintel unload, the indirect call targets\nreleased module text and can cause an instruction-fetch page fault. The\nclose operation serializes with a running callback but does not prevent\na delayed management handler from invoking it afterwards.\n\nCheck HCI_UNREGISTER immediately after acquiring the existing req_lock\nand return MGMT_STATUS_INVALID_INDEX via the common unlock path. If\nunregister passed its close section first, the request now rejects the\nremoved controller before accessing the callback. If the request passes\nthe check first, hci_dev_do_close() must wait for req_lock until the\ncallback has returned, so unregister cannot finish before the use.\n\nOops report as below:\n\n    BUG: unable to handle page fault for address: ffffffffc0408e10\n    #PF: supervisor instruction fetch in kernel mode\n    #PF: error_code(0x0010) - not-present page\n    PGD 80a9067 P4D 80a9067 PUD 80ab067 PMD 0\n    Oops: Oops: 0010 [#1] SMP KASAN NOPTI\n    CPU: 1 UID: 0 PID: 439 Comm: btmgmt Tainted: G           O        7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy)\n    Tainted: [O]\u003dOOT_MODULE\n    Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n    RIP: 0010:0xffffffffc0408e10\n    Code: Unable to access opcode bytes at 0xffffffffc0408de6.\n    RSP: 0018:ffff888110927838 EFLAGS: 00010293\n    RAX: 0000000000000000 RBX: 1ffff11022124f0c RCX: ffffffff85b1a1b6\n    RDX: ffff888117511d00 RSI: 0000000000000001 RDI: ffff888117598000\n    RBP: ffff888110927950 R08: 0000000000000001 R09: 0000000000000001\n    R10: ffffffff893d3057 R11: ffff888117511d00 R12: ffff888117598000\n    R13: 0000000000000001 R14: ffffffffc0408e10 R15: ffff888117599970\n    FS:  00007f15453f2040(0000) GS:ffff8881fd852000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: ffffffffc0408de6 CR3: 000000010b832005 CR4: 0000000000770ef0\n    PKRU: 55555554\n    Call Trace:\n     \u003cTASK\u003e\n     ? set_quality_report_func+0x232/0x660\n     ? __pfx_set_quality_report_func+0x10/0x10\n     ? pmbd_gate_maybe+0x47/0x60\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? pmbd_probe_hit_cookie+0xe7/0x1c0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? pmbd_probe_hit_cookie+0xee/0x1c0\n     set_exp_feature+0xf7/0x260\n     ? set_exp_feature+0xf7/0x260\n     ? hci_sock_sendmsg+0x12b2/0x2400\n     ? __pfx_hci_sock_sendmsg+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? selinux_socket_sendmsg+0x160/0x280\n     ? sock_write_iter+0x4c0/0x550\n     ? __pfx_hci_sock_sendmsg+0x10/0x10\n     ? __pfx_sock_write_iter+0x10/0x10\n     ? __file_has_perm+0x25e/0x420\n     ? __pfx___file_has_perm+0x10/0x10\n     ? do_iter_readv_writev+0x59c/0x860\n     ? __pfx_do_iter_readv_writev+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? security_file_permission+0x26/0x80\n     ? vfs_writev+0x30e/0xc10\n     ? __pfx_vfs_writev+0x10/0x10\n     ? __pfx_do_epoll_wait+0x10/0x10\n     ? __pfx_do_epoll_ctl+0x10/0x10\n     ? do_writev+0x241/0x2f0\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? do_writev+0x241/0x2f0\n     ? __pfx_do_writev+0x10/0x10\n     ? irqentry_exit+0xbe/0x820\n     ? do_syscall_64+0x115/0x6a0\n     ? entry_SYSCALL_64_after_hwframe+0x77/0x7f\n     \u003c/TASK\u003e\n    Modules linked in: [last unloaded: btintel(O)]\n    CR2: ffffffffc0408e10\n    ---[ end trace 0000000000000000 ]---\n    RIP: 0010:0xffffffffc0408e10\n    Code: Unable to access opcode bytes at 0xffffffffc0408de6.\n    RSP: 0018:ffff888110927838 EFLAGS: 00010293\n    RAX: 0000000000000000 RBX: 1ffff11022124f0c RCX: ffffffff85b1a1b6\n    RDX: ffff888117511d00 RSI: 0000000000000001 RDI: ffff888117598000\n    RBP: ffff888110927950 R08: 0000000000000001 R09: 0000000000000001\n    R10: ffffffff893d3057 R11: ffff888117511d00 R12: ffff888117598000\n    R13: 0000000000000001 R14: ffffffffc0408e10 R15: ffff888117599970\n    FS:  00007f15453f2040(0000) GS:ffff8881fd852000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: ffffffffc0408de6 CR3: 000000010b832005 CR4: 0000000000770ef0\n    PKRU: 55555554\n    Kernel panic - not syncing: Fatal exception\n    Kernel Offset: disabled\n    Rebooting in 1 seconds..\n\nFixes: ae7d925b5c04 (\"Bluetooth: Support the quality report events\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "b4a00dedc5cc6f6f98c07ec1b54d24a817d9fc88",
      "tree": "571a419e651994be01945743561d3767bf8c78f4",
      "parents": [
        "6d91353f6dbcc5c4fbb47bbd0c7f885453cfc939"
      ],
      "author": {
        "name": "Cen Zhang",
        "email": "zzzccc427@gmail.com",
        "time": "Tue Oct 06 22:45:53 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:22 2026 -0400"
      },
      "message": "Bluetooth: ISO: Hold the listener during disconnect notification\n\nAn ISO listener must remain alive until a queued child\u0027s disconnect\nnotification completes. bt_accept_enqueue() retains only the child and\nstores a raw parent pointer; iso_conn_ready() drops its temporary\nlistener reference after setup. iso_chan_del() saves that pointer,\nunlinks the child and then calls parent-\u003esk_data_ready() without holding\na listener reference.\n\nWith an incoming CIS child still queued, disconnect and listener release\ncan proceed in this order:\n\n  HCI disconnect                   Listener release\n  iso_conn_del(): lock child\n  iso_chan_del(): save parent\n  bt_accept_unlink(child)\n                                   iso_sock_cleanup_listen():\n                                     drain empty accept queue\n                                   iso_sock_release():\n                                     orphan and kill listener\n                                     final sock_put(listener)\n  parent-\u003esk_data_ready(parent)\n\nAfter unlink, listener cleanup no longer has to take the child socket\nlock. The listener can therefore be freed before iso_chan_del() reads\nsk_data_ready, causing a use-after-free.\n\nTake a temporary parent reference before bt_accept_unlink() and drop it\nafter the notification. The child lock excludes accept dequeue while the\nchild is still queued, so listener cleanup cannot complete before\nsock_hold(). The reference then keeps the listener alive across unlink\nand through the callback without changing lock order.\n\nKASAN report as below:\n\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n    BUG: KASAN: slab-use-after-free in iso_chan_del+0x302/0x320\n    Read of size 8 at addr ffff888105ca2188 by task kworker/2:1/50\n\n        CPU: 2 UID: 0 PID: 50 Comm: kworker/2:1 Not tainted\n    7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy)\n        Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps\n    fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n    Workqueue: events iso_fixture_disconnect_work\n    Call Trace:\n     \u003cTASK\u003e\n     dump_stack_lvl+0x93/0xd0\n     print_report+0xce/0x630\n     ? iso_chan_del+0x302/0x320\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __virt_addr_valid+0x20d/0x410\n     ? iso_chan_del+0x302/0x320\n     kasan_report+0xe0/0x110\n     ? iso_chan_del+0x302/0x320\n     iso_chan_del+0x302/0x320\n     iso_conn_del+0x19d/0x3c0\n     ? __pfx_iso_disconn_cfm+0x10/0x10\n     iso_disconn_cfm+0x78/0x120\n     hci_disconn_complete_evt+0x319/0xa30\n     ? find_held_lock+0x2b/0x80\n     hci_test_iso_disconn_event+0x85/0xb0\n     ? __pfx_hci_test_iso_disconn_event+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? _raw_read_unlock+0x23/0x40\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __hci_dev_get+0x15d/0x280\n     iso_fixture_disconnect_work+0x67/0x290\n     process_one_work+0x908/0x19c0\n     ? __pfx_process_one_work+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lock_is_held_type+0x8f/0x100\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     worker_thread+0x65c/0xe40\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __kthread_parkme+0x175/0x220\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __pfx_worker_thread+0x10/0x10\n     kthread+0x34f/0x460\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __pfx_kthread+0x10/0x10\n     ret_from_fork+0x659/0x940\n     ? __pfx_ret_from_fork+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __switch_to+0x74f/0xf80\n     ? __pfx_kthread+0x10/0x10\n     ret_from_fork_asm+0x1a/0x30\n     \u003c/TASK\u003e\n\n    Allocated by task 521:\n     kasan_save_stack+0x33/0x60\n     kasan_save_track+0x14/0x30\n     __kasan_kmalloc+0xaa/0xb0\n     __kmalloc_noprof+0x2d7/0x770\n     sk_prot_alloc+0x13e/0x260\n     sk_alloc+0x37/0xb40\n     bt_sock_alloc+0x40/0x3b0\n     iso_sock_alloc.constprop.0+0x3a/0x360\n     iso_sock_create+0xc7/0x160\n     bt_sock_create+0x171/0x330\n     __sock_create+0x2c4/0x730\n     __sys_socket+0x141/0x210\n     __x64_sys_socket+0x77/0xc0\n     do_syscall_64+0x115/0x6a0\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n    Freed by task 521:\n     kasan_save_stack+0x33/0x60\n     kasan_save_track+0x14/0x30\n     kasan_save_free_info+0x3b/0x60\n     __kasan_slab_free+0x5f/0x80\n     kfree+0x307/0x580\n     __sk_destruct+0x64f/0x790\n     sk_destruct+0xb3/0xd0\n     __sk_free+0xdd/0x370\n     sk_free+0x51/0x80\n     iso_sock_release+0x46d/0x5b0\n     __sock_release+0xb8/0x270\n     sock_close+0x21/0x30\n     __fput+0x39f/0xa60\n     task_work_run+0x144/0x230\n     do_exit+0x834/0x2830\n     do_group_exit+0xc7/0x280\n     get_signal+0x20a9/0x2400\n     arch_do_signal_or_restart+0x94/0x6f0\n     exit_to_user_mode_loop+0xcf/0x570\n     do_syscall_64+0x4f0/0x6a0\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n    The buggy address belongs to the object at ffff888105ca2000\n                                                                which\n                                belongs to the cache kmalloc-2k of size\n                                2048\n    The buggy address is located 392 bytes inside of\n                                                                freed\n                                2048-byte region [ffff888105ca2000,\n                                ffff888105ca2800)\n\n    The buggy address belongs to the physical page:\n        page: refcount:0 mapcount:0 mapping:0000000000000000\n    index:0xffff888105ca5000 pfn:0x105ca0\n    head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n    flags: 0x200000000000240(workingset|head|node\u003d0|zone\u003d2)\n    page_type: f5(slab)\n        raw: 0200000000000240 ffff888100042f00 ffffea00042cd010\n    ffffea00042c9210\n        raw: ffff888105ca5000 0000000000080005 00000000f5000000\n    0000000000000000\n        head: 0200000000000240 ffff888100042f00 ffffea00042cd010\n    ffffea00042c9210\n        head: ffff888105ca5000 0000000000080005 00000000f5000000\n    0000000000000000\n        head: 0200000000000003 fffffffffffffe01 00000000ffffffff\n    00000000ffffffff\n        head: ffff888105ca1000 0000000000000000 00000000ffffffff\n    0000000000000000\n    page dumped because: kasan: bad access detected\n\n    Memory state around the buggy address:\n     ffff888105ca2080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ffff888105ca2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n    \u003effff888105ca2180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                          ^\n     ffff888105ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ffff888105ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nFixes: f764a6c2c1e4 (\"Bluetooth: ISO: Add broadcast support\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "6d91353f6dbcc5c4fbb47bbd0c7f885453cfc939",
      "tree": "11508e7cdfcfa3d0ccf35879b17c6deec6ad484f",
      "parents": [
        "817cbcab91fe870e5b69c835cbd708242c9f8c8e"
      ],
      "author": {
        "name": "Cen Zhang",
        "email": "zzzccc427@gmail.com",
        "time": "Tue Oct 06 22:39:21 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:22 2026 -0400"
      },
      "message": "Bluetooth: hci_sync: Serialize devcoredump reset during device open\n\nAn ACTIVE devcoredump\u0027s buffer cursors must remain valid from the\npacket handler\u0027s state check through its copy. hci_devcd_rx() holds\nhdev-\u003elock across that interval, and hci_devcd_reset() requires the\nsame lock. However, hci_dev_open_sync() invokes reset without taking\nit.\n\nA registered VHCI controller can collect a dump through its debugfs\ninterface while the controller is down. If a successful open overlaps\nwith handling a nonempty dump packet, reset can run after the receiver\u0027s\nACTIVE check and before its copy:\n\n  hci_devcd_rx()                    hci_dev_open_sync()\n    dequeue nonempty skb\n    hci_dev_lock(hdev)\n    handler observes ACTIVE\n                                     hdev-\u003eopen(hdev) succeeds\n                                     hci_devcd_reset(hdev)\n                                       dump.tail \u003d NULL\n                                       dump.state \u003d IDLE\n    hci_devcd_copy()\n      compare against old dump.end\n      memcpy(NULL, ..., skb-\u003elen)\n    hci_dev_unlock(hdev)\n\nReset leaves dump.end pointing at the old buffer and purges only queued\npackets, so it cannot discard the skb already dequeued by the receiver.\nThe bounds check can pass with a NULL tail, leading to a nonempty copy\nto address zero. KASAN reported a 24-byte NULL write in hci_devcd_rx().\n\nTake hdev-\u003elock around the open-time reset. The receiver then finishes\nits state check and copy using valid cursors before reset, or observes\nIDLE after reset and skips the copy.\n\nKASAN report as below:\n\n    BUG: KASAN: null-ptr-deref in hci_devcd_rx+0x5d5/0x1a80\n    Write of size 24 at addr 0000000000000000 by task kworker/u17:0/496\n\n        CPU: 0 UID: 0 PID: 496 Comm: kworker/u17:0 Not tainted\n    7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy)\n        Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps\n    fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n    Workqueue: hci0 hci_devcd_rx\n    Call Trace:\n     \u003cTASK\u003e\n     dump_stack_lvl+0x93/0xd0\n     kasan_report+0xe0/0x110\n     ? hci_devcd_rx+0x5d5/0x1a80\n     kasan_check_range+0x105/0x1b0\n     __asan_memcpy+0x3c/0x60\n     hci_devcd_rx+0x5d5/0x1a80\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __pfx_hci_devcd_rx+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lock_release+0xc8/0x280\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     process_one_work+0x908/0x19c0\n     ? __pfx_process_one_work+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? lock_is_held_type+0x8f/0x100\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     worker_thread+0x65c/0xe40\n     ? __pfx_worker_thread+0x10/0x10\n     kthread+0x34f/0x460\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __pfx_kthread+0x10/0x10\n     ret_from_fork+0x659/0x940\n     ? __pfx_ret_from_fork+0x10/0x10\n     ? srso_alias_return_thunk+0x5/0xfbef5\n     ? __switch_to+0x74f/0xf80\n     ? __pfx_kthread+0x10/0x10\n     ret_from_fork_asm+0x1a/0x30\n     \u003c/TASK\u003e\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n    Disabling lock debugging due to kernel taint\n\nFixes: 9695ef876fd1 (\"Bluetooth: Add support for hci devcoredump\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "817cbcab91fe870e5b69c835cbd708242c9f8c8e",
      "tree": "41d2a00368c95d10b68d560a5b901e1e3c3cbac7",
      "parents": [
        "f51ee3bb5fbe9c2019c31befe330bddd3aee39c2"
      ],
      "author": {
        "name": "Cen Zhang",
        "email": "zzzccc427@gmail.com",
        "time": "Tue Oct 06 15:38:38 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:22 2026 -0400"
      },
      "message": "Bluetooth: hci_core: Keep RCU protection through LTK filtering\n\nThe LTK selected by hci_find_ltk() must remain allocated while its\nvalue is checked against the blocked-key list. The finder releases RCU\nbefore passing k-\u003eval to hci_is_blocked_key(). The helper\u0027s own RCU\nsection protects the blocked-key list, but the selected LTK may already\nhave been reclaimed before that section starts.\n\nAn LE ATT socket security request can reach smp_ltk_encrypt() without\nholding hdev-\u003elock. With a matching stored LTK and an LTK-type\nblocked-key entry present, a concurrent MGMT_OP_LOAD_LONG_TERM_KEYS can\nremove the selected LTK in the following order:\n\n  Socket security                 Management / RCU reclamation\n  hci_find_ltk()\n    rcu_read_lock()\n    select k\n    rcu_read_unlock()\n                                  load_long_term_keys()\n                                    hci_dev_lock(hdev)\n                                    hci_smp_ltks_clear(hdev)\n                                      list_del_rcu(\u0026k-\u003elist)\n                                      kfree_rcu(k, rcu)\n                                  grace period ends; k is freed\n    hci_is_blocked_key(..., k-\u003eval)\n      memcmp(b-\u003eval, val, ...)\n\nThe final comparison reads freed LTK bytes. Entering a new RCU section\nin hci_is_blocked_key() cannot protect a pointer obtained before the\ncompleted grace period.\n\nKeep the finder\u0027s RCU read-side section active through the blocked-key\ncomparison and the warning that reads k-\u003ebdaddr. Release it before\nreturning on either matched-key path. This delays reclamation until the\nfinder has finished using the selected record, following the existing\nIRK lookup pattern.\n\nKFENCE report as below:\n\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n    BUG: KFENCE: use-after-free read in hci_is_blocked_key+0xdf/0x240\n\n    Use-after-free read at 0x00000000b9ee38e4 (in kfence-#249):\n     hci_is_blocked_key+0xdf/0x240\n     blocked_key_wrapper+0xc5/0x140 [pmbd_ltk_probe]\n     hci_find_ltk+0x1aa/0x3e0\n     smp_ltk_encrypt.isra.0+0xad/0x340\n     smp_conn_security+0x3b8/0x8c0\n     l2cap_sock_setsockopt+0x1c4b/0x2270\n     do_sock_setsockopt+0x1fb/0x430\n     __sys_setsockopt+0x106/0x180\n     __x64_sys_setsockopt+0xc2/0x160\n     do_syscall_64+0x115/0x6a0\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n    kfence-#249: 0x00000000121f2ad9-0x000000005b5bfb3d, size\u003d72, cache\u003dkmalloc-96\n\n    allocated by task 495 on cpu 0 at 36.722380s (2.603973s ago):\n     hci_add_ltk+0x1f5/0x3a0\n     load_long_term_keys+0x6d0/0x860\n     hci_sock_sendmsg+0x128b/0x22e0\n     __sys_sendto+0x425/0x470\n     __x64_sys_sendto+0xe5/0x1c0\n     do_syscall_64+0x115/0x6a0\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n    freed by task 533 on cpu 0 at 36.993097s (2.339769s ago):\n     __rcu_free_sheaf_prepare+0x261/0x2a0\n     rcu_free_sheaf+0x1f/0xe0\n     rcu_core+0x661/0x1d10\n     handle_softirqs+0x201/0x930\n     __irq_exit_rcu+0x110/0x1e0\n     irq_exit_rcu+0xe/0x20\n     sysvec_apic_timer_interrupt+0x6c/0x80\n     asm_sysvec_apic_timer_interrupt+0x1a/0x20\n     srso_alias_return_thunk+0x0/0xfbef5\n     __asan_memcpy+0x23/0x60\n     create_monitor_ctrl_event+0x1a2/0x460\n     mgmt_cmd_complete+0x2da/0x580\n     load_long_term_keys+0x741/0x860\n     hci_sock_sendmsg+0x128b/0x22e0\n     __sys_sendto+0x425/0x470\n     __x64_sys_sendto+0xe5/0x1c0\n     do_syscall_64+0x115/0x6a0\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n    CPU: 1 UID: 0 PID: 495 Comm: python3 Tainted: G           O        7.2.0-rc6-pmb-bt-functional-v1+ #1 PREEMPT(lazy)\n    Tainted: [O]\u003dOOT_MODULE\n    Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n    \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nFixes: 600a87490ff9 (\"Bluetooth: Implementation of MGMT_OP_SET_BLOCKED_KEYS.\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "f51ee3bb5fbe9c2019c31befe330bddd3aee39c2",
      "tree": "9b81c69b9b377f54a186a6a207b7a5b73579adc8",
      "parents": [
        "8c27d7d06e21ba9455ddae4e14f364c57f095cba"
      ],
      "author": {
        "name": "Hitalo Souza",
        "email": "enghitalo@gmail.com",
        "time": "Tue Oct 06 17:21:42 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:22 2026 -0400"
      },
      "message": "Bluetooth: Add missing newline to bt_dev_{err,warn}_ratelimited()\n\nbt_dev_err_ratelimited() and bt_dev_warn_ratelimited() pass the format\nstring to bt_err_ratelimited()/bt_warn_ratelimited() without appending\na newline, unlike bt_dev_err() and bt_dev_warn(), which go through\nBT_ERR()/BT_WARN() and add one. Only 2 of the 22 in-tree callers (both\nin virtio_bt) put the newline in their own format string.\n\nA printk record without a trailing newline is stored with prb_commit()\ninstead of prb_final_commit(), and readers of the log buffer (/dev/kmsg,\nsyslog) do not see it until it is finalized, which only happens when the\nnext record is reserved. These messages therefore stay invisible until\nsome unrelated message is printed, and journald, which timestamps a\nrecord when it reads it, logs them with the time of that later message.\n\nThis was observed with a MediaTek MT7921 controller (USB 04ca:3802):\nwhen an eSCO link is closed, the host still receives a few SCO packets\nfor the handle after Disconnection Complete, so hci_scodata_packet()\nlogs \"SCO packet for unknown connection handle\". Comparing the record\u0027s\nkernel timestamp (_SOURCE_MONOTONIC_TIMESTAMP) with the time journald\nreceived it, over one capture:\n\n  emitted       logged        delay\n  15:36:52.896  15:37:00.214    7.3 s\n  15:37:03.410  15:39:05.574  122.2 s\n  15:39:05.574  15:39:12.506    6.9 s\n  15:39:19.791  15:40:54.109   94.3 s\n  15:41:22.021  15:41:24.647    2.6 s\n\nEach message showed up together with the next kernel message; the 94 s\none looked as if it had been logged in the middle of a later, healthy\neSCO connection.\n\nbt_dev_err_ratelimited() lost its newline in commit 657cc646475b\n(\"Bluetooth: Remove usage of BT_ERR_RATELIMITED macro\"), which replaced\nBT_ERR_RATELIMITED(), the variant that appended \"\\n\", with a direct call\nto bt_err_ratelimited(). bt_dev_warn_ratelimited() never had one.\n\nAppend the newline in both macros, as BT_ERR() and BT_WARN() do, and\ndrop it from the two virtio_bt format strings so that their messages do\nnot gain an empty line.\n\nFixes: 36278a5d4d35 (\"Bluetooth: Adding a bt_dev_warn_ratelimited macro.\")\nFixes: 657cc646475b (\"Bluetooth: Remove usage of BT_ERR_RATELIMITED macro\")\nAssisted-by: Claude:claude-opus-5-5\nSigned-off-by: Hitalo Souza \u003cenghitalo@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "8c27d7d06e21ba9455ddae4e14f364c57f095cba",
      "tree": "f35ee21f9765413c3b98a99ad4c6a46a19a79fb7",
      "parents": [
        "f7f0d0a9eb6e4616c0b3a2a95498b5204c5543c9"
      ],
      "author": {
        "name": "Cen Zhang",
        "email": "zzzccc427@gmail.com",
        "time": "Tue Oct 06 15:35:23 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:21 2026 -0400"
      },
      "message": "Bluetooth: 6LoWPAN: Use RCU-safe device list removal\n\nRCU readers of bt_6lowpan_devices must be able to follow an adapter\u0027s\nforward link until their read-side critical section ends. The entries\nare published with list_add_rcu(), but device_event() removes an entry\non NETDEV_UNREGISTER with list_del(), poisoning that link.\n\nWhen an adapter is being unregistered and 6LoWPAN is enabled, a\n6lowpan_control debugfs write with an existing LE L2CAP connection can\nenter lookup_peer() after unregister\u0027s first synchronize_net(). If the\nconnection has no peer on that adapter, the reader must advance to the\nnext list entry. Neither RTNL nor devices_lock excludes this RCU reader.\n\nThe last peer\u0027s chan_close_cb() schedules delete_netdev(), which reaches\nunregister_netdevice_many_notify() through unregister_dev() and\nlowpan_unregister_netdev(). The following ordering is possible:\n\n  Unregister worker                 Control writer\n  -----------------                 --------------\n  synchronize_net() returns\n                                    lowpan_control_write()\n                                    lookup_peer(): rcu_read_lock()\n                                    reach adapter; no matching peer\n  device_event(): devices_lock\n  list_del(\u0026entry-\u003elist)\n  spin_unlock(\u0026devices_lock)\n                                    follow poisoned next link\n                                    read invalid adapter address\n  post-notifier synchronize_net()\n    waits for the reader\n\nThis invalid pointer access can fault in lookup_peer(). The first grace\nperiod drains existing readers but permits new ones to start, and the\nlater grace period cannot prevent the intervening poisoned-link access.\n\nUse list_del_rcu() under the existing devices_lock to preserve the\nforward link for readers that already reached the adapter. The existing\npost-notifier synchronize_net() waits for those readers before netdevice\nteardown frees the private storage containing lowpan_btle_dev.\n\nKASAN report as below:\n\n    [...]\n    [   45.867526] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000023: 0000 [#1] SMP KASAN NOPTI\n    [   45.869489] KASAN: maybe wild-memory-access in range [0xdead000000000118-0xdead00000000011f]\n    [   45.870981] CPU: 1 UID: 0 PID: 646 Comm: sh Not tainted 7.2.0-rc6-pmb-bt-functional-v1+ #4 PREEMPT(lazy)\n    [   45.872609] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n    [   45.874380] RIP: 0010:lookup_peer+0x1ba/0x320\n    [   45.875067] Code: 48 89 d9 ba 04 00 00 00 4c 89 fe bf a0 06 00 00 e8 2b e8 ad fb e9 56 ff ff ff e8 01 1e c3 fb 49 8d 7f 18 48 89 f8 48 c1 e8 03 \u003c80\u003e 3c 28 00 0f 85 4a 01 00 00 4d 8b 47 18 4c 89 f1 ba 04 00 00 00\n    [   45.878206] RSP: 0018:ffff888114d67b90 EFLAGS: 00010212\n    [   45.879106] RAX: 1bd5a00000000023 RBX: 0000000000000000 RCX: ffffffff85c1d19f\n    [   45.880334] RDX: ffff88810dc35700 RSI: 0000000000000000 RDI: dead000000000118\n    [   45.881455] RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000001\n    [   45.882546] R10: ffffffff893d3057 R11: ffff88810dc35700 R12: ffff88810a690000\n    [   45.883839] R13: ffff888115451038 R14: ffff88810a690000 R15: dead000000000100\n    [   45.885186] FS:  00007fa889bac780(0000) GS:ffff8881fd852000(0000) knlGS:0000000000000000\n    [   45.886539] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    [   45.887527] CR2: 00007ffe304f2f80 CR3: 0000000104f64005 CR4: 0000000000770ef0\n    [   45.888687] PKRU: 55555554\n    [   45.889183] Call Trace:\n    [   45.889666]  \u003cTASK\u003e\n    [   45.890061]  lowpan_control_write+0x445/0x9e0\n    [   45.890854]  ? __pfx_lowpan_control_write+0x10/0x10\n    [   45.891738]  ? srso_alias_return_thunk+0x5/0xfbef5\n    [   45.892603]  ? srso_alias_return_thunk+0x5/0xfbef5\n    [   45.893383]  ? __debugfs_file_get+0x1bd/0x7f0\n    [   45.894057]  ? srso_alias_return_thunk+0x5/0xfbef5\n    [   45.894902]  ? lock_acquire+0x17b/0x2f0\n    [   45.895593]  ? ksys_write+0x111/0x200\n    [   45.896290]  full_proxy_write+0x11f/0x180\n    [   45.896991]  vfs_write+0x25a/0x1010\n    [   45.897642]  ? __pfx_full_proxy_write+0x10/0x10\n    [   45.898440]  ? __pfx_vfs_write+0x10/0x10\n    [   45.899178]  ? lock_release+0x11f/0x280\n    [   45.899855]  ksys_write+0x111/0x200\n    [   45.900435]  ? __pfx_ksys_write+0x10/0x10\n    [   45.901074]  ? irqentry_exit+0xbe/0x820\n    [   45.901722]  ? srso_alias_return_thunk+0x5/0xfbef5\n    [   45.902489]  do_syscall_64+0x115/0x6a0\n    [   45.903064]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n    [   45.903813] RIP: 0033:0x7fa889c3e687\n    [   45.904359] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 \u003c5b\u003e c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff\n    [   45.906981] RSP: 002b:00007ffd7651b960 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\n    [   45.908070] RAX: ffffffffffffffda RBX: 00007fa889bac780 RCX: 00007fa889c3e687\n    [   45.909102] RDX: 000000000000001c RSI: 00005570f25e8d10 RDI: 0000000000000001\n    [   45.910133] RBP: 00005570f25e8d10 R08: 0000000000000000 R09: 0000000000000000\n    [   45.911162] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000001\n    [   45.912190] R13: 000000000000001c R14: 0000000000000000 R15: 00005570f25e8a78\n    [   45.913208]  \u003c/TASK\u003e\n    [   45.913530] Modules linked in:\n    [   45.914022] ---[ end trace 0000000000000000 ]---\n    [   45.914709] RIP: 0010:lookup_peer+0x1ba/0x320\n    [   45.915436] Code: 48 89 d9 ba 04 00 00 00 4c 89 fe bf a0 06 00 00 e8 2b e8 ad fb e9 56 ff ff ff e8 01 1e c3 fb 49 8d 7f 18 48 89 f8 48 c1 e8 03 \u003c80\u003e 3c 28 00 0f 85 4a 01 00 00 4d 8b 47 18 4c 89 f1 ba 04 00 00 00\n    [   45.919191] RSP: 0018:ffff888114d67b90 EFLAGS: 00010212\n    [   45.920046] RAX: 1bd5a00000000023 RBX: 0000000000000000 RCX: ffffffff85c1d19f\n    [   45.921129] RDX: ffff88810dc35700 RSI: 0000000000000000 RDI: dead000000000118\n    [   45.922553] RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000001\n    [   45.923653] R10: ffffffff893d3057 R11: ffff88810dc35700 R12: ffff88810a690000\n    [   45.925119] R13: ffff888115451038 R14: ffff88810a690000 R15: dead000000000100\n    [   45.926180] FS:  00007fa889bac780(0000) GS:ffff8881fd852000(0000) knlGS:0000000000000000\n    [   45.927817] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    [   45.928726] CR2: 00007ffe304f2f80 CR3: 0000000104f64005 CR4: 0000000000770ef0\n    [   45.930069] PKRU: 55555554\n    [   45.930456] Kernel panic - not syncing: Fatal exception\n    [   45.931542] Kernel Offset: disabled\n    [   45.932040] Rebooting in 1 seconds..\n\nFixes: 90305829635d (\"Bluetooth: 6lowpan: Converting rwlocks to use RCU\")\nAssisted-by: LLM\nSigned-off-by: Cen Zhang \u003czzzccc427@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "f7f0d0a9eb6e4616c0b3a2a95498b5204c5543c9",
      "tree": "cbee5e96e0761b48ef2d02a1b970b1b1e817beec",
      "parents": [
        "5548fb51aa3cc24545029a286882d261a8e77d8a"
      ],
      "author": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Mon Oct 05 13:39:26 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:21 2026 -0400"
      },
      "message": "Bluetooth: MGMT: Fix leaking instance on Add Extended Advertising Parameters\n\nIf queueing the command fails the instance is never removed, despite it\nhaving already been added or modified by hci_add_adv_instance, so remove\nit as it is done by add_ext_adv_params_complete on failure, signaling\nit has been removed if it was previously added.\n\nFixes: cba6b758711c (\"Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 2\")\nAssisted-by: OpenCode:claude-opus-5.5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "5548fb51aa3cc24545029a286882d261a8e77d8a",
      "tree": "f9a82f6b794a9a9297ae8d78ad45f52e4dfa58b7",
      "parents": [
        "1bfecdbd031711e5205ae78f3b8c296e5a53bc55"
      ],
      "author": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Mon Oct 05 13:39:25 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:21 2026 -0400"
      },
      "message": "Bluetooth: MGMT: Fix pending state of instances added without HCI traffic\n\nWhen Add Advertising completes without HCI communication, e.g. when the\ndevice is not powered or the instance is overridden by Global\nAdvertising, the instance is left marked as pending, so a subsequent\nfailure in add_adv_complete would remove it despite it having been\nsuccessfully added.\n\nFix this by clearing the pending state before completing the command.\n\nFixes: fffd38bca51c (\"Bluetooth: mgmt/hci_core: multi-adv for add_advertising*()\")\nAssisted-by: OpenCode:claude-opus-5.5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "1bfecdbd031711e5205ae78f3b8c296e5a53bc55",
      "tree": "0737df3b3c300eebf798e2dd77bf4db05baa769d",
      "parents": [
        "0ad48c88a2ed3b58164fa771977868503b0abac3"
      ],
      "author": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Mon Oct 05 13:39:17 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:21 2026 -0400"
      },
      "message": "Bluetooth: HCI: Fix tracking of instances sharing handle 0x00\n\nWhen the controller supports a single advertising set, instance 1 uses\nhandle 0x00 which is the same handle used by instance 0 (Global\nAdvertising), but hci_cc_le_set_ext_adv_enable would lookup the instance\nusing the handle as instance identifier, marking instance 0 as\nenabled/disabled instead of instance 1, leaving its state out of sync.\n\nFix this by matching instances by handle and, for handle 0x00, using\nhdev-\u003ecur_adv_instance, now set when enabling an instance, to determine\nwhich instance owns the set. Also disable the instance sharing the\nadvertising set of instance 0 before overriding it.\n\nFixes: e77f43d531af (\"Bluetooth: hci_core: Fix not handling hdev-\u003ele_num_of_adv_sets\u003d1\")\nAssisted-by: OpenCode:claude-opus-5.5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "0ad48c88a2ed3b58164fa771977868503b0abac3",
      "tree": "9f97b681aaacc2d7b32ed74e1e4883d39354a551",
      "parents": [
        "3d9526b171e0f2b94e478204d232e3ea94296200"
      ],
      "author": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Mon Oct 05 11:15:02 2026 -0400"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:20 2026 -0400"
      },
      "message": "Bluetooth: MGMT: Fix advertising instances with Global Advertising\n\nGlobal Advertising, enabled with MGMT_OP_SET_ADVERTISING, uses instance\n0 and with extended advertising it has its own advertising set, but\ninstances were still being treated as if they shared the same set:\n\n - Add Advertising and Add Extended Advertising Data would return\n   success without ever enabling the instance.\n - Removing the last instance would disable all advertising sets,\n   stopping Global Advertising while leaving its setting enabled.\n - Disabling Global Advertising would disable all sets, including\n   active instances.\n\nFix this by only overriding instances that share the advertising set of\nGlobal Advertising, and by tracking HCI_LE_ADV_0 rather than HCI_LE_ADV\nto determine the state of Global Advertising.\n\nFixes: 0d92808024b4 (\"Bluetooth: HCI: Fix tracking of advertisement set/instance 0x00\")\nAssisted-by: OpenCode:claude-opus-5.5\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "3d9526b171e0f2b94e478204d232e3ea94296200",
      "tree": "11f926beff71425ecf6995c5880e1bd6f400a738",
      "parents": [
        "8a8d51eeedebfa5aaaae7720f2fb2aa1a67b8587"
      ],
      "author": {
        "name": "Pauli Virtanen",
        "email": "pav@iki.fi",
        "time": "Mon Oct 05 21:13:55 2026 +0300"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:20 2026 -0400"
      },
      "message": "Bluetooth: make hdev-\u003eadv_instance_timeout a boolean\n\nMesh uses millisecond time units for advertisements instead of seconds\nas normally. These values go to hdev-\u003eadv_instance_timeout, which then\nhas mixed units.  hdev-\u003eadv_instance_timeout is however only used as a\ntrue/false flag.\n\nMake hdev-\u003eadv_instance_timeout boolean flag, to avoid possible future\nproblems with its mixed-units values.\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": "8a8d51eeedebfa5aaaae7720f2fb2aa1a67b8587",
      "tree": "5bd69853a7bc8f1b1d858c6afb73e73b801410ab",
      "parents": [
        "cfa67a1dbfd9425044f6eef037a114b2d108f436"
      ],
      "author": {
        "name": "Pauli Virtanen",
        "email": "pav@iki.fi",
        "time": "Mon Oct 05 21:13:54 2026 +0300"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:20 2026 -0400"
      },
      "message": "Bluetooth: hci_sync: fix mesh adv timeout units\n\nMesh adv instance timeout and duration are in milliseconds, see\nmesh_send_sync, hci_add_adv_instance.  hci_schedule_adv_instance_sync()\nand hci_enable_ext_advertising_sync() ignore this, and scale the timeout\nwrong.\n\nFix for mesh instances by using msecs_to_jiffies() in\nhci_schedule_adv_instance_sync and fixing the scaling in\nhci_enable_ext_advertising_sync.\n\nFixes BlueZ \"Mesh - Send cancel\" test failures.\n\nFixes: b338d91703fa (\"Bluetooth: Implement support for Mesh\")\nAssisted-by: opencode:qwen3.8-flash-next sashiko\nSigned-off-by: Pauli Virtanen \u003cpav@iki.fi\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "cfa67a1dbfd9425044f6eef037a114b2d108f436",
      "tree": "542f59931c8005eb9da8df59cb2a2cdabf502938",
      "parents": [
        "371d16580886bafdb1203b0818cdeafd153bbf08"
      ],
      "author": {
        "name": "Konstantin Nazarov",
        "email": "qwertyuiopyyy@gmail.com",
        "time": "Thu Oct 01 14:35:13 2026 +0300"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:20 2026 -0400"
      },
      "message": "Bluetooth: btusb: add ASUS 0b05:1825 to QCA Rome quirks\n\nThe Bluetooth controller with USB ID 0b05:1825 found on ASUS\nsystems uses a Qualcomm QCA Rome chipset, but is currently matched\nonly by the generic Bluetooth USB entry.\n\nWithout BTUSB_QCA_ROME, the driver does not load the QCA rampatch and\nNVM firmware. BLE scanning also repeatedly reports:\n\n    Bluetooth: hci0: unexpected event for opcode 0x2005\n\nMark the device as BTUSB_QCA_ROME with wideband speech support, in\nline with the other QCA Rome USB IDs.\n\nSimilar issue but with different device id. After patching bluetooth is\nworking fine, no unexpected events in log.\n\nLink: https://lore.kernel.org/linux-bluetooth/20260928143655.22223-1-qstrydom0@gmail.com\n\nTested-on: Qualcomm Atheros QCA6174 SoC integrated in motherboard\nASUS Z170I PRO GAMING, USB device id: 0b05:1825\n\nSigned-off-by: Konstantin Nazarov \u003cqwertyuiopyyy@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "371d16580886bafdb1203b0818cdeafd153bbf08",
      "tree": "6c85273611485fd47f74c0e8d4cd2300779ac42e",
      "parents": [
        "1b723bd2945df4c75d7a4a4525660704ef8f4df8"
      ],
      "author": {
        "name": "Aaron Kling",
        "email": "webgeek1234@gmail.com",
        "time": "Fri Sep 25 01:52:50 2026 -0500"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:19 2026 -0400"
      },
      "message": "Bluetooth: btbcm: Add entry for BCM4356A3 UART bluetooth\n\nThis patch adds the device ID for the bluetooth chip used in the\nNvidia specific Broadcom BCM4356 PCI-E WiFi / UART BT chip.\n\nStartup log:\n\n  Bluetooth: hci0: BCM: chip id 122\n  Bluetooth: hci0: BCM: features 0x0f\n  Bluetooth: hci0: BCM4356A3\n  Bluetooth: hci0: BCM4356A3 (001.004.009) build 0000\n  Bluetooth: hci0: BCM4356A3 \u0027brcm/BCM4356A3.nvidia,p2894-2551-b00.hcd\u0027 Patch\n  Bluetooth: hci0: BCM: features 0x0f\n  Bluetooth: hci0: BCM4356A3 37.4MHz Class 1.5 Nvidia mDarcy-0108\n  Bluetooth: hci0: BCM4356A3 (001.004.009) build 0109\n\nSigned-off-by: Aaron Kling \u003cwebgeek1234@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "1b723bd2945df4c75d7a4a4525660704ef8f4df8",
      "tree": "3f34552125cff4a8c1e0728737fb773bca971c49",
      "parents": [
        "df5e35f1663abc2702cf9f9e7eba024129ac5df1"
      ],
      "author": {
        "name": "Frédéric Danis",
        "email": "frederic.danis@collabora.com",
        "time": "Thu Oct 01 15:51:08 2026 +0200"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:19 2026 -0400"
      },
      "message": "Bluetooth: MGMT: Add management security level changed event\n\nAdd an event on device security level or encryption type change to\nlet user space know which level is currently in use.\nReset security level to 0 on disconnection so further connections\nwill correctly report security level changes.\n\nThis will be used for BlueZ qualification automation.\n\nAssisted-by: GPT:GPT-5.3-Codex\nAssisted-by: Copilot:claude-sonnet-5\nSigned-off-by: Frédéric Danis \u003cfrederic.danis@collabora.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "df5e35f1663abc2702cf9f9e7eba024129ac5df1",
      "tree": "6efdb653c38319448ad235ea99509ab552509388",
      "parents": [
        "fa96916cfd05ceb1c26af0b2ea73daf5481cad2d"
      ],
      "author": {
        "name": "Junjie Cao",
        "email": "junjie.cao@intel.com",
        "time": "Sun Sep 20 10:02:27 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:19 2026 -0400"
      },
      "message": "Bluetooth: btusb: drop BROKEN_EXT_SCAN quirk for 0bda:a728\n\nCommit 5ead2063611a (\"Bluetooth: btrtl: fix RTL8761B/BU broken LE\nextended scan\") set HCI_QUIRK_BROKEN_EXT_SCAN on every RTL8761B, and\ncommit ca0583c24661 (\"Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN\nquirk to 0bda:a728\") kept it on 0bda:a728 on the assumption that the\nUSB id separates dongles with broken extended scan from those with a\nbroken legacy scan path. It does not. An 0bda:a728 unit (RTL8761BUV,\nfw 0xdfc6d922) on 6.18.51 fails the same way the UB500 and 0bda:8771\ndid: LE Set Scan Enable (0x200c) times out with -110 and btusb resets\nthe device. With the flag removed from the table entry, scanning works\non that unit.\n\nTwo dongles with the same USB id need opposite settings, so the device\ntable cannot key the quirk either. The costs are not symmetric. Without\nthe quirk, the unit it was written for gets -EBUSY on LE Set Extended\nScan Enable (0x2042) while a connection is up. With it, 0x200c times\nout and btusb resets the device on three reported units, two of them in\na re-enumeration loop.\n\nRemove the flag and the table entry. 0bda:a728 matches the generic\nRealtek entry again and runs without the quirk, as before v7.2.\n\nReported-by: Andy Tsvetinskiy \u003candrew.tsvetinskiy@gmail.com\u003e\nCloses: https://lore.kernel.org/all/CAE4bxw+ofDFVx0aTHqCrzns9oP1CRQDm_wzeyHPeMBYOhSpcuA@mail.gmail.com/\nFixes: 5ead2063611a (\"Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan\")\nFixes: ca0583c24661 (\"Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN quirk to 0bda:a728\")\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": "fa96916cfd05ceb1c26af0b2ea73daf5481cad2d",
      "tree": "a88bdfc641e438f16acaadd2547a7fe164dd3f28",
      "parents": [
        "f2cee6e2aa35a6a701ce3f4bedf20273c808361f"
      ],
      "author": {
        "name": "Kiran K",
        "email": "kiran.k@intel.com",
        "time": "Tue Sep 29 12:15:56 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:19 2026 -0400"
      },
      "message": "Bluetooth: btusb: Preserve event and ACL packet ordering\n\nWhen force_poll_sync is enabled, commit 800fe5ec302e (\"Bluetooth:\nbtusb: Add support for queuing during polling interval\") defers ACL\ndelivery to the RX worker. The event path currently wakes that worker\nbefore delivering the event, so queued ACL data can reach HCI first.\n\nDeliver the event before waking the worker. This preserves the intended\nevent-first ordering and the event callback\u0027s return value.\n\nFixes: 800fe5ec302e (\"Bluetooth: btusb: Add support for queuing during polling interval\")\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": "f2cee6e2aa35a6a701ce3f4bedf20273c808361f",
      "tree": "dac5f997b81ad02c324c182df047731e1f3548cc",
      "parents": [
        "4f6ead67b93bcc4ba1fbbf97c7c8bc5a0c45b80b"
      ],
      "author": {
        "name": "Ravindra",
        "email": "ravindra@intel.com",
        "time": "Mon Sep 28 22:40:03 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:18 2026 -0400"
      },
      "message": "Bluetooth: btintel_pcie: clear the GP0 cause with a W1C write\n\nMSIX_HW_INT_CAUSES is a write-one-to-clear register. Using a\nread-modify-write helper writes zero to GP0, leaving the cause uncleared,\nand can acknowledge unrelated pending causes through the read value.\n\nWrite only the GP0 bit directly, matching the interrupt handler\u0027s W1C\nacknowledgment convention.\n\nFixes: 88c6216a52ea (\"Bluetooth: btintel_pcie: Suspend/Resume: Controller doorbell interrupt handling\")\nSigned-off-by: Ravindra \u003cravindra@intel.com\u003e\nTested-by: Sergey Lebedev \u003clsa.uz@pm.me\u003e\nReviewed-by: Sergey Lebedev \u003clsa.uz@pm.me\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "4f6ead67b93bcc4ba1fbbf97c7c8bc5a0c45b80b",
      "tree": "89d7dee3005b753b22ce1ae20d9e9cbac7ca13dd",
      "parents": [
        "2926eb396711f1f843a0aafee6778822f50e9021"
      ],
      "author": {
        "name": "Sergey Lebedev",
        "email": "lsa.uz@pm.me",
        "time": "Mon Sep 28 22:40:02 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:18 2026 -0400"
      },
      "message": "Bluetooth: btintel_pcie: verify and serialize D-state transitions\n\nThe gp0_received flag only reports that the GP0 handler ran. It does not\ncontain proof that the handler completed the requested D-state transition:\na matched case can leave the state unchanged.\n\nRefresh the boot-stage register before treating the transition as\nsuccessful. When the controller is in D0 but the handler did not re-arm the\ninterface, restore the alive context, reset the IA, restart RX, and\ncomplete the mailbox/alive handshake. Propagate RX setup failures to the PM\ncaller. Likewise, when the controller is in D3 but the handler did not\nrecord it, restore the alive context so the next transition dispatches\ncorrectly.\n\nSerialize the alive-context claim between the GP0 handler and the\nset_dxstate() fallback with irq_lock. Only the path that claims the D0\ntransition resets the IA and rearms RX, avoiding concurrent updates to the\nshared ring state.\n\nCo-developed-by: Ravindra \u003cravindra@intel.com\u003e\nSigned-off-by: Ravindra \u003cravindra@intel.com\u003e\nSigned-off-by: Sergey Lebedev \u003clsa.uz@pm.me\u003e\nFixes: 88c6216a52ea (\"Bluetooth: btintel_pcie: Suspend/Resume: Controller doorbell interrupt handling\")\nTested-by: Sergey Lebedev \u003clsa.uz@pm.me\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "2926eb396711f1f843a0aafee6778822f50e9021",
      "tree": "a7975dc2c8258971bc3e6b7e197ef59ef66ecb83",
      "parents": [
        "12997a385f7140c66f733128b76845fd906c270a"
      ],
      "author": {
        "name": "Ravindra",
        "email": "ravindra@intel.com",
        "time": "Mon Sep 28 22:40:01 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:18 2026 -0400"
      },
      "message": "Bluetooth: btintel_pcie: fix PM flow for S0ix, S3 and S4\n\nFix two issues in the PM suspend/resume path:\n\n1. S3 was handled the same as S0ix, keeping the controller on the\n   D3hot-style path. That caused resume instability because S3 can\n   remove power from the controller, unlike s2idle/S0ix. Use\n   pm_suspend_target_state to distinguish them: D3_HOT for S0ix and\n   D3_COLD for S3/S4. Add .restore to force FLR-based firmware recovery\n   after S4 and S3 (PM_SUSPEND_MEM), as power is lost. S0ix resumes via\n   a normal D0 transition.\n\n2. During hibernation, .freeze() puts the controller into the D3cold\n   state without any loss of power, and the flow normally continues to\n   .poweroff(). If hibernation instead fails, .thaw() is called to bring\n   the controller back up, and the old code routed it through\n   btintel_pcie_resume(), which forced FLR-based firmware recovery\n   whenever data-\u003epm_sx_event was PM_EVENT_FREEZE. That check was\n   incorrect: since the controller\u0027s power was never actually removed on\n   this failed-hibernation path, FLR-based recovery is unnecessary. Remove\n   pm_sx_event and route .thaw through a normal D0 transition instead;\n   FLR-based recovery is retained only in .restore, where genuine S4\n   power loss requires it.\n\nTested with:\n  S0ix: sudo sh -c \u0027echo \"+40\" \u003e /sys/class/rtc/rtc0/wakealarm\u0027 \u0026\u0026 \\\n        echo freeze | sudo tee /sys/power/state\n  S3:   sudo rtcwake -m mem  -s 60\n  S4:   sudo rtcwake -m disk -s 60\n\nFixes: e57362f4911b (\"Bluetooth: btintel_pcie: Add support for _suspend() / _resume()\")\nAssisted-by: GitHub-Copilot:GPT5\nSigned-off-by: Ravindra \u003cravindra@intel.com\u003e\nTested-by: Sergey Lebedev \u003clsa.uz@pm.me\u003e\nReviewed-by: Paul Menzel \u003cpmenzel@molgen.mpg.de\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "12997a385f7140c66f733128b76845fd906c270a",
      "tree": "dd30d006a9e9d50a464569d6f13a70a7c1fc818b",
      "parents": [
        "7de1fcfb783b0633684c0eff0c18d6f4e12e8954"
      ],
      "author": {
        "name": "Vladimir V. Kondratyev",
        "email": "vladimirkondratyev2@gmail.com",
        "time": "Mon Sep 28 22:40:00 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:18 2026 -0400"
      },
      "message": "Bluetooth: btintel_pcie: fix stale cache in set_dxstate fallback check\n\nbtintel_pcie returns -16 (EBUSY) during suspend, causing the entire\nsuspend operation to abort on Intel Lunar Lake hardware. The system\nimmediately resumes after every suspend attempt:\n\n  Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entry, retry count 0\n  Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entry, retry count 1\n  Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D2 entry, retry count 2\n  btintel_pcie 0000:00:14.7: PM: pci_pm_suspend(): btintel_pcie_suspend [btintel_pcie] returns -16\n  btintel_pcie 0000:00:14.7: PM: dpm_run_callback(): pci_pm_suspend returns -16\n  btintel_pcie 0000:00:14.7: PM: failed to suspend async: error -16\n  PM: Some devices failed to suspend, or early wake event detected\n\nbtintel_pcie_set_dxstate() falls back to checking the controller state via\nbtintel_pcie_in_d3/d0() when the alive interrupt is missed. However, these\nhelpers read boot_stage_cache, which is only updated by the interrupt\nhandler. As such, if the interrupt was missed, the cache is stale and the\nfallback check always fails, exhausting all retries and returning -EBUSY,\ncausing suspend to abort.\n\nThe fix involves re-reading the hardware register before the fallback state\ncheck, consistent with btintel_pcie_resume().\n\nFixes: 88c6216a52ea (\"Bluetooth: btintel_pcie: Suspend/Resume: Controller doorbell interrupt handling\")\nLink: https://bugzilla.kernel.org/show_bug.cgi?id\u003d221481\nLink: https://lore.kernel.org/linux-bluetooth/20260830151550.44687-1-lsa.uz@pm.me/\nSigned-off-by: Vladimir V. Kondratyev \u003cvladimirkondratyev2@gmail.com\u003e\nTested-by: Sergey Lebedev \u003clsa.uz@pm.me\u003e\nSigned-off-by: Sergey Lebedev \u003clsa.uz@pm.me\u003e\nSigned-off-by: Ravindra \u003cravindra@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "7de1fcfb783b0633684c0eff0c18d6f4e12e8954",
      "tree": "5d8d301d6499fbb7c408f72fc87a47050f2d1cdb",
      "parents": [
        "d54601f21faf1ab5728e98e2102c3f738be0c177"
      ],
      "author": {
        "name": "Catherine L",
        "email": "catherine.l@intel.com",
        "time": "Fri Sep 18 19:19:19 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:17 2026 -0400"
      },
      "message": "Bluetooth: btintel_pcie: Add CNVi ID for Titan Lake (Scorpius Peak2 C0)\n\nDefine BTINTEL_CNVI_SCP2_C0 (0xA11) for the Scorpius Peak2 C0 stepping\nused on Titan Lake platforms and handle it in btintel_pcie_read_hwexp()\nalongside existing Scorpius Peak2 variants.\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": "d54601f21faf1ab5728e98e2102c3f738be0c177",
      "tree": "793a115ae239b21fa73ce4546e06a9926443811d",
      "parents": [
        "88b08675443b0e06df34af6eb1edebb097e3fa1a"
      ],
      "author": {
        "name": "Quentin Strydom",
        "email": "qstrydom0@gmail.com",
        "time": "Mon Sep 28 15:36:55 2026 +0100"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:17 2026 -0400"
      },
      "message": "Bluetooth: btusb: add ASUS 0b05:1868 to QCA Rome quirks\n\nThe Bluetooth controller with USB ID 0b05:1868 found on ASUS\nsystems uses a Qualcomm QCA Rome chipset, but is currently matched\nonly by the generic Bluetooth USB entry.\n\nWithout BTUSB_QCA_ROME, the driver does not load the QCA rampatch and\nNVM firmware. BLE scanning also repeatedly reports:\n\n    Bluetooth: hci0: unexpected event for opcode 0x2005\n\nMark the device as BTUSB_QCA_ROME with wideband speech support, in\nline with the other QCA Rome USB IDs.\n\nWith the quirk applied, btusb loads:\n\n    qca/rampatch_usb_00000302.bin\n    qca/nvm_usb_00000302.bin\n\nand the unexpected LE Set Random Address completion events are no\nlonger observed.\n\nTested-on: ASUS USB 0b05:1868, QCA Rome 0x302\n\nSigned-off-by: Quentin Strydom \u003cqstrydom0@gmail.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "88b08675443b0e06df34af6eb1edebb097e3fa1a",
      "tree": "c266b4a719451eaea29b8f53ab4d490944bbcc24",
      "parents": [
        "677d3d323f9a5d34a792e70d73bd1aff0cd8782c"
      ],
      "author": {
        "name": "Sai Teja Aluvala",
        "email": "aluvala.sai.teja@intel.com",
        "time": "Tue Sep 22 11:48:21 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:17 2026 -0400"
      },
      "message": "Bluetooth: Add support for Intel DRACO\n\nAdd support for the Draco Bluetooth core (hardware variant 0x23,\nCNVi 0xA30) recognizing the new variant in btintel\u0027s version\ninfo TLV parsing, MSFT vendor opcode setup, and combined setup\npath, as well as in btintel_pcie hardware exception handling\nand PCIe setup path.\n\nSigned-off-by: Sai Teja Aluvala \u003caluvala.sai.teja@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "677d3d323f9a5d34a792e70d73bd1aff0cd8782c",
      "tree": "fcd4c9d95aa2cb3d42c82de1eebf36271b4af178",
      "parents": [
        "18b0fd644fbd15b4cee0ff39b7eaa6cf3df415f3"
      ],
      "author": {
        "name": "Sai Teja Aluvala",
        "email": "aluvala.sai.teja@intel.com",
        "time": "Tue Sep 22 11:48:04 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:17 2026 -0400"
      },
      "message": "Bluetooth: btintel_pcie: Add support for Intel Draco\n\nAdd Device_id 2732 for intel Draco\n\nFrom lspci -v -d 8086:2732\n02:00.0 Bluetooth: Intel Corporation Device 2732\n        Subsystem: Intel Corporation Device 0012\n        Flags: bus master, fast devsel, latency 0, IRQ 16\n        Memory at fe000000 (32-bit, non-prefetchable) [size\u003d16K]\n        Capabilities: [c8] Power Management version 3\n        Capabilities: [d0] MSI: Enable- Count\u003d1/1 Maskable- 64bit+\n        Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00\n        Capabilities: [80] MSI-X: Enable+ Count\u003d5 Masked-\n        Kernel driver in use: btintel_pcie\n        Kernel modules: btintel_pcie\n\nSigned-off-by: Sai Teja Aluvala \u003caluvala.sai.teja@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "18b0fd644fbd15b4cee0ff39b7eaa6cf3df415f3",
      "tree": "01d7794844c9118c1e0352e78841429975356c97",
      "parents": [
        "eb2a7f1bc891695fa714e2146f3c7141274eeb15"
      ],
      "author": {
        "name": "Sai Teja Aluvala",
        "email": "aluvala.sai.teja@intel.com",
        "time": "Tue Sep 22 11:47:44 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:16 2026 -0400"
      },
      "message": "Bluetooth: btintel_pcie: Add support for Intel Draco\n\nAdd Device ID for Intel Draco support\n\nFrom lspci -v -d 8086:2731\n\n02: 00.0 Bluetooth: Intel Corporation Device 2731\n        Subsystem: Intel Corporation Device 0012\n        Flags: bus master, fast devsel, latency 0, IRQ 16\n        Memory at fe000000 (32-bit, non-prefetchable) [size\u003d16K]\n        Capabilities: [c8] Power Management version 3\n        Capabilities: [d0] MSI: Enable- Count\u003d1/1 Maskable- 64bit+\n        Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00\n        Capabilities: [80] MSI-X: Enable+ Count\u003d5 Masked-\n        Kernel driver in use: btintel_pcie\n        Kernel modules: btintel_pcie\n\nSigned-off-by: Sai Teja Aluvala \u003caluvala.sai.teja@intel.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "eb2a7f1bc891695fa714e2146f3c7141274eeb15",
      "tree": "fc4c56db217927bfdd7a80f247ae70ffa4e1a7b0",
      "parents": [
        "c4154fc34772134b0dbd14ab0134ba10b90c52cc"
      ],
      "author": {
        "name": "Ravindra",
        "email": "ravindra@intel.com",
        "time": "Mon Sep 21 11:18:30 2026 +0530"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:16 2026 -0400"
      },
      "message": "Bluetooth: btintel: read ROM debug registers on FW download failure\n\nThe bootloader records init sequence progress and debug info in four\ncore debug registers, useful for debugging FW download failures.\n\nAdd btintel_get_rom_debug_info() to issue BTINTEL_GET_ROM_DEBUG_INFO\n(0xfcde) and log these registers, and invoke it from every FW download\nfailure and timeout path: btintel_download_fw() (legacy .sfi flow) and\nbtintel_prepare_fw_download_tlv() (TLV flow), before resetting to the\nbootloader.\n\nTested by corrupting the operational firmware file to force a\ndownload timeout; the driver logged the debug registers on each\nfailure and retry, e.g.:\n\n  Bluetooth: hci0: Firmware loading timeout\n  Bluetooth: Intel get rom debug info: dr0:0x80000001 dr1:0x00000000 dr2:0x00000001 dr3:0x00df0071\n\nSigned-off-by: Ravindra \u003cravindra@intel.com\u003e\nReviewed-by: Paul Menzel \u003cpmenzel@molgen.mpg.de\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "c4154fc34772134b0dbd14ab0134ba10b90c52cc",
      "tree": "1b2daf74249bc3698bedd8a1637dab0c4bc46b3d",
      "parents": [
        "589b80b654588ab19117e45097772e85e45dd1bb"
      ],
      "author": {
        "name": "Peng Fan",
        "email": "peng.fan@nxp.com",
        "time": "Sun Sep 20 10:26:02 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:16 2026 -0400"
      },
      "message": "Bluetooth: use assign_bit() where applicable\n\nConvert open-coded if/else with set_bit/clear_bit the assign_bit API.\n\nDone with Coccinelle semantic patch:\n    // set_bit -\u003e clear_bit \u003d\u003e assign_bit\n\n    @@\n    expression cond, bit, addr;\n    @@\n\n    -if (cond)\n    -        set_bit(bit, addr);\n    -else\n    -        clear_bit(bit, addr);\n    +assign_bit(bit, addr, cond);\n\n    @@\n    expression cond, bit, addr;\n    @@\n\n    -if (cond)\n    -        clear_bit(bit, addr);\n    -else\n    -        set_bit(bit, addr);\n    +assign_bit(bit, addr, !cond);\n\nSigned-off-by: Peng Fan \u003cpeng.fan@nxp.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "589b80b654588ab19117e45097772e85e45dd1bb",
      "tree": "a82101016f7f5d16d2af6f53cce9092ed4f96c1e",
      "parents": [
        "10038da922652aa990ce9d07f04854611172b59d"
      ],
      "author": {
        "name": "Zijun Hu",
        "email": "zijun.hu@oss.qualcomm.com",
        "time": "Tue Sep 15 19:17:17 2026 -0700"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:16 2026 -0400"
      },
      "message": "Bluetooth: btnxpuart: Simplify nxp_recv_acl_pkt() by hci_acl_handle()\n\nSimplify nxp_recv_acl_pkt() by using hci_acl_handle() instead of:\n\n__u16 handle \u003d __le16_to_cpu(hci_acl_hdr(skb)-\u003ehandle);\n... (handle \u0026 0x0FFF) ...\n\nReviewed-by: Neeraj Sanjay Kale \u003cneeraj.sanjaykale@nxp.com\u003e\nSigned-off-by: Zijun Hu \u003czijun.hu@oss.qualcomm.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "10038da922652aa990ce9d07f04854611172b59d",
      "tree": "4a4520152ab1fa0b02752ccfe1498cad5186cdaa",
      "parents": [
        "3669487308f87d1e6550cf6d5613ea171bad1181"
      ],
      "author": {
        "name": "Alex Zhou",
        "email": "alex.zhou@nxp.com",
        "time": "Wed Sep 16 04:07:19 2026 +0200"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:15 2026 -0400"
      },
      "message": "MAINTAINERS: add entry for NXP wireless Bluetooth driver\n\nAdd Song Xue and Alex Zhou as maintainers for the NXP wireless\nBluetooth driver.\n\nSigned-off-by: Alex Zhou \u003calex.zhou@nxp.com\u003e\nAcked-by: Neeraj Sanjay Kale \u003cneeraj.sanjaykale@nxp.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "3669487308f87d1e6550cf6d5613ea171bad1181",
      "tree": "55e3d420e4702fefd57b77c11f2857efce62c0be",
      "parents": [
        "be58267a34ae562a4a6932f68f1487bceb0345d7"
      ],
      "author": {
        "name": "Zijun Hu",
        "email": "zijun.hu@oss.qualcomm.com",
        "time": "Sun Sep 13 19:46:46 2026 -0700"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:15 2026 -0400"
      },
      "message": "Bluetooth: btusb: Add support for Qualcomm multi-subsystem QCC2072\n\nQCC2072 has a Peripheral (PERI) subsystem to support the BT function\nunit, the transport wire is owned by PERI and carries both BT-HCI and\nPERI-HCI frames, as shown below:\n\n                 _______________________________\n       USB I/F\t|\t   internal link\t|\nBTHOST --------\t|---- PERI -------------- BT\t|\n\t\t|_______________________________|\n                (other on-chip subsystems omitted)\n\nPERI has its own command/event/ACL traffic, memdump, and firmware\n(PATCH and NVM), all different from BT\u0027s own, and BTHOST needs to\ninteract with PERI directly.\n\nTo support multi-subsystem controllers, add btusb_qcom.c/.h as a new\ntransport-specific design:\n\n- Multi-subsystem memdump collection.\n- Generic PERI event handling, and sending a PERI frame then\n  syncing an event sequence.\n- Downloading PERI firmware (rampatch and NVM).\n- Recovery on command timeout or hardware error event.\n\nBTW, it also supports BT-only chips.\n\n/sys/kernel/debug/usb/devices:\nT:  Bus\u003d03 Lev\u003d02 Prnt\u003d02 Port\u003d02 Cnt\u003d01 Dev#\u003d  5 Spd\u003d12   MxCh\u003d 0\nD:  Ver\u003d 1.10 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 MxPS\u003d64 #Cfgs\u003d  1\nP:  Vendor\u003d0cf3 ProdID\u003dea00 Rev\u003d 0.01\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\u003d82(I) Atr\u003d02(Bulk) MxPS\u003d  64 Ivl\u003d0ms\nE:  Ad\u003d02(O) 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\u003d83(I) Atr\u003d01(Isoc) MxPS\u003d   0 Ivl\u003d1ms\nE:  Ad\u003d03(O) Atr\u003d01(Isoc) MxPS\u003d   0 Ivl\u003d1ms\nI:  If#\u003d 1 Alt\u003d 1 #EPs\u003d 2 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 Driver\u003dbtusb\nE:  Ad\u003d83(I) Atr\u003d01(Isoc) MxPS\u003d   9 Ivl\u003d1ms\nE:  Ad\u003d03(O) Atr\u003d01(Isoc) MxPS\u003d   9 Ivl\u003d1ms\nI:  If#\u003d 1 Alt\u003d 2 #EPs\u003d 2 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 Driver\u003dbtusb\nE:  Ad\u003d83(I) Atr\u003d01(Isoc) MxPS\u003d  17 Ivl\u003d1ms\nE:  Ad\u003d03(O) Atr\u003d01(Isoc) MxPS\u003d  17 Ivl\u003d1ms\nI:  If#\u003d 1 Alt\u003d 3 #EPs\u003d 2 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 Driver\u003dbtusb\nE:  Ad\u003d83(I) Atr\u003d01(Isoc) MxPS\u003d  25 Ivl\u003d1ms\nE:  Ad\u003d03(O) Atr\u003d01(Isoc) MxPS\u003d  25 Ivl\u003d1ms\nI:  If#\u003d 1 Alt\u003d 4 #EPs\u003d 2 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 Driver\u003dbtusb\nE:  Ad\u003d83(I) Atr\u003d01(Isoc) MxPS\u003d  33 Ivl\u003d1ms\nE:  Ad\u003d03(O) Atr\u003d01(Isoc) MxPS\u003d  33 Ivl\u003d1ms\nI:  If#\u003d 1 Alt\u003d 5 #EPs\u003d 2 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 Driver\u003dbtusb\nE:  Ad\u003d83(I) Atr\u003d01(Isoc) MxPS\u003d  49 Ivl\u003d1ms\nE:  Ad\u003d03(O) Atr\u003d01(Isoc) MxPS\u003d  49 Ivl\u003d1ms\nI:  If#\u003d 1 Alt\u003d 6 #EPs\u003d 2 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 Driver\u003dbtusb\nE:  Ad\u003d83(I) Atr\u003d01(Isoc) MxPS\u003d  63 Ivl\u003d1ms\nE:  Ad\u003d03(O) Atr\u003d01(Isoc) MxPS\u003d  63 Ivl\u003d1ms\nI:  If#\u003d 1 Alt\u003d 7 #EPs\u003d 2 Cls\u003de0(wlcon) Sub\u003d01 Prot\u003d01 Driver\u003dbtusb\nE:  Ad\u003d83(I) Atr\u003d01(Isoc) MxPS\u003d  65 Ivl\u003d1ms\nE:  Ad\u003d03(O) Atr\u003d01(Isoc) MxPS\u003d  65 Ivl\u003d1ms\n\nSigned-off-by: Zijun Hu \u003czijun.hu@oss.qualcomm.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "be58267a34ae562a4a6932f68f1487bceb0345d7",
      "tree": "d653996d680f9af47042dc685570b02771e3a1f7",
      "parents": [
        "366cdec7fec589321248bf3080216d42bf492a19"
      ],
      "author": {
        "name": "Zijun Hu",
        "email": "zijun.hu@oss.qualcomm.com",
        "time": "Sun Sep 13 19:46:45 2026 -0700"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:15 2026 -0400"
      },
      "message": "Bluetooth: btusb: Build the driver from multiple source files\n\nAllow the driver to include vendor USB-transport-specific source files by:\n- renaming btusb.c to btusb_main.c\n- making btusb.o a composite object\n\nUsed by Qualcomm QCC2072 support.\n\nSigned-off-by: Zijun Hu \u003czijun.hu@oss.qualcomm.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "366cdec7fec589321248bf3080216d42bf492a19",
      "tree": "4f22a172d5b46d44dc34bedac3164e38e94d3ee9",
      "parents": [
        "179950cdcb2667a253671ea1001d4cab48e0040a"
      ],
      "author": {
        "name": "Zijun Hu",
        "email": "zijun.hu@oss.qualcomm.com",
        "time": "Sun Sep 13 19:46:44 2026 -0700"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:15 2026 -0400"
      },
      "message": "Bluetooth: Add generic support for vendor packets\n\nThe virtual HCI_VENDOR_PKT (0xff) has been defined but never used by\nthe BT core. Now, there is a requirement to implement it, as follows:\n\nFor Qualcomm multi-subsystem BT chips, the transport wire carries both\nBT-HCI and PERI-HCI packets, where PERI is a subsystem in the chip, take\nthe upcoming QCC2072 as an example:\n\n    Packet type                 BT-HCI indicator   PERI-HCI indicator\n    -----------------------------------------------------------------\n    CMD (Host -\u003e Controller)    0x01               0x31\n    ACL Data (bidirectional)    0x02               0x32\n    EVENT (Controller -\u003e Host)  0x04               0x34\n\nThere are also BT ACL packets with vendor-reserved handles found in\nexisting device drivers, as shown below:\n\n+--------+--------+---------------------------+\n| Vendor | Handle | Purpose                   |\n+--------+--------+---------------------------+\n| QCOM   | 0xEDD  | Firmware coredump         |\n|        | 0xEDC  | Firmware enhanced logging |\n+--------+--------+---------------------------+\n| MTK    | 0xFC6F | Firmware coredump         |\n|        | 0x05FF | Firmware debug logging 1  |\n|        | 0x05FE | Firmware debug logging 2  |\n+--------+--------+---------------------------+\n| NXP    | 0xFFF  | Firmware coredump         |\n+--------+--------+---------------------------+\n\nImplement HCI_VENDOR_PKT to generically support such vendor packets,\nwhich don\u0027t follow BT SIG\u0027s vendor-extension framework:\n\n- Log them in btmon as they appear on the wire.\n- Add hdev-\u003erecv_vendor_pkt() to handle them in hci_rx_work().\n- Add hci_send_vendor_frame() to send them to the device driver.\n- Allow them to flow over HCI_CHANNEL_USER, nested inside HCI_VENDOR_PKT.\n\nAlso solve the same issues that the commit below fixes for\nHCI_EV_VENDOR, which follows BT SIG\u0027s vendor-extension framework:\n\ncommit 0bd606b31d40 (\"Bluetooth: hci_event: Introduce\nhandle_ev_vendor() for HCI_EV_VENDOR\")\n\nSigned-off-by: Zijun Hu \u003czijun.hu@oss.qualcomm.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "179950cdcb2667a253671ea1001d4cab48e0040a",
      "tree": "e1a82f25b5c47ab0cf607960e86b66f2ad522291",
      "parents": [
        "3fe48c863a145738720f37a1309643c84b39b06d"
      ],
      "author": {
        "name": "Zijun Hu",
        "email": "zijun.hu@oss.qualcomm.com",
        "time": "Sun Sep 13 19:46:43 2026 -0700"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:14 2026 -0400"
      },
      "message": "Bluetooth: btusb: Add recv_intr() hook to btusb_data\n\nTo allow a vendor driver to assemble and handle its non-BT frames\nfrom the interrupt endpoint.\n\nUsed by Qualcomm QCC2072 support.\n\nSigned-off-by: Zijun Hu \u003czijun.hu@oss.qualcomm.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "3fe48c863a145738720f37a1309643c84b39b06d",
      "tree": "267fd4ebb377117f036dd2d6c56eb4603005de9b",
      "parents": [
        "13095bb5ce1f3b5d720de252e1410d178cf1155b"
      ],
      "author": {
        "name": "Tzung-Bi Shih",
        "email": "tzungbi@kernel.org",
        "time": "Mon Sep 14 09:46:31 2026 +0000"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:14 2026 -0400"
      },
      "message": "Bluetooth: btmtksdio: Fix spurious ownership error logs\n\nIn btmtksdio_fw_pmctrl(), if an early operation fails (like clearing\nthe mailbox ACK), it jumps to the `out:` label and spuriously prints\n\"Cannot return ownership to device\".\n\nEvaluate the ownership return errors locally to ensure the error log is\nonly printed if the actual ownership transaction fails.\n\nSigned-off-by: Tzung-Bi Shih \u003ctzungbi@kernel.org\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "13095bb5ce1f3b5d720de252e1410d178cf1155b",
      "tree": "6a480d8b949600a861de6f5bb3f7d0f2def46498",
      "parents": [
        "51589ddae31137711c985f2b02c917c760ab5a81"
      ],
      "author": {
        "name": "Chris Lu",
        "email": "chris.lu@mediatek.com",
        "time": "Mon Sep 14 14:56:52 2026 +0800"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:14 2026 -0400"
      },
      "message": "Bluetooth: btmtk: Route firmware debug event to the diag channel\n\nMediaTek controllers may emit a firmware debug event on the ACL channel\nusing the reserved handle 0x0efd, which shows up in the ACL header as\n0x2efd once the start fragment flag is included.\n\nNeither btmtk_usb_recv_acl() nor btmtksdio_recv_acl() recognizes it, so\nthe packet is passed to the HCI core, which has no connection with that\nhandle and complains:\n\n  Bluetooth: hci0: ACL packet for unknown connection handle 3837\n\nHandle it the same way as the existing firmware debug logging packets and\nforward it to the diagnostic channel instead.\n\nConfirmed with MTK internally that this event\u0027s wire format is fixed:\nfirmware always sends it as a single ACL_START packet and never splits\nit into a continuation (ACL_CONT, which would show up as 0x1efd). Add a\ncomment above the switch spelling that out for this and the other\nvendor-reserved handles already handled here (0xfc6f, 0x05ff, 0x05fe),\nso review tooling doesn\u0027t keep flagging the apparent lack of a matching\ncontinuation case.\n\nVerified on MT7922: under the condition that triggers this firmware\ndebug event, it is now routed to the diag channel instead of reaching\nthe host as an unknown ACL packet.\n\nSigned-off-by: Chris Lu \u003cchris.lu@mediatek.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "51589ddae31137711c985f2b02c917c760ab5a81",
      "tree": "794fa281077d012603d9894d41c1050a71d02ab4",
      "parents": [
        "9822887f0db04ef169a1428892b63139ccf953e8"
      ],
      "author": {
        "name": "Zijun Hu",
        "email": "zijun.hu@oss.qualcomm.com",
        "time": "Sun Sep 13 20:42:59 2026 -0700"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:14 2026 -0400"
      },
      "message": "Bluetooth: hci_event: Use 252 as max CC event payload length in hci_cc_table[]\n\nhci_cc_func() validates skb-\u003elen against cc-\u003emax_len from the entry in\nhci_cc_table[], But By then, the HCI event and CC headers have already been\nstripped by skb_pull(). So the max CC payload is 252, but hci_cc_table[]\nstill uses HCI_MAX_EVENT_SIZE (260) for it, which is imprecise.\n\nFix by defining HCI_MAX_CC_PLEN (252) and using it instead.\n\nSigned-off-by: Zijun Hu \u003czijun.hu@oss.qualcomm.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "9822887f0db04ef169a1428892b63139ccf953e8",
      "tree": "b7643367df90c8f73874c490815dc647be934ebc",
      "parents": [
        "c930a69fecb98fc058ad4d57f2d9bf2e11f318f3"
      ],
      "author": {
        "name": "Zijun Hu",
        "email": "zijun.hu@oss.qualcomm.com",
        "time": "Sun Sep 13 20:42:58 2026 -0700"
      },
      "committer": {
        "name": "Luiz Augusto von Dentz",
        "email": "luiz.von.dentz@intel.com",
        "time": "Wed Oct 14 14:38:13 2026 -0400"
      },
      "message": "Bluetooth: hci_event: Use 254 as max LE Meta subevent payload length in hci_le_ev_table[]\n\nhci_le_meta_evt() validates skb-\u003elen against subev-\u003emax_len from the entry\nin hci_le_ev_table[], By then, the HCI event header and LE Meta subevent\nheader have already been stripped by skb_pull(), So the max LE Meta\nsubevent payload is 254, but hci_le_ev_table[] still uses\nHCI_MAX_EVENT_SIZE (260) for it, which is imprecise.\n\nFix by defining HCI_MAX_LE_SUBEVT_PLEN (254) and using it instead.\n\nSigned-off-by: Zijun Hu \u003czijun.hu@oss.qualcomm.com\u003e\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "c930a69fecb98fc058ad4d57f2d9bf2e11f318f3",
      "tree": "828d81582ae0a9448309837c295c10b41de8e446",
      "parents": [
        "00b201656db41c9eeeed5ca92a4efb6d729ae58e"
      ],
      "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": "Wed Oct 14 14:38:13 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\nSigned-off-by: Luiz Augusto von Dentz \u003cluiz.von.dentz@intel.com\u003e\n"
    },
    {
      "commit": "00b201656db41c9eeeed5ca92a4efb6d729ae58e",
      "tree": "e604495213fedb0865919a26bcdb501e1ed9d211",
      "parents": [
        "8be5ec1f66df125af8b968a176c65344e3844a5f"
      ],
      "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": "Wed Oct 14 14:38:13 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": "8be5ec1f66df125af8b968a176c65344e3844a5f",
      "tree": "2f838e95ed2f01ff6d61b361a5a68cc071e6b4c2",
      "parents": [
        "046fa20e9c7abbafb166b431fe446c49b71cb15a"
      ],
      "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 Oct 14 14:38:13 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": "046fa20e9c7abbafb166b431fe446c49b71cb15a",
      "tree": "ec4eede2b4f1ba4c38a73d7beef095978ef3c9a4",
      "parents": [
        "760ac9d02dce001f2e20c17deb18e7bb63d8355e"
      ],
      "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 Oct 14 14:38:12 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": "760ac9d02dce001f2e20c17deb18e7bb63d8355e",
      "tree": "5afae90f6d7bd130140fc2f367cae5fc3ffee8c8",
      "parents": [
        "9cc144d95eb746a6853cc5a463fc53d1e604d4a4"
      ],
      "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 Oct 14 14:38:12 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": "9cc144d95eb746a6853cc5a463fc53d1e604d4a4",
      "tree": "b401d97e48514c5dc182481ead3a89051ca9c659",
      "parents": [
        "3889a5fcd091d2154861c19e9c581f9f04aabd0e"
      ],
      "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 Oct 14 14:38:12 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": "3889a5fcd091d2154861c19e9c581f9f04aabd0e",
      "tree": "2507b4112beabb13ea38d25abdcd0f46ad7def17",
      "parents": [
        "cbfada3f0c5de233af6bff5a7dbbd05aaefca962"
      ],
      "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 Oct 14 14:38:12 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": "cbfada3f0c5de233af6bff5a7dbbd05aaefca962",
      "tree": "bd3e1d0391223ba60b8b6951e45a04ba82a7394a",
      "parents": [
        "479b0776f7802dca9e036d8944ad29d02dc695c0"
      ],
      "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": "Wed Oct 14 14:38:11 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": "479b0776f7802dca9e036d8944ad29d02dc695c0",
      "tree": "8308518d3751d8a29bf9bd70e57b9596a1fd5d75",
      "parents": [
        "09cf09f752ddd2fecad2aff0d053d90872d55adb"
      ],
      "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": "Wed Oct 14 14:38:11 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: 9ea41cd5a639 (\"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": "09cf09f752ddd2fecad2aff0d053d90872d55adb",
      "tree": "5bb798bd38f9d5e0578470a442a25589d9ebf218",
      "parents": [
        "c84f9fc657986a65f64124a986a5d3a177c44f0c"
      ],
      "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": "Wed Oct 14 14:38:11 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": "c84f9fc657986a65f64124a986a5d3a177c44f0c",
      "tree": "9fcfc44d71141fcbba7e7a9db3543a16e2812500",
      "parents": [
        "266e44d71b41b980ce00b7eda91c6f8c75b1fb15"
      ],
      "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": "Wed Oct 14 14:38:11 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": "266e44d71b41b980ce00b7eda91c6f8c75b1fb15",
      "tree": "d84585f4406b33e288b961b347be6dae4dd3e510",
      "parents": [
        "1430308fc9d47a801a305700cd444b1a0051d14a"
      ],
      "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": "Wed Oct 14 14:38:11 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": "1430308fc9d47a801a305700cd444b1a0051d14a",
      "tree": "80f4d5db39d7f9aa5d0ea0fc3f390854c29829e2",
      "parents": [
        "9ea41cd5a6397544620c185d52d23ec556e37d02"
      ],
      "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": "Wed Oct 14 14:38:10 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": "9ea41cd5a6397544620c185d52d23ec556e37d02",
      "tree": "4eeb68d31079bb30ef7f75826fa8719fd9235d15",
      "parents": [
        "5530f514d9e4141e3105a9efd4279202d533ebb5"
      ],
      "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": "Wed Oct 14 13:31:58 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": "5530f514d9e4141e3105a9efd4279202d533ebb5",
      "tree": "75b1c6064fba9a67aa972451411c47d3a924fa42",
      "parents": [
        "937363063afde2dce1f45d8f22514db99b9eba6b"
      ],
      "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": "Wed Oct 14 13:31:39 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": "937363063afde2dce1f45d8f22514db99b9eba6b",
      "tree": "cca502bccc738bf07b076783a4b481df8454397e",
      "parents": [
        "c5b9532d041b0de8e1b6006d21af977e33e7023a"
      ],
      "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": "Wed Oct 14 13:31:20 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": "c5b9532d041b0de8e1b6006d21af977e33e7023a",
      "tree": "7445b38ca6901e11aebf9ed046b1581593adf999",
      "parents": [
        "4f532f7276269627cc8f2288e2dd351a07367598"
      ],
      "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": "Wed Oct 14 13:31:01 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": "4f532f7276269627cc8f2288e2dd351a07367598",
      "tree": "4ad09a4c99ab11685a7a5d29b669eaa43e661dc1",
      "parents": [
        "69bf0c2b348ff9da580cba5b6a15d0c125a449f3"
      ],
      "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": "Wed Oct 14 13:30:44 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": "69bf0c2b348ff9da580cba5b6a15d0c125a449f3",
      "tree": "f1559c054afd272f53fd61bdca799c49ecb72a02",
      "parents": [
        "7adde1e5216e984480a7e29f00028951fd7f3dc1"
      ],
      "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": "Wed Oct 14 13:30:25 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": "7adde1e5216e984480a7e29f00028951fd7f3dc1",
      "tree": "0adbd878067fda34a19bf5bd9d6d42fa7786a868",
      "parents": [
        "c2163c83e76b988746b0145b954b58e7f7187e3f"
      ],
      "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": "Wed Oct 14 13:30:05 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": "c2163c83e76b988746b0145b954b58e7f7187e3f",
      "tree": "b6bcfbf63bb8a9fe4ec201d1ddb2661ebb815357",
      "parents": [
        "5299db91df03894253e8fa08627cfb9ec1429e89"
      ],
      "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 Oct 14 13:29:46 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": "5299db91df03894253e8fa08627cfb9ec1429e89",
      "tree": "e4a35236af27866aac8908534e07e2c9a240f736",
      "parents": [
        "86b55991d3cd690e73c5ef8d20b75ae4905b357a"
      ],
      "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 Oct 14 13:29:26 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": "86b55991d3cd690e73c5ef8d20b75ae4905b357a",
      "tree": "136bb58c260c6e466967b35ec27cc53635fee91f",
      "parents": [
        "a0c672c4105545f430db3b6379858c8c0ec34f2e"
      ],
      "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 Oct 14 13:29:05 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"
    }
  ],
  "next": "a0c672c4105545f430db3b6379858c8c0ec34f2e"
}