<?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>Tue, 29 Sep 2026 05:26:49 +0000</lastBuildDate>
    <item>
      <title>CVE-2022-49551 — usb: isp1760: Fix out-of-bounds array access</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2022-49551</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;usb: isp1760: Fix out-of-bounds array access&lt;/p&gt;
&lt;p&gt;Running the driver through kasan gives an interesting splat:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c
  Read of size 20 at addr f1db2e64 by task swapper/0/1
  (...)
  isp1760_register from isp1760_plat_probe+0x1d8/0x220
  (...)&lt;/p&gt;
&lt;p&gt;This happens because the loop reading the regmap fields for the
different ISP1760 variants look like this:&lt;/p&gt;
&lt;p&gt;for (i = 0; i &amp;lt; HC_FIELD_MAX; i++) { ... }&lt;/p&gt;
&lt;p&gt;Meaning it expects the arrays to be at least HC_FIELD_MAX - 1 long.&lt;/p&gt;
&lt;p&gt;However the arrays isp1760_hc_reg_fields[], isp1763_hc_reg_fields[],
isp1763_hc_volatile_ranges[] and isp1763_dc_volatile_ranges[] are
dynamically sized during compilation.&lt;/p&gt;
&lt;p&gt;Fix this by putting an empty assignment to the [HC_FIELD_MAX]
and [DC_FIELD_MAX] array member at the end of each array.
This will make the array one member longer than it needs to be,
but avoids the risk of overwriting whatever is inside
[HC_FIELD_MAX - 1] and is simple and intuitive to read. Also
add comments explaining what is going on.&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;usb: isp1760: Fix out-of-bounds array access&lt;/p&gt;
&lt;p&gt;Running the driver through kasan gives an interesting splat:&lt;/p&gt;
&lt;p&gt;BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c
  Read of size 20 at addr f1db2e64 by task swapper/0/1
  (...)
  isp1760_register from isp1760_plat_probe+0x1d8/0x220
  (...)&lt;/p&gt;
&lt;p&gt;This happens because the loop reading the regmap fields for the
different ISP1760 variants look like this:&lt;/p&gt;
&lt;p&gt;for (i = 0; i &amp;lt; HC_FIELD_MAX; i++) { ... }&lt;/p&gt;
&lt;p&gt;Meaning it expects the arrays to be at least HC_FIELD_MAX - 1 long.&lt;/p&gt;
&lt;p&gt;However the arrays isp1760_hc_reg_fields[], isp1763_hc_reg_fields[],
isp1763_hc_volatile_ranges[] and isp1763_dc_volatile_ranges[] are
dynamically sized during compilation.&lt;/p&gt;
&lt;p&gt;Fix this by putting an empty assignment to the [HC_FIELD_MAX]
and [DC_FIELD_MAX] array member at the end of each array.
This will make the array one member longer than it needs to be,
but avoids the risk of overwriting whatever is inside
[HC_FIELD_MAX - 1] and is simple and intuitive to read. Also
add comments explaining what is going on.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2022-49551</guid>
    </item>
  </channel>
</rss>
