<?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>Mon, 28 Sep 2026 20:29:44 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-97536</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-97536</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown&lt;/p&gt;
&lt;p&gt;The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules
qla_do_work() via queue_work(ha-&amp;gt;wq, &amp;amp;qpair-&amp;gt;q_work). qla_do_work()
dereferences the qpair (vha, rsp) and takes qpair-&amp;gt;qp_lock.&lt;/p&gt;
&lt;p&gt;During teardown, qla2xxx_delete_qpair() deletes the response queue, which
calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and
the qpair. free_irq() waits for running hardirq handlers but does not
cancel work already placed on ha-&amp;gt;wq. A still-pending q_work then runs
qla_do_work() against the freed qpair and response queue, causing a
use-after-free. This is especially likely during full adapter teardown,
where destroy_workqueue(ha-&amp;gt;wq) forces pending work to run after the queue
pairs have been freed.&lt;/p&gt;
&lt;p&gt;Flush the work item with cancel_work_sync() in qla25xx_free_rsp_que()
after free_irq() has released the interrupt (so no new work can be
queued) and before the response queue and qpair memory are freed (so the
flushed handler still sees valid memory). Guard on rsp-&amp;gt;qpair and ha-&amp;gt;wq
to match the INIT_WORK() condition and avoid operating on an
uninitialized work_struct.&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;scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown&lt;/p&gt;
&lt;p&gt;The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules
qla_do_work() via queue_work(ha-&amp;gt;wq, &amp;amp;qpair-&amp;gt;q_work). qla_do_work()
dereferences the qpair (vha, rsp) and takes qpair-&amp;gt;qp_lock.&lt;/p&gt;
&lt;p&gt;During teardown, qla2xxx_delete_qpair() deletes the response queue, which
calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and
the qpair. free_irq() waits for running hardirq handlers but does not
cancel work already placed on ha-&amp;gt;wq. A still-pending q_work then runs
qla_do_work() against the freed qpair and response queue, causing a
use-after-free. This is especially likely during full adapter teardown,
where destroy_workqueue(ha-&amp;gt;wq) forces pending work to run after the queue
pairs have been freed.&lt;/p&gt;
&lt;p&gt;Flush the work item with cancel_work_sync() in qla25xx_free_rsp_que()
after free_irq() has released the interrupt (so no new work can be
queued) and before the response queue and qpair memory are freed (so the
flushed handler still sees valid memory). Guard on rsp-&amp;gt;qpair and ha-&amp;gt;wq
to match the INIT_WORK() condition and avoid operating on an
uninitialized work_struct.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-97536</guid>
    </item>
    <item>
      <title>GHSA-6h84-4ch4-64mj</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-6h84-4ch4-64mj</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown&lt;/p&gt;
&lt;p&gt;The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules
qla_do_work() via queue_work(ha-&amp;gt;wq, &amp;amp;qpair-&amp;gt;q_work). qla_do_work()
dereferences the qpair (vha, rsp) and takes qpair-&amp;gt;qp_lock.&lt;/p&gt;
&lt;p&gt;During teardown, qla2xxx_delete_qpair() deletes the response queue, which
calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and
the qpair. free_irq() waits for running hardirq handlers but does not
cancel work already placed on ha-&amp;gt;wq. A still-pending q_work then runs
qla_do_work() against the freed qpair and response queue, causing a
use-after-free. This is especially likely during full adapter teardown,
where destroy_workqueue(ha-&amp;gt;wq) forces pending work to run after the queue
pairs have been freed.&lt;/p&gt;
&lt;p&gt;Flush the work item with cancel_work_sync() in qla25xx_free_rsp_que()
after free_irq() has released the interrupt (so no new work can be
queued) and before the response queue and qpair memory are freed (so the
flushed handler still sees valid memory). Guard on rsp-&amp;gt;qpair and ha-&amp;gt;wq
to match the INIT_WORK() condition and avoid operating on an
uninitialized work_struct.&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;scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown&lt;/p&gt;
&lt;p&gt;The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules
qla_do_work() via queue_work(ha-&amp;gt;wq, &amp;amp;qpair-&amp;gt;q_work). qla_do_work()
dereferences the qpair (vha, rsp) and takes qpair-&amp;gt;qp_lock.&lt;/p&gt;
&lt;p&gt;During teardown, qla2xxx_delete_qpair() deletes the response queue, which
calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and
the qpair. free_irq() waits for running hardirq handlers but does not
cancel work already placed on ha-&amp;gt;wq. A still-pending q_work then runs
qla_do_work() against the freed qpair and response queue, causing a
use-after-free. This is especially likely during full adapter teardown,
where destroy_workqueue(ha-&amp;gt;wq) forces pending work to run after the queue
pairs have been freed.&lt;/p&gt;
&lt;p&gt;Flush the work item with cancel_work_sync() in qla25xx_free_rsp_que()
after free_irq() has released the interrupt (so no new work can be
queued) and before the response queue and qpair memory are freed (so the
flushed handler still sees valid memory). Guard on rsp-&amp;gt;qpair and ha-&amp;gt;wq
to match the INIT_WORK() condition and avoid operating on an
uninitialized work_struct.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-6h84-4ch4-64mj</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-97536</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97536</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: scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules qla_do_work() via queue_work(ha-&amp;gt;wq, &amp;amp;qpair-&amp;gt;q_work). qla_do_work() dereferences the qpair (vha, rsp) and takes qpair-&amp;gt;qp_lock. During teardown, qla2xxx_delete_qpair() deletes the response queue, which calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and the qpair. free_irq() waits for running hardirq handlers but does not cancel work already placed on ha-&amp;gt;wq. A still-pending q_work then runs qla_do_work() against the freed qpair and response queue, causing a use-after-free. This is especially likely during full adapter teardown, where destroy_workqueue(ha-&amp;gt;wq) forces pending work to run after the queue pairs have been freed. Flush the work item with cancel_work_sync() in qla25xx_free_rsp_que() after free_irq() has released the interrupt (so no new work can be queued) and before the response queue and qpair memory are freed (so the flushed handler still sees valid memory). Guard on rsp-&amp;gt;qpair and ha-&amp;gt;wq to match the INIT_WORK() condition and avoid operating on an uninitialized work_struct.&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: scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules qla_do_work() via queue_work(ha-&amp;gt;wq, &amp;amp;qpair-&amp;gt;q_work). qla_do_work() dereferences the qpair (vha, rsp) and takes qpair-&amp;gt;qp_lock. During teardown, qla2xxx_delete_qpair() deletes the response queue, which calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and the qpair. free_irq() waits for running hardirq handlers but does not cancel work already placed on ha-&amp;gt;wq. A still-pending q_work then runs qla_do_work() against the freed qpair and response queue, causing a use-after-free. This is especially likely during full adapter teardown, where destroy_workqueue(ha-&amp;gt;wq) forces pending work to run after the queue pairs have been freed. Flush the work item with cancel_work_sync() in qla25xx_free_rsp_que() after free_irq() has released the interrupt (so no new work can be queued) and before the response queue and qpair memory are freed (so the flushed handler still sees valid memory). Guard on rsp-&amp;gt;qpair and ha-&amp;gt;wq to match the INIT_WORK() condition and avoid operating on an uninitialized work_struct.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-97536</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3579 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2026-3579</guid>
    </item>
  </channel>
</rss>
