[Bug 2165873] Re: Bluetooth fails to initialize due to a kernel NULL pointer error

I can confirm the bug affects a CyberPower Z890 Ultra 9 with ASUSTeK Z890 MAX GAMING WIFI7 motherboard and, of course, a MEDIATEK bluetooth device. Bluetooth does not work on 6.8.0-139-generic, but it does work on 6.8.0-138-generic -- the *previous* kernel (and several still earlier kernels). I recently upgraded my ASUS BIOS to version 3212. The problem persists (as does my 'hibernate will not resume' problem) in 139. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2165873 Title: Bluetooth fails to initialize due to a kernel NULL pointer error Status in linux package in Ubuntu: Confirmed Status in linux-hwe-6.8 package in Ubuntu: Confirmed Status in linux source package in Noble: In Progress Status in linux-hwe-6.8 source package in Noble: In Progress Bug description: SRU Justification [Impact] Bluetooth fails to start on HP systems with a MediaTek MT7922 controller (CID: 202401-33402) running 6.8.0-139.139~22.04.1. The kernel oopses during Bluetooth power-on. The worker thread dies, so hci0 stays in DOWN INIT and its BD address is all zeros. Bluetooth is unusable. rfkill unblock and hciconfig do not help. Error log: Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20231120183620 BUG: kernel NULL pointer dereference, address: 0000000000000219 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 PID: 340 Comm: kworker/u33:1 Not tainted 6.8.0-139-generic Workqueue: hci0 hci_power_on [bluetooth] RIP: 0010:__pm_runtime_resume+0x1b/0x80 Call Trace: <TASK> usb_autopm_get_interface+0x1d/0x60 btmtk_usb_hci_wmt_sync+0xb9/0x340 [btmtk] btmtk_setup_firmware_79xx+0x1c7/0x360 [btmtk] btusb_mtk_setup+0x2d6/0x610 [btusb] hci_dev_setup_sync+0x6c/0x440 [bluetooth] hci_dev_init_sync+0x3e/0x1c0 [bluetooth] hci_dev_open_sync+0x8b/0x350 [bluetooth] hci_dev_do_open+0x28/0x70 [bluetooth] hci_power_on+0x50/0x210 [bluetooth] Hits 3 out of 3 boots. 6.8.0-138.138~22.04.1 is fine. This breaks these checkbox tests: com.canonical.certification::bluetooth/detect-output com.canonical.certification::bluetooth4/beacon_eddystone_url_hc0 This is not limited to the reporting machine. Any MediaTek MT766x or MT79xx USB Bluetooth controller takes the same path and hits the same oops on 6.8.0-139. [Fix] 6.8.0-139 picked up d019930b0049 ("Bluetooth: btmtk: move btusb_mtk_hci_wmt_sync to btmtk.c", v6.11) as a stable dependency of the urb->setup_packet leak fix. That commit moves the WMT command path into btmtk.c, where it reads intf, udev and ctrl_anchor out of struct btmtk_data. The commit that fills those three fields in is the next one in the same upstream series, and it was not picked: 5c5e8c52e3ca Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c (v6.11) So the pointers stay NULL. The first WMT command calls usb_autopm_get_interface(NULL) and oopses. The fix is to backport 5c5e8c52e3ca so the series is complete again. It adds the missing assignments in btusb_mtk_setup(): btmtk_data->drv_name = btusb_driver.name; btmtk_data->intf = data->intf; btmtk_data->udev = data->udev; btmtk_data->ctrl_anchor = &data->ctrl_anchor; btmtk_data->reset_sync = btusb_mtk_reset; udev and ctrl_anchor are just as NULL as intf, and are used by the WMT receive URB, so all of them are needed. A NULL check on intf alone would only move the oops. [Test Plan] On a machine with a MediaTek MT7922 Bluetooth controller. Boot the machine, then check for the oops: $ dmesg | grep -A20 'NULL pointer' $ journalctl -b -0 -k | grep btmtk Check the controller came up: $ sudo rfkill unblock bluetooth $ hciconfig -a $ hcitool dev Without patch: dmesg shows the NULL pointer oops in __pm_runtime_resume with btmtk_usb_hci_wmt_sync in the call trace. hciconfig shows hci0 DOWN INIT with BD Address 00:00:00:00:00:00. hcitool dev lists no device. With patch: no oops in dmesg. hciconfig shows hci0 UP RUNNING with a real BD address. hcitool dev lists hci0. Then run the two failing tests: $ checkbox-cli run com.canonical.certification::bluetooth/detect-output $ checkbox-cli run com.canonical.certification::bluetooth4/beacon_eddystone_url_hc0 Both pass with the patch, both fail without it. [Where problems could occur] Could break the btusb and btmtk drivers for all MediaTek Bluetooth controllers. This is not a small patch. It moves btusb_mtk_setup() and btusb_mtk_shutdown() and their helpers out of btusb.c into btmtk.c, so the whole MediaTek setup path is touched. If the move dropped or changed something, MediaTek Bluetooth would fail to set up. That would show up as "Failed to set up firmware" or "Failed to send wmt func ctrl" in dmesg, or as a timeout during hci0 power-on, and Bluetooth would stay down. The device reset path also moves (btusb_mtk_subsys_reset becomes btmtk_usb_subsys_reset). If that is wrong, chip recovery after a firmware crash would fail and the controller would need a reboot to come back. Nothing outside drivers/bluetooth is touched. Other Bluetooth vendors (Intel, Realtek, Qualcomm, Broadcom) are not affected, because btusb only calls this code for MediaTek devices. [Other Info] The patch is upstream in v6.11. It is the second half of a two-commit series; the first half is already in 6.8.0-139, which is what caused the regression. The backport needed manual conflict resolution in drivers/bluetooth/btusb.c. 6.8 is missing the intermediate commits that added fw_flavor handling and the BTMTK_FIRMWARE_LOADED flag, so the old copies of btusb_mtk_func_query(), btusb_mtk_uhw_reg_*(), btusb_mtk_reg_read(), btusb_mtk_id_get(), btusb_mtk_reset_done(), btusb_mtk_subsys_reset() and the open-coded btusb_mtk_setup() body all conflicted. Those are exactly the functions this commit deletes, so the upstream side was taken. The resulting btusb_mtk_setup() is identical to upstream at 5c5e8c52e3ca. =========================== The Bluetooth controller fails to initialize on kernel 6.8.0-139.139~22.04.1. During hci_power_on, the MediaTek btmtk driver hits a kernel NULL pointer dereference, the handling kworker dies with IRQs disabled, and hci0 is left stuck in DOWN INIT with an all-zero BD address. The previous kernel 6.8.0-138.138~22.04.1 is unaffected, with identical linux-firmware(20220329.git681281e4-0ubuntu3.42) and bluez(5.64-0ubuntu1.4), this seems to be a kernel regression. This failure affects the following checkbox tests: - com.canonical.certification::bluetooth/detect-output - com.canonical.certification::bluetooth4/beacon_eddystone_url_hc0 Machines: - https://certification.canonical.com/hardware/202401-33402/ Steps to reproduce: 1. Boot the machine with kernel 6.8.0-139.139~22.04.1. 2. Checkbox dmesg for crash, null pointer appears in btmtk_usb_hci_wmt_sync during hci power on. 3. run `sudo rfkill unblock bluetooth; hciconfig -a; hcitool dev` to check the controller state. 4. reboot into 6.8.0-138.138~22.04.1 and repeat steps 2-3. Fail rate: 3/3 on 6.8.0.139 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: linux-image-6.8.0-139-generic 6.8.0-139.139~22.04.1 ProcVersionSignature: Ubuntu 6.8.0-139.139~22.04.1-generic 6.8.12 Uname: Linux 6.8.0-139-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.10 Architecture: amd64 AudioDevicesInUse:  USER PID ACCESS COMMAND  /dev/snd/controlC1: ubuntu 1307 F.... pulseaudio  /dev/snd/controlC0: ubuntu 1307 F.... pulseaudio CasperMD5CheckMismatches: ./preseed/project.cfg CasperMD5CheckResult: fail Date: Mon Aug 31 13:19:26 2026 DistributionChannelDescriptor:  # This is the distribution channel descriptor for the OEM CDs  # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor  canonical-oem-stella-jammy-amd64-20240408-800 InstallationDate: Installed on 2026-08-28 (3 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - pc-stella-jammy-amd64-20240408-800 MachineType: HP HP ZBook Power 16 inch G11 A Mobile Workstation PC ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-139-generic root=UUID=6006e56e-4c1e-49e1-8a56-4c55eea6d70d ro automatic-oem-config quiet splash vt.handoff=7 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions:  linux-restricted-modules-6.8.0-139-generic N/A  linux-backports-modules-6.8.0-139-generic N/A  linux-firmware 20220329.git681281e4-0ubuntu3.42 SourcePackage: linux-hwe-6.8 UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/21/2024 dmi.bios.release: 1.1 dmi.bios.vendor: HP dmi.bios.version: W85 Ver. 01.01.01 dmi.board.name: 8C95 dmi.board.vendor: HP dmi.board.version: KBC Version 08.40.00 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.ec.firmware.release: 8.64 dmi.modalias: dmi:bvnHP:bvrW85Ver.01.01.01:bd03/21/2024:br1.1:efr8.64:svnHP:pnHPZBookPower16inchG11AMobileWorkstationPC:pvrSBKPF:rvnHP:rn8C95:rvrKBCVersion08.40.00:cvnHP:ct10:cvr:skuXW8SKU3#ABA: dmi.product.family: 103C_5336AN HP ZBook dmi.product.name: HP ZBook Power 16 inch G11 A Mobile Workstation PC dmi.product.sku: XW8SKU3#ABA dmi.product.version: SBKPF dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2165873/+subscriptions