Cloudanix VulnDB

CVE-2026-98358

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux kernel code for certain high-speed storage connections can let a storage device cause the computer to crash.

Exploitation
Remote Authenticated
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Null pointer dereference in iser_check_remote_inv and iser_inv_desc triggered when an RDMA target issues IB_WR_SEND_WITH_INV against an iSER direction left unregistered (immediate-data write path), resulting in a general protection fault during descriptor access in iser_task_rsp.

Why it matters to the business

Denial of service via kernel panic on Linux initiators using iSER over RDMA; systems handling untrusted storage targets may experience repeated crashes and loss of availability.

How an attack unfolds

An attacker positioned as a malicious RDMA target accepts an iSER write command whose data arrives entirely as immediate data (no memory registration performed). The attacker then replies with a send-with-invalidate work request targeting the unregistered direction. The initiator's iser_check_remote_inv consults only the direction array, passes a NULL descriptor to iser_inv_desc, and dereferences sig_protected, crashing the kernel.

How to fix it

Upgrade the Linux kernel to a version containing the fix that causes iser_check_remote_inv to terminate the connection on remote invalidation of an unregistered direction; apply the patch that rejects such invalidations with the same handling already used for unsolicited invalidations.

How to confirm the fix worked

Confirm the kernel source contains the updated iser_check_remote_inv logic that checks for NULL descriptors before calling iser_inv_desc and verify the absence of the prior null-ptr-deref path in iser_task_rsp.

Typical attack path

  1. Establish an RDMA/iSER session as the target
  2. Receive an iSER write command sent entirely via immediate data
  3. Reply with IB_WR_SEND_WITH_INV for the unregistered ISER_DIR_OUT direction
  4. Trigger null dereference inside iser_task_rsp on the initiator

How to detect it

Inspect kernel logs and dmesg for Oops entries, general protection faults, or KASAN null-ptr-deref reports citing iser_task_rsp, iser_inv_desc, or rxe_receiver in conjunction with iSER or RDMA workqueues.

  • iser_task_rsp+0x6d6/0xec0
  • KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]
  • Oops: general protection fault, probably for non-canonical address
  • iser_check_remote_inv

What your security team should do

  • Prioritize kernel updates on any system exposing iSER/RDMA initiators to untrusted targets
  • Restrict RDMA connectivity to trusted storage endpoints until patches are applied
  • Enable kernel panic logging and monitor for oops entries referencing iser_task_rsp

The record

In the Linux kernel, the following vulnerability has been resolved: IB/iser: reject a remote invalidation of an unregistered direction A write command whose data is sent entirely as immediate data is not registered. iser_reg_mem_fastreg() takes the DMA key path and leaves rdma_reg[ISER_DIR_OUT].desc at NULL, while iser_dma_map_task_data() has already set dir[ISER_DIR_OUT]. iser_check_remote_inv() looks at dir[] alone and hands the descriptor to iser_inv_desc(), which reads desc->sig_protected. A target that answers such a command with IB_WR_SEND_WITH_INV faults the initiator. Leaving those commands unregistered is deliberate. The same function already terminates the connection when a target sends a remote invalidation the initiator did not ask for. A target that invalidates a direction that was never registered is in the same class, so give it the same answer. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000004: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] CPU: 0 UID: 0 PID: 40 Comm: kworker/u8:2 Not tainted 7.2.0-rc5-ISERHOST-gf5098b6bae76-dirty #3 PREEMPT(lazy) Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: rxe_wq do_work RIP: 0010:iser_task_rsp+0x6d6/0xec0 Code: 48 c1 ea 03 80 3c 02 00 0f 85 ba 06 00 00 48 8b 9b 78 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 20 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 06 0f 8e 76 06 00 00 80 7b 20 00 0f 84 3d 04 RSP: 0018:ffff88811b008db8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000001848 RDX: 0000000000000004 RSI: 1ffff11021587b12 RDI: 0000000000000020 RBP: ffff88810adc1ae4 R08: ffff888109b7f860 R09: ffffffff90a922c0 R10: ffff88810adc1a1c R11: 000000000000003c R12: ffff888109b7f800 R13: ffff88810adc1acc R14: ffff888109b7f820 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88818a676000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005afe2b CR3: 000000010af23005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <IRQ> __ib_process_cq+0xe1/0x390 ib_poll_handler+0x6e/0x200 irq_poll_softirq+0x1df/0x480 ? clockevents_program_event+0x2ba/0x860 ? __pfx_irq_poll_softirq+0x10/0x10 handle_softirqs+0x18e/0x590 ? __pfx_handle_softirqs+0x10/0x10 ? __hrtimer_rearm_deferred+0x156/0x450 do_softirq+0x3b/0x60 </IRQ> <TASK> __local_bh_enable_ip+0x61/0x70 __alloc_skb+0x732/0x890 ? _raw_spin_lock_irqsave+0x85/0xe0 ? __pfx___alloc_skb+0x10/0x10 ? _raw_read_unlock_irqrestore+0x16/0x50 rxe_init_packet+0x16b/0x4f0 prepare_ack_packet+0xb8/0x830 rxe_receiver+0x499/0x9980 ? __pfx_rxe_receiver+0x10/0x10 ? rxe_completer+0x29e5/0x38c0 ? hrtimer_start_range_ns_common+0x75f/0x1730 ? hrtimer_start_range_ns+0xa6/0x2c0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __pfx_rxe_receiver+0x10/0x10 do_work+0x144/0x470 process_one_work+0x633/0x1030 ? assign_work+0x11d/0x370 worker_thread+0x45b/0xd10 ? __pfx_worker_thread+0x10/0x10 kthread+0x2c6/0x3b0 ? recalc_sigpending+0x15c/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x36e/0x5a0 ? __pfx_ret_from_fork+0x10/0x10 ? __switch_to+0x572/0xdd0 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]---

Affected packages

Ecosystem Package Introduced Fixed