CVE-2025-68304

Vulnérabilité élevée dans Linux (Linux)

CVSS 8.8 · Élevée
EPSS 0.2%
Linux•Linux•Versions : 4d3ca4a9aaf0aa798a6be372dc0fc3a29e37dd57, 6.6, 6.17.11, <=*, <=6.17.*, <6.6, 6.18, 5af1f84ed13a416297ab9ced7537f4d5ae7f329a, 6.5.3, cd55c13bbb3d093ae601aa97e588ed4c1390ebb1, <6.2, 80265dd1d944c3f33e52375b5dbe654980bd2688, <6.5, 0, 6.4.16, <ec74cdf77310c43b01b83ee898a9bd4b4b0b8e93, 6.1.149, <79a2d4678ba90bdba577dc3af88cc900d6dcd5ee

Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: lookup hci_conn on RX path on protocol side The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b ("Bluetooth: convert conn hash to RCU") and not clear if it had purpose since then. Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync") introduced some of these, and there probably were a few others before it. It's better to do the locking so that even if these run concurrently no UAF is possible. Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup. syzkaller has reported a crash that appears to be this issue: [Task hdev->workqueue] [Task 2] hci_disconnect_all_sync l2cap_recv_acldata(hcon) hci_conn_get(hcon) hci_abort_conn_sync(hcon) hci_dev_lock hci_dev_lock hci_conn_del(hcon) v-------------------------------- hci_dev_unlock hci_conn_put(hcon) conn = hcon->l2cap_data (UAF)

Gravité et risque d'exploitation

CVE-2025-68304 obtient un score CVSS de 8.8/10, soit une gravité élevée. Selon le modèle EPSS, la probabilité qu'elle soit exploitée dans les 30 prochains jours est de 0.23 %, ce qui la place devant 13.1 % des CVE référencées.

Que faire ?

  • Vérifiez si Linux (versions 4d3ca4a9aaf0aa798a6be372dc0fc3a29e37dd57, 6.6, 6.17.11, <=*, <=6.17.*, <6.6, 6.18, 5af1f84ed13a416297ab9ced7537f4d5ae7f329a, 6.5.3, cd55c13bbb3d093ae601aa97e588ed4c1390ebb1, <6.2, 80265dd1d944c3f33e52375b5dbe654980bd2688, <6.5, 0, 6.4.16, <ec74cdf77310c43b01b83ee898a9bd4b4b0b8e93, 6.1.149, <79a2d4678ba90bdba577dc3af88cc900d6dcd5ee) est présent sur votre parc.
  • Appliquez le correctif ou la version corrigée indiqués dans les références de l'éditeur.
  • À défaut de correctif, limitez l'exposition (filtrage réseau, désactivation du composant).
  • Automatisez la détection : les agents CVE Heimdall (gratuits, open source) corrèlent l'inventaire de vos serveurs avec la base CVE.

Références