<?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://db.gcve.eu</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, 10 Nov 2026 01:02:43 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-99183</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-99183</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;accel/rocket: search every core slot when looking up a scheduler&lt;/p&gt;
&lt;p&gt;sched_to_core() walks rdev-&amp;gt;cores[] up to rdev-&amp;gt;num_cores, and
rocket_remove() decrements num_cores for every core it removes. Unbind a
core that is not the last one and the cores behind it fall outside the
search, so sched_to_core() returns NULL for a core that is still bound and
still running jobs. Neither caller checks the result:&lt;/p&gt;
&lt;p&gt;rocket_job_run():      rocket_fence_create(core), core-&amp;gt;dev
  rocket_job_timedout(): dev_err(core-&amp;gt;dev, &amp;#34;NPU job timed out&amp;#34;)&lt;/p&gt;
&lt;p&gt;Unbinding the middle core of the three on an RK3588 while three clients are
submitting to all of them faults twice, once from the surviving core&amp;#39;s
job queue and once from its reset work:&lt;/p&gt;
&lt;p&gt;KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]
  Workqueue: fdad0000.npu drm_sched_run_job_work [gpu_sched]
  pc : rocket_job_run+0x234/0x838 [rocket]
  Call trace:
   rocket_job_run+0x234/0x838 [rocket]
   drm_sched_run_job_work+0x2cc/0xad8 [gpu_sched]
   process_one_work+0x640/0x14f0&lt;/p&gt;
&lt;p&gt;KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  Workqueue: rocket-reset-2 drm_sched_job_timedout [gpu_sched]
  pc : rocket_job_timedout+0xf0/0x1e0 [rocket]
  Call trace:
   rocket_job_timedout+0xf0/0x1e0 [rocket]
   drm_sched_job_timedout+0x188/0x6a0 [gpu_sched]&lt;/p&gt;
&lt;p&gt;Both are the third core: the workqueue names are its device and its
core-&amp;gt;index, and it was left at slot 2…&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;accel/rocket: search every core slot when looking up a scheduler&lt;/p&gt;
&lt;p&gt;sched_to_core() walks rdev-&amp;gt;cores[] up to rdev-&amp;gt;num_cores, and
rocket_remove() decrements num_cores for every core it removes. Unbind a
core that is not the last one and the cores behind it fall outside the
search, so sched_to_core() returns NULL for a core that is still bound and
still running jobs. Neither caller checks the result:&lt;/p&gt;
&lt;p&gt;rocket_job_run():      rocket_fence_create(core), core-&amp;gt;dev
  rocket_job_timedout(): dev_err(core-&amp;gt;dev, &amp;#34;NPU job timed out&amp;#34;)&lt;/p&gt;
&lt;p&gt;Unbinding the middle core of the three on an RK3588 while three clients are
submitting to all of them faults twice, once from the surviving core&amp;#39;s
job queue and once from its reset work:&lt;/p&gt;
&lt;p&gt;KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]
  Workqueue: fdad0000.npu drm_sched_run_job_work [gpu_sched]
  pc : rocket_job_run+0x234/0x838 [rocket]
  Call trace:
   rocket_job_run+0x234/0x838 [rocket]
   drm_sched_run_job_work+0x2cc/0xad8 [gpu_sched]
   process_one_work+0x640/0x14f0&lt;/p&gt;
&lt;p&gt;KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  Workqueue: rocket-reset-2 drm_sched_job_timedout [gpu_sched]
  pc : rocket_job_timedout+0xf0/0x1e0 [rocket]
  Call trace:
   rocket_job_timedout+0xf0/0x1e0 [rocket]
   drm_sched_job_timedout+0x188/0x6a0 [gpu_sched]&lt;/p&gt;
&lt;p&gt;Both are the third core: the workqueue names are its device and its
core-&amp;gt;index, and it was left at slot 2…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-99183</guid>
    </item>
    <item>
      <title>GHSA-cgc9-44mx-vhwg</title>
      <link>https://db.gcve.eu/vuln/ghsa-cgc9-44mx-vhwg</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;accel/rocket: search every core slot when looking up a scheduler&lt;/p&gt;
&lt;p&gt;sched_to_core() walks rdev-&amp;gt;cores[] up to rdev-&amp;gt;num_cores, and
rocket_remove() decrements num_cores for every core it removes. Unbind a
core that is not the last one and the cores behind it fall outside the
search, so sched_to_core() returns NULL for a core that is still bound and
still running jobs. Neither caller checks the result:&lt;/p&gt;
&lt;p&gt;rocket_job_run():      rocket_fence_create(core), core-&amp;gt;dev
  rocket_job_timedout(): dev_err(core-&amp;gt;dev, &amp;#34;NPU job timed out&amp;#34;)&lt;/p&gt;
&lt;p&gt;Unbinding the middle core of the three on an RK3588 while three clients are
submitting to all of them faults twice, once from the surviving core&amp;#39;s
job queue and once from its reset work:&lt;/p&gt;
&lt;p&gt;KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]
  Workqueue: fdad0000.npu drm_sched_run_job_work [gpu_sched]
  pc : rocket_job_run+0x234/0x838 [rocket]
  Call trace:
   rocket_job_run+0x234/0x838 [rocket]
   drm_sched_run_job_work+0x2cc/0xad8 [gpu_sched]
   process_one_work+0x640/0x14f0&lt;/p&gt;
&lt;p&gt;KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  Workqueue: rocket-reset-2 drm_sched_job_timedout [gpu_sched]
  pc : rocket_job_timedout+0xf0/0x1e0 [rocket]
  Call trace:
   rocket_job_timedout+0xf0/0x1e0 [rocket]
   drm_sched_job_timedout+0x188/0x6a0 [gpu_sched]&lt;/p&gt;
&lt;p&gt;Both are the third core: the workqueue names are its device and its
core-&amp;gt;index, and it was left at slot 2…&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;accel/rocket: search every core slot when looking up a scheduler&lt;/p&gt;
&lt;p&gt;sched_to_core() walks rdev-&amp;gt;cores[] up to rdev-&amp;gt;num_cores, and
rocket_remove() decrements num_cores for every core it removes. Unbind a
core that is not the last one and the cores behind it fall outside the
search, so sched_to_core() returns NULL for a core that is still bound and
still running jobs. Neither caller checks the result:&lt;/p&gt;
&lt;p&gt;rocket_job_run():      rocket_fence_create(core), core-&amp;gt;dev
  rocket_job_timedout(): dev_err(core-&amp;gt;dev, &amp;#34;NPU job timed out&amp;#34;)&lt;/p&gt;
&lt;p&gt;Unbinding the middle core of the three on an RK3588 while three clients are
submitting to all of them faults twice, once from the surviving core&amp;#39;s
job queue and once from its reset work:&lt;/p&gt;
&lt;p&gt;KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]
  Workqueue: fdad0000.npu drm_sched_run_job_work [gpu_sched]
  pc : rocket_job_run+0x234/0x838 [rocket]
  Call trace:
   rocket_job_run+0x234/0x838 [rocket]
   drm_sched_run_job_work+0x2cc/0xad8 [gpu_sched]
   process_one_work+0x640/0x14f0&lt;/p&gt;
&lt;p&gt;KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  Workqueue: rocket-reset-2 drm_sched_job_timedout [gpu_sched]
  pc : rocket_job_timedout+0xf0/0x1e0 [rocket]
  Call trace:
   rocket_job_timedout+0xf0/0x1e0 [rocket]
   drm_sched_job_timedout+0x188/0x6a0 [gpu_sched]&lt;/p&gt;
&lt;p&gt;Both are the third core: the workqueue names are its device and its
core-&amp;gt;index, and it was left at slot 2…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-cgc9-44mx-vhwg</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-99183</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-99183</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 127 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: accel/rocket: search every core slot when looking up a scheduler sched_to_core() walks rdev-&amp;gt;cores[] up to rdev-&amp;gt;num_cores, and rocket_remove() decrements num_cores for every core it removes. Unbind a core that is not the last one and the cores behind it fall outside the search, so sched_to_core() returns NULL for a core that is still bound and still running jobs. Neither caller checks the result:   rocket_job_run():      rocket_fence_create(core), core-&amp;gt;dev   rocket_job_timedout(): dev_err(core-&amp;gt;dev, &amp;#34;NPU job timed out&amp;#34;) Unbinding the middle core of the three on an RK3588 while three clients are submitting to all of them faults twice, once from the surviving core&amp;#39;s job queue and once from its reset work:   KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]   Workqueue: fdad0000.npu drm_sched_run_job_work [gpu_sched]   pc : rocket_job_run+0x234/0x838 [rocket]   Call trace:    rocket_job_run+0x234/0x838 [rocket]    drm_sched_run_job_work+0x2cc/0xad8 [gpu_sched]    process_one_work+0x640/0x14f0   KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]   Workqueue: rocket-reset-2 drm_sched_job_timedout [gpu_sched]   pc : rocket_job_timedout+0xf0/0x1e0 [rocket]   Call trace:    rocket_job_timedout+0xf0/0x1e0 [rocket]    drm_sched_job_timedout+0x188/0x6a0 [gpu_sched] Both are the third core: the workqueue names are its device and its core-&amp;gt;index, and it was left at slot 2 while…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 127 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: accel/rocket: search every core slot when looking up a scheduler sched_to_core() walks rdev-&amp;gt;cores[] up to rdev-&amp;gt;num_cores, and rocket_remove() decrements num_cores for every core it removes. Unbind a core that is not the last one and the cores behind it fall outside the search, so sched_to_core() returns NULL for a core that is still bound and still running jobs. Neither caller checks the result:   rocket_job_run():      rocket_fence_create(core), core-&amp;gt;dev   rocket_job_timedout(): dev_err(core-&amp;gt;dev, &amp;#34;NPU job timed out&amp;#34;) Unbinding the middle core of the three on an RK3588 while three clients are submitting to all of them faults twice, once from the surviving core&amp;#39;s job queue and once from its reset work:   KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]   Workqueue: fdad0000.npu drm_sched_run_job_work [gpu_sched]   pc : rocket_job_run+0x234/0x838 [rocket]   Call trace:    rocket_job_run+0x234/0x838 [rocket]    drm_sched_run_job_work+0x2cc/0xad8 [gpu_sched]    process_one_work+0x640/0x14f0   KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]   Workqueue: rocket-reset-2 drm_sched_job_timedout [gpu_sched]   pc : rocket_job_timedout+0xf0/0x1e0 [rocket]   Call trace:    rocket_job_timedout+0xf0/0x1e0 [rocket]    drm_sched_job_timedout+0x188/0x6a0 [gpu_sched] Both are the third core: the workqueue names are its device and its core-&amp;gt;index, and it was left at slot 2 while…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-99183</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-4224 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://db.gcve.eu/vuln/wid-sec-w-2026-4224</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/wid-sec-w-2026-4224</guid>
    </item>
  </channel>
</rss>
