<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-09T22:11:50.968112+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2026-45898</id>
    <title>CVE-2026-45898 — RDMA/iwcm: Fix workqueue list corruption by removing work_list</title>
    <updated>2026-10-09T22:11:50.984194+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 10.0 Extended Update Support, Red Hat Enterprise Linux 9, Red Hat Enterprise Linux 9.6 Extended Update Support, Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>RDMA/iwcm: Fix workqueue list corruption by removing work_list</p>
<p>The commit e1168f0 ("RDMA/iwcm: Simplify cm_event_handler()")
changed the work submission logic to unconditionally call
queue_work() with the expectation that queue_work() would
have no effect if work was already pending. The problem is
that a free list of struct iwcm_work is used (for which
struct work_struct is embedded), so each call to queue_work()
is basically unique and therefore does indeed queue the work.</p>
<p>This causes a problem in the work handler which walks the work_list
until it's empty to process entries. This means that a single
run of the work handler could process item N+1 and release it
back to the free list while the actual workqueue entry is still
queued. It could then get reused (INIT_WORK...) and lead to
list corruption in the workqueue logic.</p>
<p>Fix this by just removing the work_list. The workqueue already
does this for us.</p>
<p>This fixes the following error that was observed when stress
testing with ucmatose on an Intel E830 in iWARP mode:</p>
<p>[  151.465780] list_del corruption. next-&gt;prev should be ffff9f0915c69c08, but was ffff9f0a1116be08. (next=ffff9f0a15b11c08)
[  151.466639] ------------[ cut here ]------------
[  151.466986] kernel BUG at lib/list_debug.c:67!
[  151.467349] Oops: invalid opcode: 0000 [#1] SMP NOPTI
[  151.467753] CPU: 14 UID: 0 PID: 2306 Comm: kworker/u64:18 Not tainted 6.19.0-rc4+ #1 PREEMPT(voluntary)
[…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-45898"/>
  </entry>
</feed>
