<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/target/iscsi, branch linux-5.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-06-04T12:32:29Z</updated>
<entry>
<title>scsi: target: iscsi: Fix timeout on deleted connection</title>
<updated>2025-06-04T12:32:29Z</updated>
<author>
<name>Dmitry Bogdanov</name>
</author>
<published>2024-12-24T10:17:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=571ce6b6f5cbaf7d24af03cad592fc0e2a54de35'/>
<id>urn:sha1:571ce6b6f5cbaf7d24af03cad592fc0e2a54de35</id>
<content type='text'>
[ Upstream commit 7f533cc5ee4c4436cee51dc58e81dfd9c3384418 ]

NOPIN response timer may expire on a deleted connection and crash with
such logs:

Did not receive response to NOPIN on CID: 0, failing connection for I_T Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d

BUG: Kernel NULL pointer dereference on read at 0x00000000
NIP  strlcpy+0x8/0xb0
LR iscsit_fill_cxn_timeout_err_stats+0x5c/0xc0 [iscsi_target_mod]
Call Trace:
 iscsit_handle_nopin_response_timeout+0xfc/0x120 [iscsi_target_mod]
 call_timer_fn+0x58/0x1f0
 run_timer_softirq+0x740/0x860
 __do_softirq+0x16c/0x420
 irq_exit+0x188/0x1c0
 timer_interrupt+0x184/0x410

That is because nopin response timer may be re-started on nopin timer
expiration.

Stop nopin timer before stopping the nopin response timer to be sure
that no one of them will be re-started.

Signed-off-by: Dmitry Bogdanov &lt;d.bogdanov@yadro.com&gt;
Link: https://lore.kernel.org/r/20241224101757.32300-1-d.bogdanov@yadro.com
Reviewed-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()</title>
<updated>2023-09-23T09:00:05Z</updated>
<author>
<name>Konstantin Shelekhin</name>
</author>
<published>2023-07-22T15:26:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2cbe6a88fbdd6e8aeab358eef61472e2de43d6f6'/>
<id>urn:sha1:2cbe6a88fbdd6e8aeab358eef61472e2de43d6f6</id>
<content type='text'>
[ Upstream commit 801f287c93ff95582b0a2d2163f12870a2f076d4 ]

The function lio_target_nacl_info_show() uses sprintf() in a loop to print
details for every iSCSI connection in a session without checking for the
buffer length. With enough iSCSI connections it's possible to overflow the
buffer provided by configfs and corrupt the memory.

This patch replaces sprintf() with sysfs_emit_at() that checks for buffer
boundries.

Signed-off-by: Konstantin Shelekhin &lt;k.shelekhin@yadro.com&gt;
Link: https://lore.kernel.org/r/20230722152657.168859-2-k.shelekhin@yadro.com
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: target: iscsi: Prevent login threads from racing between each other</title>
<updated>2023-06-28T08:18:40Z</updated>
<author>
<name>Maurizio Lombardi</name>
</author>
<published>2023-05-08T16:22:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2af8d9637270c9fb0300299458d115f625ee8c84'/>
<id>urn:sha1:2af8d9637270c9fb0300299458d115f625ee8c84</id>
<content type='text'>
[ Upstream commit 2a737d3b8c792400118d6cf94958f559de9c5e59 ]

The tpg-&gt;np_login_sem is a semaphore that is used to serialize the login
process when multiple login threads run concurrently against the same
target portal group.

The iscsi_target_locate_portal() function finds the tpg, calls
iscsit_access_np() against the np_login_sem semaphore and saves the tpg
pointer in conn-&gt;tpg;

If iscsi_target_locate_portal() fails, the caller will check for the
conn-&gt;tpg pointer and, if it's not NULL, then it will assume that
iscsi_target_locate_portal() called iscsit_access_np() on the semaphore.

Make sure that conn-&gt;tpg gets initialized only if iscsit_access_np() was
successful, otherwise iscsit_deaccess_np() may end up being called against
a semaphore we never took, allowing more than one thread to access the same
tpg.

Signed-off-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Link: https://lore.kernel.org/r/20230508162219.1731964-4-mlombard@redhat.com
Reviewed-by: Mike Christie &lt;michael.christie@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: target: iscsit: Free cmds before session free</title>
<updated>2023-05-30T11:44:03Z</updated>
<author>
<name>Dmitry Bogdanov</name>
</author>
<published>2023-03-19T01:56:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=89f5055f9b0b57c7e7f02e32df95ef401f809b71'/>
<id>urn:sha1:89f5055f9b0b57c7e7f02e32df95ef401f809b71</id>
<content type='text'>
[ Upstream commit d8990b5a4d065f38f35d69bcd627ec5a7f8330ca ]

Commands from recovery entries are freed after session has been closed.
That leads to use-after-free at command free or NPE with such call trace:

Time2Retain timer expired for SID: 1, cleaning up iSCSI session.
BUG: kernel NULL pointer dereference, address: 0000000000000140
RIP: 0010:sbitmap_queue_clear+0x3a/0xa0
Call Trace:
 target_release_cmd_kref+0xd1/0x1f0 [target_core_mod]
 transport_generic_free_cmd+0xd1/0x180 [target_core_mod]
 iscsit_free_cmd+0x53/0xd0 [iscsi_target_mod]
 iscsit_free_connection_recovery_entries+0x29d/0x320 [iscsi_target_mod]
 iscsit_close_session+0x13a/0x140 [iscsi_target_mod]
 iscsit_check_post_dataout+0x440/0x440 [iscsi_target_mod]
 call_timer_fn+0x24/0x140

Move cleanup of recovery enrties to before session freeing.

Reported-by: Forza &lt;forza@tnonline.net&gt;
Signed-off-by: Dmitry Bogdanov &lt;d.bogdanov@yadro.com&gt;
Signed-off-by: Mike Christie &lt;michael.christie@oracle.com&gt;
Link: https://lore.kernel.org/r/20230319015620.96006-7-michael.christie@oracle.com
Reviewed-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: target: iscsit: Fix TAS handling during conn cleanup</title>
<updated>2023-05-17T09:35:41Z</updated>
<author>
<name>Mike Christie</name>
</author>
<published>2023-03-19T01:56:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a4245323d272a4a0382dfa4a02f59c5ed8ca2a37'/>
<id>urn:sha1:a4245323d272a4a0382dfa4a02f59c5ed8ca2a37</id>
<content type='text'>
[ Upstream commit cc79da306ebb2edb700c3816b90219223182ac3c ]

Fix a bug added in commit f36199355c64 ("scsi: target: iscsi: Fix cmd abort
fabric stop race").

If CMD_T_TAS is set on the se_cmd we must call iscsit_free_cmd() to do the
last put on the cmd and free it, because the connection is down and we will
not up sending the response and doing the put from the normal I/O
path.

Add a check for CMD_T_TAS in iscsit_release_commands_from_conn() so we now
detect this case and run iscsit_free_cmd().

Fixes: f36199355c64 ("scsi: target: iscsi: Fix cmd abort fabric stop race")
Signed-off-by: Mike Christie &lt;michael.christie@oracle.com&gt;
Link: https://lore.kernel.org/r/20230319015620.96006-9-michael.christie@oracle.com
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: target: iscsi: Fix an error message in iscsi_check_key()</title>
<updated>2023-04-05T09:16:39Z</updated>
<author>
<name>Maurizio Lombardi</name>
</author>
<published>2023-02-14T14:15:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=54ec697e3ca8e6d7693394d81978f5140b74b840'/>
<id>urn:sha1:54ec697e3ca8e6d7693394d81978f5140b74b840</id>
<content type='text'>
[ Upstream commit 6cc55c969b7ce8d85e09a636693d4126c3676c11 ]

The first half of the error message is printed by pr_err(), the second half
is printed by pr_debug(). The user will therefore see only the first part
of the message and will miss some useful information.

Link: https://lore.kernel.org/r/20230214141556.762047-1-mlombard@redhat.com
Signed-off-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Reviewed-by: Mike Christie &lt;michael.christie@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: target: iscsi: Make sure the np under each tpg is unique</title>
<updated>2022-02-16T11:52:48Z</updated>
<author>
<name>ZouMingzhe</name>
</author>
<published>2022-01-11T05:47:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c6a7077144ed291cfbf736875ad0fe89e6291f02'/>
<id>urn:sha1:c6a7077144ed291cfbf736875ad0fe89e6291f02</id>
<content type='text'>
[ Upstream commit a861790afaa8b6369eee8a88c5d5d73f5799c0c6 ]

iscsit_tpg_check_network_portal() has nested for_each loops and is supposed
to return true when a match is found. However, the tpg loop will still
continue after existing the tpg_np loop. If this tpg_np is not the last the
match value will be changed.

Break the outer loop after finding a match and make sure the np under each
tpg is unique.

Link: https://lore.kernel.org/r/20220111054742.19582-1-mingzhe.zou@easystack.cn
Signed-off-by: ZouMingzhe &lt;mingzhe.zou@easystack.cn&gt;
Reviewed-by: Mike Christie &lt;michael.christie@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: target: cxgbit: Unmap DMA buffer before calling target_execute_cmd()</title>
<updated>2021-07-14T14:53:48Z</updated>
<author>
<name>Varun Prakash</name>
</author>
<published>2021-04-14T12:39:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1bfb3a070b580a0873870a396c4f6a0788815ad3'/>
<id>urn:sha1:1bfb3a070b580a0873870a396c4f6a0788815ad3</id>
<content type='text'>
commit 6ecdafaec79d4b3388a5b017245f23a0ff9d852d upstream.

Instead of calling dma_unmap_sg() after completing WRITE I/O, call
dma_unmap_sg() before calling target_execute_cmd() to sync the DMA buffer.

Link: https://lore.kernel.org/r/1618403949-3443-1-git-send-email-varun@chelsio.com
Cc: &lt;stable@vger.kernel.org&gt; # 5.4+
Signed-off-by: Varun Prakash &lt;varun@chelsio.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>cxgb4/chtls/cxgbit: Keeping the max ofld immediate data size same in cxgb4 and ulds</title>
<updated>2021-03-04T09:26:17Z</updated>
<author>
<name>Ayush Sawal</name>
</author>
<published>2021-02-15T11:42:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9db1f14e7043a3d55b53dfb692559d0b815f18b3'/>
<id>urn:sha1:9db1f14e7043a3d55b53dfb692559d0b815f18b3</id>
<content type='text'>
[ Upstream commit 2355a6773a2cb0d2dce13432dde78497f1d6617b ]

The Max imm data size in cxgb4 is not similar to the max imm data size
in the chtls. This caused an mismatch in output of is_ofld_imm() of
cxgb4 and chtls. So fixed this by keeping the max wreq size of imm data
same in both chtls and cxgb4 as MAX_IMM_OFLD_TX_DATA_WR_LEN.

As cxgb4's max imm. data value for ofld packets is changed to
MAX_IMM_OFLD_TX_DATA_WR_LEN. Using the same in cxgbit also.

Fixes: 36bedb3f2e5b8 ("crypto: chtls - Inline TLS record Tx")
Signed-off-by: Ayush Sawal &lt;ayush.sawal@chelsio.com&gt;
Acked-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: target: iscsi: Fix cmd abort fabric stop race</title>
<updated>2020-12-02T07:49:49Z</updated>
<author>
<name>Mike Christie</name>
</author>
<published>2020-11-14T01:46:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fd81f0711d9c6013f234cf9874e12031d4a06025'/>
<id>urn:sha1:fd81f0711d9c6013f234cf9874e12031d4a06025</id>
<content type='text'>
[ Upstream commit f36199355c64a39fe82cfddc7623d827c7e050da ]

Maurizio found a race where the abort and cmd stop paths can race as
follows:

 1. thread1 runs iscsit_release_commands_from_conn and sets
    CMD_T_FABRIC_STOP.

 2. thread2 runs iscsit_aborted_task and then does __iscsit_free_cmd. It
    then returns from the aborted_task callout and we finish
    target_handle_abort and do:

    target_handle_abort -&gt; transport_cmd_check_stop_to_fabric -&gt;
	lio_check_stop_free -&gt; target_put_sess_cmd

    The cmd is now freed.

 3. thread1 now finishes iscsit_release_commands_from_conn and runs
    iscsit_free_cmd while accessing a command we just released.

In __target_check_io_state we check for CMD_T_FABRIC_STOP and set the
CMD_T_ABORTED if the driver is not cleaning up the cmd because of a session
shutdown. However, iscsit_release_commands_from_conn only sets the
CMD_T_FABRIC_STOP and does not check to see if the abort path has claimed
completion ownership of the command.

This adds a check in iscsit_release_commands_from_conn so only the abort or
fabric stop path cleanup the command.

Link: https://lore.kernel.org/r/1605318378-9269-1-git-send-email-michael.christie@oracle.com
Reported-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Reviewed-by: Maurizio Lombardi &lt;mlombard@redhat.com&gt;
Signed-off-by: Mike Christie &lt;michael.christie@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
