<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 10:29:20 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-68298 — Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-68298</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref&lt;/p&gt;
&lt;p&gt;In btusb_mtk_setup(), we set `btmtk_data-&amp;gt;isopkt_intf` to:
  usb_ifnum_to_if(data-&amp;gt;udev, MTK_ISO_IFNUM)&lt;/p&gt;
&lt;p&gt;That function can return NULL in some cases. Even when it returns
NULL, though, we still go on to call btusb_mtk_claim_iso_intf().&lt;/p&gt;
&lt;p&gt;As of commit e9087e828827 (&amp;#34;Bluetooth: btusb: mediatek: Add locks for
usb_driver_claim_interface()&amp;#34;), calling btusb_mtk_claim_iso_intf()
when `btmtk_data-&amp;gt;isopkt_intf` is NULL will cause a crash because
we&amp;#39;ll end up passing a bad pointer to device_lock(). Prior to that
commit we&amp;#39;d pass the NULL pointer directly to
usb_driver_claim_interface() which would detect it and return an
error, which was handled.&lt;/p&gt;
&lt;p&gt;Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check
at the start of the function. This makes the code handle a NULL
`btmtk_data-&amp;gt;isopkt_intf` the same way it did before the problematic
commit (just with a slight change to the error message printed).&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL deref&lt;/p&gt;
&lt;p&gt;In btusb_mtk_setup(), we set `btmtk_data-&amp;gt;isopkt_intf` to:
  usb_ifnum_to_if(data-&amp;gt;udev, MTK_ISO_IFNUM)&lt;/p&gt;
&lt;p&gt;That function can return NULL in some cases. Even when it returns
NULL, though, we still go on to call btusb_mtk_claim_iso_intf().&lt;/p&gt;
&lt;p&gt;As of commit e9087e828827 (&amp;#34;Bluetooth: btusb: mediatek: Add locks for
usb_driver_claim_interface()&amp;#34;), calling btusb_mtk_claim_iso_intf()
when `btmtk_data-&amp;gt;isopkt_intf` is NULL will cause a crash because
we&amp;#39;ll end up passing a bad pointer to device_lock(). Prior to that
commit we&amp;#39;d pass the NULL pointer directly to
usb_driver_claim_interface() which would detect it and return an
error, which was handled.&lt;/p&gt;
&lt;p&gt;Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL check
at the start of the function. This makes the code handle a NULL
`btmtk_data-&amp;gt;isopkt_intf` the same way it did before the problematic
commit (just with a slight change to the error message printed).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-68298</guid>
    </item>
  </channel>
</rss>
