https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 02 Nov 2026 09:29:25 +0000 https://db.gcve.eu/vuln/certfr-2026-avi-1375 certfr-2026-avi-1375 https://db.gcve.eu/vuln/certfr-2026-avi-1375 https://db.gcve.eu/vuln/fkie_cve-2026-98632 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel</p> <p>In send_cancel(), pending mesh_tx objects are removed from the hdev-&gt;mesh_pending list and freed via mesh_send_complete(). However, if a mesh transmission was already queued onto hdev-&gt;cmd_sync_work_list via mesh_next(), the queued entry retains a raw pointer to mesh_tx.</p> <p>When hci_cmd_sync_work later processes the entry, it attempts to execute mesh_send_sync and its destroy callback mesh_send_start_complete using the already freed mesh_tx pointer, leading to a use-after-free.</p> <p>Fix this by invoking hci_cmd_sync_dequeue() for mesh_send_sync on the target mesh_tx before completing it. If the entry is found and dequeued, its destroy callback will complete and free the object; otherwise, mesh_send_complete() is called directly.</p> <p>Additionally, ensure the transmission queue advances after cancellation or errors. In mesh_send_start_complete(), call mesh_next() on error unless err is -ECANCELED, because hci_cmd_sync_dequeue() holds hdev-&gt;cmd_sync_work_lock and calling mesh_next() synchronously would deadlock. Instead, advance the queue in send_cancel() once the lock is released and if no transmission is in progress.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel</p> <p>In send_cancel(), pending mesh_tx objects are removed from the hdev-&gt;mesh_pending list and freed via mesh_send_complete(). However, if a mesh transmission was already queued onto hdev-&gt;cmd_sync_work_list via mesh_next(), the queued entry retains a raw pointer to mesh_tx.</p> <p>When hci_cmd_sync_work later processes the entry, it attempts to execute mesh_send_sync and its destroy callback mesh_send_start_complete using the already freed mesh_tx pointer, leading to a use-after-free.</p> <p>Fix this by invoking hci_cmd_sync_dequeue() for mesh_send_sync on the target mesh_tx before completing it. If the entry is found and dequeued, its destroy callback will complete and free the object; otherwise, mesh_send_complete() is called directly.</p> <p>Additionally, ensure the transmission queue advances after cancellation or errors. In mesh_send_start_complete(), call mesh_next() on error unless err is -ECANCELED, because hci_cmd_sync_dequeue() holds hdev-&gt;cmd_sync_work_lock and calling mesh_next() synchronously would deadlock. Instead, advance the queue in send_cancel() once the lock is released and if no transmission is in progress.</p> https://db.gcve.eu/vuln/fkie_cve-2026-98632 https://db.gcve.eu/vuln/ghsa-qvq7-5mpj-hvwr <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel</p> <p>In send_cancel(), pending mesh_tx objects are removed from the hdev-&gt;mesh_pending list and freed via mesh_send_complete(). However, if a mesh transmission was already queued onto hdev-&gt;cmd_sync_work_list via mesh_next(), the queued entry retains a raw pointer to mesh_tx.</p> <p>When hci_cmd_sync_work later processes the entry, it attempts to execute mesh_send_sync and its destroy callback mesh_send_start_complete using the already freed mesh_tx pointer, leading to a use-after-free.</p> <p>Fix this by invoking hci_cmd_sync_dequeue() for mesh_send_sync on the target mesh_tx before completing it. If the entry is found and dequeued, its destroy callback will complete and free the object; otherwise, mesh_send_complete() is called directly.</p> <p>Additionally, ensure the transmission queue advances after cancellation or errors. In mesh_send_start_complete(), call mesh_next() on error unless err is -ECANCELED, because hci_cmd_sync_dequeue() holds hdev-&gt;cmd_sync_work_lock and calling mesh_next() synchronously would deadlock. Instead, advance the queue in send_cancel() once the lock is released and if no transmission is in progress.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel</p> <p>In send_cancel(), pending mesh_tx objects are removed from the hdev-&gt;mesh_pending list and freed via mesh_send_complete(). However, if a mesh transmission was already queued onto hdev-&gt;cmd_sync_work_list via mesh_next(), the queued entry retains a raw pointer to mesh_tx.</p> <p>When hci_cmd_sync_work later processes the entry, it attempts to execute mesh_send_sync and its destroy callback mesh_send_start_complete using the already freed mesh_tx pointer, leading to a use-after-free.</p> <p>Fix this by invoking hci_cmd_sync_dequeue() for mesh_send_sync on the target mesh_tx before completing it. If the entry is found and dequeued, its destroy callback will complete and free the object; otherwise, mesh_send_complete() is called directly.</p> <p>Additionally, ensure the transmission queue advances after cancellation or errors. In mesh_send_start_complete(), call mesh_next() on error unless err is -ECANCELED, because hci_cmd_sync_dequeue() holds hdev-&gt;cmd_sync_work_lock and calling mesh_next() synchronously would deadlock. Instead, advance the queue in send_cancel() once the lock is released and if no transmission is in progress.</p> https://db.gcve.eu/vuln/ghsa-qvq7-5mpj-hvwr https://db.gcve.eu/vuln/msrc_cve-2026-98632 msrc_CVE-2026-98632 https://db.gcve.eu/vuln/msrc_cve-2026-98632 https://db.gcve.eu/vuln/ubuntu-cve-2026-98632 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 154 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel In send_cancel(), pending mesh_tx objects are removed from the hdev-&gt;mesh_pending list and freed via mesh_send_complete(). However, if a mesh transmission was already queued onto hdev-&gt;cmd_sync_work_list via mesh_next(), the queued entry retains a raw pointer to mesh_tx. When hci_cmd_sync_work later processes the entry, it attempts to execute mesh_send_sync and its destroy callback mesh_send_start_complete using the already freed mesh_tx pointer, leading to a use-after-free. Fix this by invoking hci_cmd_sync_dequeue() for mesh_send_sync on the target mesh_tx before completing it. If the entry is found and dequeued, its destroy callback will complete and free the object; otherwise, mesh_send_complete() is called directly. Additionally, ensure the transmission queue advances after cancellation or errors. In mesh_send_start_complete(), call mesh_next() on error unless err is -ECANCELED, because hci_cmd_sync_dequeue() holds hdev-&gt;cmd_sync_work_lock and calling mesh_next() synchronously would deadlock. Instead, advance the queue in send_cancel() once the lock is released and if no transmission is in progress.</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 154 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel In send_cancel(), pending mesh_tx objects are removed from the hdev-&gt;mesh_pending list and freed via mesh_send_complete(). However, if a mesh transmission was already queued onto hdev-&gt;cmd_sync_work_list via mesh_next(), the queued entry retains a raw pointer to mesh_tx. When hci_cmd_sync_work later processes the entry, it attempts to execute mesh_send_sync and its destroy callback mesh_send_start_complete using the already freed mesh_tx pointer, leading to a use-after-free. Fix this by invoking hci_cmd_sync_dequeue() for mesh_send_sync on the target mesh_tx before completing it. If the entry is found and dequeued, its destroy callback will complete and free the object; otherwise, mesh_send_complete() is called directly. Additionally, ensure the transmission queue advances after cancellation or errors. In mesh_send_start_complete(), call mesh_next() on error unless err is -ECANCELED, because hci_cmd_sync_dequeue() holds hdev-&gt;cmd_sync_work_lock and calling mesh_next() synchronously would deadlock. Instead, advance the queue in send_cancel() once the lock is released and if no transmission is in progress.</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-98632