All of lore.kernel.org
 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: 5+ 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]
2026-07-27 10:13       ` Yehyeong Lee

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 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.