<?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>Sun, 04 Oct 2026 03:51:31 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-80781 — HID: core: fix OOB read of field-&gt;usage in hid_set_field()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-80781</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;HID: core: fix OOB read of field-&amp;gt;usage in hid_set_field()&lt;/p&gt;
&lt;p&gt;hid_set_field() hands field-&amp;gt;usage + offset to hid_dump_input() before
the guard that bounds offset:&lt;/p&gt;
&lt;p&gt;hid_dump_input(field-&amp;gt;report-&amp;gt;device, field-&amp;gt;usage + offset, value);&lt;/p&gt;
&lt;p&gt;if (offset &amp;gt;= field-&amp;gt;report_count) {
		hid_err(...);
		return -1;
	}&lt;/p&gt;
&lt;p&gt;Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with
buf = hid_resolv_usage(usage-&amp;gt;hid, NULL).  The usage[] array is
allocated inline with the hid_field in hid_register_field() and holds
field-&amp;gt;maxusage entries, so an offset past it reads off the end of the
kvzalloc()ed allocation and into a neighbouring object.  Had the guard
run first, offset &amp;lt; report_count &amp;lt;= maxusage would already have confined
the pointer to the array.&lt;/p&gt;
&lt;p&gt;A caller supplies such an offset today.  picolcd_fb_send_tile()
validates only report-&amp;gt;maxfield before issuing
hid_set_field(report-&amp;gt;field[0], 11 + i, ...) for i = 0..31, so its
offsets are fixed at 11..42 and are never checked against the bound
field.  When the device registers that field with fewer usages, the
framebuffer deferred-io work drives the read on every tile.  KASAN
reports a 4-byte slab-out-of-bounds read in hid_dump_input() below
hid_set_field(), and the same boot logs &amp;#34;offset (1) exceeds
report_count (1)&amp;#34; from the guard that runs only afterwards.&lt;/p&gt;
&lt;p&gt;Move the hid_dump_input() call below the guard.  Because
field-&amp;gt;maxusage &amp;gt;= field-&amp;gt;report_count, the guard the…&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;HID: core: fix OOB read of field-&amp;gt;usage in hid_set_field()&lt;/p&gt;
&lt;p&gt;hid_set_field() hands field-&amp;gt;usage + offset to hid_dump_input() before
the guard that bounds offset:&lt;/p&gt;
&lt;p&gt;hid_dump_input(field-&amp;gt;report-&amp;gt;device, field-&amp;gt;usage + offset, value);&lt;/p&gt;
&lt;p&gt;if (offset &amp;gt;= field-&amp;gt;report_count) {
		hid_err(...);
		return -1;
	}&lt;/p&gt;
&lt;p&gt;Under CONFIG_DEBUG_FS hid_dump_input() dereferences that pointer, with
buf = hid_resolv_usage(usage-&amp;gt;hid, NULL).  The usage[] array is
allocated inline with the hid_field in hid_register_field() and holds
field-&amp;gt;maxusage entries, so an offset past it reads off the end of the
kvzalloc()ed allocation and into a neighbouring object.  Had the guard
run first, offset &amp;lt; report_count &amp;lt;= maxusage would already have confined
the pointer to the array.&lt;/p&gt;
&lt;p&gt;A caller supplies such an offset today.  picolcd_fb_send_tile()
validates only report-&amp;gt;maxfield before issuing
hid_set_field(report-&amp;gt;field[0], 11 + i, ...) for i = 0..31, so its
offsets are fixed at 11..42 and are never checked against the bound
field.  When the device registers that field with fewer usages, the
framebuffer deferred-io work drives the read on every tile.  KASAN
reports a 4-byte slab-out-of-bounds read in hid_dump_input() below
hid_set_field(), and the same boot logs &amp;#34;offset (1) exceeds
report_count (1)&amp;#34; from the guard that runs only afterwards.&lt;/p&gt;
&lt;p&gt;Move the hid_dump_input() call below the guard.  Because
field-&amp;gt;maxusage &amp;gt;= field-&amp;gt;report_count, the guard the…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-80781</guid>
    </item>
  </channel>
</rss>
