The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Cc: sagi@grimberg.me, jgg@ziepe.ca, linux-rdma@vger.kernel.org,
	target-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] IB/isert: reject PDUs declaring more data than was received
Date: Mon, 27 Jul 2026 08:15:57 +0300	[thread overview]
Message-ID: <20260727051557.GH12003@unreal> (raw)
In-Reply-To: <20260726153130.934622-1-yhlee@isslab.korea.ac.kr>

On Mon, Jul 27, 2026 at 12:31:30AM +0900, Yehyeong Lee wrote:
> On Sun, Jul 26, 2026 at 09:46:28AM +0300, Leon Romanovsky wrote:
> > 1. You should review patches generated by AI.
> > 2. There is a need to add similar check to isert_get_login_rx() too.
> 
> You are right on both counts.  My changelog said the login handler
> "already rejects PDUs shorter than ISER_HEADERS_LEN"; I confirmed that a
> length check existed there and did not confirm that it was the same
> check.  It is not - 29e7b925ae6d bounds login_req_len from below, and
> nothing bounds the length the BHS declares.
> 
> I reproduced it before replying.  An initiator that sends a 105-byte
> first login PDU while declaring 8193 in the BHS DataSegmentLength, on
> 7.2.0-rc4 with KASAN over soft-RoCE:
> 
>   BUG: KASAN: slab-out-of-bounds in kmemdup_nul+0x43/0x80
>   Read of size 8193 at addr ffff8881056a8000 by task iscsi_np/167
>    __asan_memcpy+0x23/0x60
>    kmemdup_nul+0x43/0x80
>    iscsi_target_locate_portal+0x48d/0x1180
>    iscsi_target_login_thread+0x19a9/0x3350
>   Allocated by task 167:
>    __kmalloc_cache_noprof+0x158/0x370
>    iscsi_target_login_thread+0x971/0x3350
>   The buggy address belongs to the object at ffff8881056a8000
>    which belongs to the cache kmalloc-8k of size 8192
>   allocated 8192-byte region
> 
> faddr2line puts the allocation at iscsi_login_init_conn(),
> iscsi_target_login.c:50 - login->req_buf = kzalloc(MAX_KEY_VALUE_PAIRS) -
> and the read at iscsi_target_nego.c:1136, the kmemdup_nul() in
> iscsi_target_locate_portal().  The read size tracks the declared value
> exactly; 16384 gives "Read of size 16384", and a control run with a
> correct DataSegmentLength produces no report.  It is reached before
> authentication and the length is attacker-chosen.
> 
> On why isert is the one exposed: iscsi_target_check_login_request()
> already rejects payload_length > MAX_KEY_VALUE_PAIRS, but it is only
> called from iscsit_get_login_rx() and from cxgbit.  isert does not call
> it.  iscsit over TCP is safe by construction in any case - it reads
> exactly payload_length + padding from the socket, so the declared length
> governs how much arrives rather than how much is copied out of an
> already-filled buffer.
> 
> Your check is sufficient and not merely necessary: the posted login SGE
> is ISER_RX_PAYLOAD_SIZE, so login_req_len cannot exceed
> MAX_KEY_VALUE_PAIRS and size = min(login_req_len, MAX_KEY_VALUE_PAIRS)
> is login_req_len; once dlength <= login_req_len the copy out stays
> inside what was copied in.

I have little desire to argue with chatbot, but the second check MUST to
be added.

Thanks

> 
> I will send a v2 two-patch series - the isert_recv_done() check as 1/2
> and this one as 2/2 with Suggested-by: Leon Romanovsky
> <leonro@nvidia.com> - once the before/after on the login case is run.
> 
> Best regards,

      reply	other threads:[~2026-07-27  5:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-25  1:18 [PATCH] IB/isert: reject PDUs declaring more data than was received Yehyeong Lee
2026-07-26  6:46 ` Leon Romanovsky
2026-07-26 15:31   ` Yehyeong Lee
2026-07-27  5:15     ` Leon Romanovsky [this message]

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=20260727051557.GH12003@unreal \
    --to=leon@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=sagi@grimberg.me \
    --cc=stable@vger.kernel.org \
    --cc=target-devel@vger.kernel.org \
    --cc=yhlee@isslab.korea.ac.kr \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox