CVE-2025-37918

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: avoid NULL pointer dereference in skb_dequeue()<br /> <br /> A NULL pointer dereference can occur in skb_dequeue() when processing a<br /> QCA firmware crash dump on WCN7851 (0489:e0f3).<br /> <br /> [ 93.672166] Bluetooth: hci0: ACL memdump size(589824)<br /> <br /> [ 93.672475] BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> [ 93.672517] Workqueue: hci0 hci_devcd_rx [bluetooth]<br /> [ 93.672598] RIP: 0010:skb_dequeue+0x50/0x80<br /> <br /> The issue stems from handle_dump_pkt_qca() returning 0 even when a dump<br /> packet is successfully processed. This is because it incorrectly<br /> forwards the return value of hci_devcd_init() (which returns 0 on<br /> success). As a result, the caller (btusb_recv_acl_qca() or<br /> btusb_recv_evt_qca()) assumes the packet was not handled and passes it<br /> to hci_recv_frame(), leading to premature kfree() of the skb.<br /> <br /> Later, hci_devcd_rx() attempts to dequeue the same skb from the dump<br /> queue, resulting in a NULL pointer dereference.<br /> <br /> Fix this by:<br /> 1. Making handle_dump_pkt_qca() return 0 on success and negative errno<br /> on failure, consistent with kernel conventions.<br /> 2. Splitting dump packet detection into separate functions for ACL<br /> and event packets for better structure and readability.<br /> <br /> This ensures dump packets are properly identified and consumed, avoiding<br /> double handling and preventing NULL pointer access.