All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Romanovsky <leon@kernel.org>
To: "Korb, Andreas" <andreas.korb@aisec.fraunhofer.de>
Cc: "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: Re: [BUG] librdmacm: Accessing out-of-bounds memory
Date: Mon, 13 Apr 2026 19:02:27 +0300	[thread overview]
Message-ID: <20260413160227.GM21470@unreal> (raw)
In-Reply-To: <BE1P281MB24354B8B12B48B807C4453E5CA242@BE1P281MB2435.DEUP281.PROD.OUTLOOK.COM>

On Mon, Apr 13, 2026 at 06:54:32AM +0000, Korb, Andreas wrote:
> > -----Original Message-----
> > From: Leon Romanovsky <leon@kernel.org>
> > Sent: Sonntag, 12. April 2026 16:04
> > To: Korb, Andreas <andreas.korb@aisec.fraunhofer.de>
> > Cc: linux-rdma@vger.kernel.org
> > Subject: Re: [BUG] librdmacm: Accessing out-of-bounds memory
> > 
> > On Tue, Apr 07, 2026 at 01:14:45PM +0000, Korb, Andreas wrote:
> > > The function `ds_init_ep` in librdmacm/rsocket.c may access memory via an object that is not allocated for this object.
> > >
> > > Relevant lines from this function:
> > >
> > > // (1): Prepare `struct rsocket`
> > > ds_set_qp_size(rs);
> > > // (2): Allocation
> > > rs->sbuf = calloc(rs->sq_size, RS_SNDLOWAT);
> > > // (3): Copy pointer to rs->smsg_free
> > > rs->smsg_free = (struct ds_smsg *) rs->sbuf;
> > > // (4): Copy pointer to msg
> > > msg = rs->smsg_free;
> > > // (5): Write to msg->next
> > > msg->next = NULL;
> > >
> > > Within my podman container:
> > > Before (1): rs->sq_size = rs->rq_size = 384
> > > After (1): rs->sq_size = rs->rq_size = 0
> > > Therefore, (2) does not reserve a buffer, but still returns a pointer which can be freed later, as described by man-page calloc(3p).
> > > (5) writes data to the buffer allocated in (2). If no actual buffer is allocated, it overwrites arbitrary data, yielding undefined
> > > behavior.
> > >
> > > I found it by executing /usr/bin/udpong (without any arguments) with libscudo on an arm64 server with memory tagging enabled. It
> > > immediately crashes with a segmentation fault, then. Without memory tagging, the bug stays undetected, and execution continues.
> > > The code behavior described above also happens on x86-64, there it doesn't result in a crash and is silently ignored because of the
> > > lack of MemoryTagging. Valgrind also detects this violation, however.
> > >
> > > In summary:
> > > The libc man-page states that if the allocated buffer size is 0, then either:
> > > >        *  A null pointer shall be returned and errno may be set to an
> > > >        implementation-defined value, or
> > > >        *  A pointer to the allocated space shall be returned. The
> > > >        application shall ensure that the pointer is not used to
> > > >        access an object.
> > 
> > Can you please provide a link to these sentences in the manual?
> > 
> > You provided invalid value as sq_size and rq_size. It is expected that
> > library won't work after that.
> > 
> > Thanks
> 
> These sentences are from: https://man7.org/linux/man-pages/man3/calloc.3p.html
> 
> When the incoming values of sq_size and rq_size are wrong, that is a
> bug in udpong then. However, since librdmacm is doing the calloc allocation,
> it should still refrain from undefined behavior with the own allocated buffer.

I don't think so. This buffer is allocated in application memory, and if  
the application is buggy, that is its problem, not the library's.

Thanks

  reply	other threads:[~2026-04-13 16:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-07 13:14 [BUG] librdmacm: Accessing out-of-bounds memory Korb, Andreas
2026-04-12 14:04 ` Leon Romanovsky
2026-04-13  6:54   ` Korb, Andreas
2026-04-13 16:02     ` Leon Romanovsky [this message]
2026-04-14  8:37       ` Korb, Andreas
2026-04-14  9:24         ` Leon Romanovsky

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=20260413160227.GM21470@unreal \
    --to=leon@kernel.org \
    --cc=andreas.korb@aisec.fraunhofer.de \
    --cc=linux-rdma@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.