<?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://cve.radiocsirt.org</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>Sat, 03 Oct 2026 06:50:53 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-80781</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-80781</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-80781</guid>
    </item>
    <item>
      <title>certfr-2026-avi-1163 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Certaines d'entre elles permettent à…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1163</link>
      <description>certfr-2026-avi-1163</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1163</guid>
    </item>
    <item>
      <title>EUVD-2026-363802</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-363802</link>
      <description>EUVD-2026-363802</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-363802</guid>
    </item>
    <item>
      <title>fkie_cve-2026-80781</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-80781</link>
      <description>&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;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://cve.radiocsirt.org/vuln/fkie_cve-2026-80781</guid>
    </item>
    <item>
      <title>GHSA-4wjj-fc9c-xhfj</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-4wjj-fc9c-xhfj</link>
      <description>&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;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://cve.radiocsirt.org/vuln/ghsa-4wjj-fc9c-xhfj</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-80781 — HID: core: fix OOB read of field-&gt;usage in hid_set_field()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-80781</link>
      <description>msrc_CVE-2026-80781</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-80781</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11773-1 — kernel-devel-7.2.5-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11773-1</link>
      <description>&lt;p&gt;kernel-devel-7.2.5-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.2.5-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11773-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-80781</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-80781</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field-&amp;gt;usage in hid_set_field() hid_set_field() hands field-&amp;gt;usage + offset to hid_dump_input() before the guard that bounds offset: 	hid_dump_input(field-&amp;gt;report-&amp;gt;device, field-&amp;gt;usage + offset, value); 	if (offset &amp;gt;= field-&amp;gt;report_count) { 		hid_err(...); 		return -1; 	} 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. 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. Move the hid_dump_input() call below the guard.  Because field-&amp;gt;maxusage &amp;gt;= field-&amp;gt;report_count, the guard then estab…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: HID: core: fix OOB read of field-&amp;gt;usage in hid_set_field() hid_set_field() hands field-&amp;gt;usage + offset to hid_dump_input() before the guard that bounds offset: 	hid_dump_input(field-&amp;gt;report-&amp;gt;device, field-&amp;gt;usage + offset, value); 	if (offset &amp;gt;= field-&amp;gt;report_count) { 		hid_err(...); 		return -1; 	} 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. 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. Move the hid_dump_input() call below the guard.  Because field-&amp;gt;maxusage &amp;gt;= field-&amp;gt;report_count, the guard then estab…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-80781</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3211 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3211</link>
      <description>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um Speicherfehler und Kernel-Abstürze beziehungsweise Denial-of-Service-Zustände auszulösen, Speicher außerhalb vorgesehener Grenzen auszulesen sowie in einzelnen Fällen weitere Sicherheitsauswirkungen zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um Speicherfehler und Kernel-Abstürze beziehungsweise Denial-of-Service-Zustände auszulösen, Speicher außerhalb vorgesehener Grenzen auszulesen sowie in einzelnen Fällen weitere Sicherheitsauswirkungen zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3211</guid>
    </item>
  </channel>
</rss>
