From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-98357: IB/isert: wait for deferred control PDU completions before releasing the connection
Date: Tue, 6 Oct 2026 10:47:38 +0200 [thread overview]
Message-ID: <2026100620-CVE-2026-98357-91fc@gregkh> (raw)
From: Greg Kroah-Hartman <gregkh@kernel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
IB/isert: wait for deferred control PDU completions before releasing the connection
isert_send_done() hands ISTATE_SEND_TASKMGTRSP, ISTATE_SEND_REJECT and
ISTATE_SEND_TEXTRSP completions off to isert_comp_wq and returns. The work
item then runs isert_completion_put() -> isert_put_cmd(), which reads
isert_conn->conn and takes conn->cmd_lock.
Nothing orders that work item against teardown. isert_wait_conn() queues
isert_release_work, which frees isert_conn, and iscsit_close_connection()
frees the iscsit_conn right after it returns, so the queued work can run
against freed memory.
Count the deferred control PDU completions per connection and let
isert_wait_conn() wait for them before the release work is queued.
ISTATE_SEND_LOGOUTRSP is deliberately not counted: that branch runs
iscsit_logout_post_handler(), which ends up waiting for
conn->conn_wait_comp, and that completion is only sent by
iscsit_close_connection() after it has called iscsit_wait_conn().
Waiting for it here would deadlock. Its wait stays the existing
isert_wait4logout().
The splat below is from a kernel with tracing printk()s and an msleep(200)
injected into isert_do_control_comp() to widen the window:
BUG: KASAN: slab-use-after-free in isert_put_cmd+0x53d/0x620
Read of size 8 at addr ffff8881054f1038 by task kworker/u17:1/182
CPU: 0 UID: 0 PID: 182 Comm: kworker/u17:1 Tainted: G B 7.2.0-rc5-TWIDE-gb8babf08acc7 #1 PREEMPT(lazy)
Tainted: [B]=BAD_PAGE
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: isert_comp_wq isert_do_control_comp
Call Trace:
<TASK>
dump_stack_lvl+0x53/0x70
print_report+0xd0/0x630
? __pfx__raw_spin_lock_irqsave+0x10/0x10
? _raw_spin_unlock_irqrestore+0x3e/0x70
? isert_put_cmd+0x53d/0x620
kasan_report+0xce/0x100
? isert_put_cmd+0x53d/0x620
isert_put_cmd+0x53d/0x620
? isert_completion_put+0x305/0x330
? isert_do_control_comp+0x2ef/0x310
process_one_work+0x633/0x1030
? assign_work+0x11d/0x370
worker_thread+0x45b/0xd10
? __pfx_worker_thread+0x10/0x10
? __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>
Allocated by task 48:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x8f/0xa0
__kmalloc_cache_noprof+0x158/0x370
isert_cma_handler+0x1e3/0x2ae0
cma_cm_event_handler+0x3e/0x240
cma_ib_req_handler+0x17d9/0x4490
cm_process_work+0x41/0x330
cm_work_handler+0x5727/0xc160
process_one_work+0x633/0x1030
worker_thread+0x45b/0xd10
kthread+0x2c6/0x3b0
ret_from_fork+0x36e/0x5a0
ret_from_fork_asm+0x1a/0x30
Freed by task 184:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x43/0x70
kfree+0x121/0x380
iscsit_close_connection+0x7cf/0x1e60
iscsit_take_action_for_connection_exit+0x1b6/0x360
iscsi_target_tx_thread+0x472/0x690
kthread+0x2c6/0x3b0
ret_from_fork+0x36e/0x5a0
ret_from_fork_asm+0x1a/0x30
The Linux kernel CVE team has assigned CVE-2026-98357 to this issue.
Affected and fixed versions
===========================
Issue introduced in 3.10 with commit b8d26b3be8b33682cf163274ed07479a70554633 and fixed in 5.10.271 with commit f5613acbe2e346d5c466ef0bd264fca936b69f82
Issue introduced in 3.10 with commit b8d26b3be8b33682cf163274ed07479a70554633 and fixed in 5.15.222 with commit ccdb1523f12bc8a9646de65055d1aafed9e9bcc6
Issue introduced in 3.10 with commit b8d26b3be8b33682cf163274ed07479a70554633 and fixed in 6.1.189 with commit 0e230917670c6e6fe3243abfa11299fcbe05b1f4
Issue introduced in 3.10 with commit b8d26b3be8b33682cf163274ed07479a70554633 and fixed in 6.6.158 with commit 505b242d9351690d1385bbe508ab4666f60363ce
Issue introduced in 3.10 with commit b8d26b3be8b33682cf163274ed07479a70554633 and fixed in 6.12.112 with commit 7edb8a88d6c76237c8b4435765bee1009e26a50a
Issue introduced in 3.10 with commit b8d26b3be8b33682cf163274ed07479a70554633 and fixed in 6.18.54 with commit b96b8b3e41c308f606ffd10cfef1a7b9f97414cd
Issue introduced in 3.10 with commit b8d26b3be8b33682cf163274ed07479a70554633 and fixed in 7.2.8 with commit 7908fbc597a694bbd99bfb59ece73bc3daded68e
Issue introduced in 3.10 with commit b8d26b3be8b33682cf163274ed07479a70554633 and fixed in 7.3-rc4 with commit a8fe3dfce8c0d8a76dc3d8486a5bff5feebe156f
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2026-98357
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
drivers/infiniband/ulp/isert/ib_isert.c
drivers/infiniband/ulp/isert/ib_isert.h
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/f5613acbe2e346d5c466ef0bd264fca936b69f82
https://git.kernel.org/stable/c/ccdb1523f12bc8a9646de65055d1aafed9e9bcc6
https://git.kernel.org/stable/c/0e230917670c6e6fe3243abfa11299fcbe05b1f4
https://git.kernel.org/stable/c/505b242d9351690d1385bbe508ab4666f60363ce
https://git.kernel.org/stable/c/7edb8a88d6c76237c8b4435765bee1009e26a50a
https://git.kernel.org/stable/c/b96b8b3e41c308f606ffd10cfef1a7b9f97414cd
https://git.kernel.org/stable/c/7908fbc597a694bbd99bfb59ece73bc3daded68e
https://git.kernel.org/stable/c/a8fe3dfce8c0d8a76dc3d8486a5bff5feebe156f
reply other threads:[~2026-10-06 10:29 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026100620-CVE-2026-98357-91fc@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=cve@kernel.org \
--cc=gregkh@kernel.org \
--cc=linux-cve-announce@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.