All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Michael Bommarito <michael.bommarito@gmail.com>
Cc: Leon Romanovsky <leon@kernel.org>,
	Zhu Yanjun <yanjun.zhu@linux.dev>,
	hkbinbin <hkbinbinbin@gmail.com>,
	linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] RDMA/rxe: Reject unknown opcodes before ICRC processing
Date: Tue, 28 Apr 2026 11:39:37 -0300	[thread overview]
Message-ID: <20260428143937.GA2655407@nvidia.com> (raw)
In-Reply-To: <20260414111555.3386793-1-michael.bommarito@gmail.com>

On Tue, Apr 14, 2026 at 07:15:55AM -0400, Michael Bommarito wrote:
> Even after applying commit 7244491dab34 ("RDMA/rxe: Validate pad and ICRC
> before payload_size() in rxe_rcv"), a single unauthenticated UDP packet
> can still trigger panic.  That patch handled payload_size() underflow
> only for valid opcodes with short packets, not for packets carrying an
> unknown opcode.  The unknown-opcode OOB read described below
> predates that commit and reaches back to the initial Soft RoCE driver.
> 
> The check added there reads
> 
>     pkt->paylen < header_size(pkt) + bth_pad(pkt) + RXE_ICRC_SIZE
> 
> where header_size(pkt) expands to rxe_opcode[pkt->opcode].length.  The
> rxe_opcode[] array has 256 entries but is only populated for defined IB
> opcodes; any other entry (for example opcode 0xff) is zero-initialized,
> so length == 0 and the check degenerates to
> 
>     pkt->paylen < 0 + bth_pad(pkt) + RXE_ICRC_SIZE
> 
> which does not constrain pkt->paylen enough.  rxe_icrc_hdr() then
> computes
> 
>     rxe_opcode[pkt->opcode].length - RXE_BTH_BYTES
> 
> which underflows when length == 0 and passes a huge value to
> rxe_crc32(), causing an out-of-bounds read of the skb payload.
> 
> Reproduced on v7.0-rc7 with that fix applied, QEMU/KVM with
> CONFIG_RDMA_RXE=y and CONFIG_KASAN=y, after
> 
>     rdma link add rxe0 type rxe netdev eth0
> 
> A single 48-byte UDP packet to port 4791 with BTH opcode=0xff and
> QPN=IB_MULTICAST_QPN triggers:
> 
>     BUG: KASAN: slab-out-of-bounds in crc32_le+0x115/0x170
>     Read of size 1 at addr ...
>     The buggy address is located 0 bytes to the right of
>      allocated 704-byte region
>     Call Trace:
>      crc32_le+0x115/0x170
>      rxe_icrc_hdr.isra.0+0x226/0x300
>      rxe_icrc_check+0x13f/0x3a0
>      rxe_rcv+0x6e1/0x16e0
>      rxe_udp_encap_recv+0x20a/0x320
>      udp_queue_rcv_one_skb+0x7ed/0x12c0
> 
> Subsequent packets with the same shape fault on unmapped memory and
> panic the kernel.  The trigger requires only module load and
> "rdma link add"; no QP, no connection, and no authentication.
> 
> Fix this by rejecting packets whose opcode has no rxe_opcode[] entry,
> detected via the zero mask or zero length, before any length
> arithmetic runs.
> 
> Fixes: 8700e3e7c485 ("Soft RoCE driver")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
> ---
> v2: also check rxe_opcode[].length per Zhu Yanjun; "||" rather than
>     "&&" so the guard tracks the actual underflow in rxe_icrc_hdr().
>
> v1 was sent privately to security@kernel.org.
> 
>  drivers/infiniband/sw/rxe/rxe_recv.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)

Applied to rc thanks

Jason

      reply	other threads:[~2026-04-28 14:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-14 11:15 [PATCH v2] RDMA/rxe: Reject unknown opcodes before ICRC processing Michael Bommarito
2026-04-28 14:39 ` Jason Gunthorpe [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=20260428143937.GA2655407@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=hkbinbinbin@gmail.com \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=michael.bommarito@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=yanjun.zhu@linux.dev \
    /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.