<?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 22:16:19 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-93119 — usb: ljca: bound bank_num in ljca_enumerate_gpio()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-93119</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: ljca: bound bank_num in ljca_enumerate_gpio()&lt;/p&gt;
&lt;p&gt;ljca_enumerate_gpio() reads desc-&amp;gt;bank_num from the device and loops
valid_pin[i] = get_unaligned_le32(...) for i &amp;lt; bank_num. valid_pin[]
holds only LJCA_MAX_GPIO_NUM / 32 = 2 entries.&lt;/p&gt;
&lt;p&gt;Two checks run before the loop. The reply length must match
struct_size(desc, bank_desc, bank_num). The product
pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM. Neither one
bounds bank_num against the size of valid_pin[]. The reply is capped at
LJCA_MAX_PAYLOAD_SIZE (60) bytes, so the struct_size check limits
bank_num to 9. A device that reports bank_num 9 with pins_per_bank 7
still passes both checks. gpio_num is 63 and the reply is 56 bytes. The
loop then writes nine u32 into the two entry array and overruns
valid_pin[] on the stack.&lt;/p&gt;
&lt;p&gt;A broken or malicious LJCA device can therefore overflow the stack.
Reject a bank_num that does not fit valid_pin[].&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: ljca: bound bank_num in ljca_enumerate_gpio()&lt;/p&gt;
&lt;p&gt;ljca_enumerate_gpio() reads desc-&amp;gt;bank_num from the device and loops
valid_pin[i] = get_unaligned_le32(...) for i &amp;lt; bank_num. valid_pin[]
holds only LJCA_MAX_GPIO_NUM / 32 = 2 entries.&lt;/p&gt;
&lt;p&gt;Two checks run before the loop. The reply length must match
struct_size(desc, bank_desc, bank_num). The product
pins_per_bank * bank_num must not exceed LJCA_MAX_GPIO_NUM. Neither one
bounds bank_num against the size of valid_pin[]. The reply is capped at
LJCA_MAX_PAYLOAD_SIZE (60) bytes, so the struct_size check limits
bank_num to 9. A device that reports bank_num 9 with pins_per_bank 7
still passes both checks. gpio_num is 63 and the reply is 56 bytes. The
loop then writes nine u32 into the two entry array and overruns
valid_pin[] on the stack.&lt;/p&gt;
&lt;p&gt;A broken or malicious LJCA device can therefore overflow the stack.
Reject a bank_num that does not fit valid_pin[].&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-93119</guid>
    </item>
  </channel>
</rss>
