CVE-2026-45898
Critical · 9.8CVSS
9.8
EPSS
0.5%
Published
May 27, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's networking code for certain high-speed connections could make the whole system crash when under heavy load.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Race condition in RDMA/iwcm workqueue handling where repeated queue_work calls on a free-list of iwcm_work structs cause concurrent list modifications, resulting in list_del corruption and kernel oops during work processing.
Why it matters to the business
Kernel crashes on systems using iWARP RDMA networking under load, leading to service disruption and potential loss of high-performance interconnect availability; low EPSS indicates limited in-the-wild exploitation risk despite high CVSS.
How an attack unfolds
An attacker with access to trigger RDMA connection management events (e.g., via ucmatose or similar stress tools in iWARP mode) repeatedly queues work items; the flawed handler processes and frees items while they remain queued, allowing reuse that corrupts internal workqueue lists and triggers kernel panic.
How to fix it
Update to a Linux kernel containing the fix that removes the work_list in favor of relying solely on the workqueue; monitor kernel changelogs for the referenced commit e1168f0 follow-up.
How to confirm the fix worked
Confirm kernel version includes the RDMA/iwcm work_list removal; reproduce stress test with ucmatose on iWARP hardware and verify absence of list_del corruption messages or kworker oops in dmesg.
Typical attack path
- Obtain local or RDMA-capable network access to target system
- Trigger repeated RDMA CM events to exercise iwcm work submission path
- Induce concurrent queue_work and handler execution to hit free-list reuse
- Cause list_del corruption leading to kernel BUG/oops and potential code execution or denial of service
How to detect it
Search kernel logs and dmesg for 'list_del corruption', 'iw_cm_wq', '__list_del_entry_valid_or_report', and call traces involving move_linked_works or kworker threads on RDMA systems.
- list_del corruption. next->prev should be
- Workqueue: 0x0 (iw_cm_wq)
- kernel BUG at lib/list_debug.c:67!
- Oops: invalid opcode: 0000
- RDMA/iwcm: Fix workqueue list corruption
What your security team should do
- Prioritize kernel upgrades for any systems exposing RDMA/iWARP interfaces
- Restrict untrusted local access and RDMA device exposure until patched
- Monitor for list corruption events in system logs as a temporary detection measure
The record
In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix workqueue list corruption by removing work_list 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. 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. Fix this by just removing the work_list. The workqueue already does this for us. This fixes the following error that was observed when stress testing with ucmatose on an Intel E830 in iWARP mode: [ 151.465780] list_del corruption. next->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) [ 151.468466] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 151.469192] Workqueue: 0x0 (iw_cm_wq) [ 151.469478] RIP: 0010:__list_del_entry_valid_or_report+0xf0/0x100 [ 151.469942] Code: c7 58 5f 4c b2 e8 10 50 aa ff 0f 0b 48 89 ef e8 36 57 cb ff 48 8b 55 08 48 89 e9 48 89 de 48 c7 c7 a8 5f 4c b2 e8 f0 4f aa ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 90 90 90 90 90 [ 151.471323] RSP: 0000:ffffb15644e7bd68 EFLAGS: 00010046 [ 151.471712] RAX: 000000000000006d RBX: ffff9f0915c69c08 RCX: 0000000000000027 [ 151.472243] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9f0a37d9c600 [ 151.472768] RBP: ffff9f0a15b11c08 R08: 0000000000000000 R09: c0000000ffff7fff [ 151.473294] R10: 0000000000000001 R11: ffffb15644e7bba8 R12: ffff9f092339ee68 [ 151.473817] R13: ffff9f0900059c28 R14: ffff9f092339ee78 R15: 0000000000000000 [ 151.474344] FS: 0000000000000000(0000) GS:ffff9f0a847b5000(0000) knlGS:0000000000000000 [ 151.474934] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 151.475362] CR2: 0000559e233a9088 CR3: 000000020296b004 CR4: 0000000000770ef0 [ 151.475895] PKRU: 55555554 [ 151.476118] Call Trace: [ 151.476331] <TASK> [ 151.476497] move_linked_works+0x49/0xa0 [ 151.476792] __pwq_activate_work.isra.46+0x2f/0xa0 [ 151.477151] pwq_dec_nr_in_flight+0x1e0/0x2f0 [ 151.477479] process_scheduled_works+0x1c8/0x410 [ 151.477823] worker_thread+0x125/0x260 [ 151.478108] ? __pfx_worker_thread+0x10/0x10 [ 151.478430] kthread+0xfe/0x240 [ 151.478671] ? __pfx_kthread+0x10/0x10 [ 151.478955] ? __pfx_kthread+0x10/0x10 [ 151.479240] ret_from_fork+0x208/0x270 [ 151.479523] ? __pfx_kthread+0x10/0x10 [ 151.479806] ret_from_fork_asm+0x1a/0x30 [ 151.480103] </TASK>
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| openSUSE:Leap 16.0 | dtb-aarch64 | 0 | 6.12.0-160000.35.1 |
| openSUSE:Leap 16.0 | kernel-64kb | 0 | 6.12.0-160000.35.1 |
| openSUSE:Leap 16.0 | kernel-azure | 0 | 6.12.0-160000.35.1 |
| openSUSE:Leap 16.0 | kernel-default | 0 | 6.12.0-160000.35.1 |
| openSUSE:Leap 16.0 | kernel-default-base | 0 | 6.12.0-160000.35.1.160000.2.16 |
| openSUSE:Leap 16.0 | kernel-docs | 0 | 6.12.0-160000.35.1 |
| openSUSE:Leap 16.0 | kernel-kvmsmall | 0 | 6.12.0-160000.35.1 |
| openSUSE:Leap 16.0 | kernel-obs-build | 0 | 6.12.0-160000.35.1 |
| openSUSE:Leap 16.0 | kernel-obs-qa | 0 | 6.12.0-160000.35.1 |
| openSUSE:Leap 16.0 | kernel-rt | 0 | 6.12.0-160000.35.1 |
| openSUSE:Leap 16.0 | kernel-source | 0 | 6.12.0-160000.35.1 |
| openSUSE:Leap 16.0 | kernel-syms | 0 | 6.12.0-160000.35.1 |
| openSUSE:Leap 16.0 | kernel-zfcpdump | 0 | 6.12.0-160000.35.1 |
Related vulnerabilities
- CVE-2026-46317 In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Reassign… Also affects dtb-aarch64
- CVE-2026-46316 In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its… Also affects dtb-aarch64
- CVE-2026-46181 In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx4: Fix… Also affects dtb-aarch64
- CVE-2026-46176 In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix error… Also affects dtb-aarch64
- CVE-2026-46159 In the Linux kernel, the following vulnerability has been resolved: btrfs: fix… Also affects dtb-aarch64
- CVE-2026-46114 In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Reject… Also affects dtb-aarch64
- CVE-2026-46090 In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer… Also affects dtb-aarch64
- CVE-2026-46094 In the Linux kernel, the following vulnerability has been resolved: ext4: fix bounds… Also affects dtb-aarch64