From: sashiko-bot@kernel.org
To: "Jason Gunthorpe" <jgg@nvidia.com>
Cc: linux-hyperv@vger.kernel.org
Subject: Re: [PATCH v3 10/10] RDMA: Replace memset with = {} pattern for ib_respond_udata()
Date: Wed, 13 May 2026 20:59:15 +0000 [thread overview]
Message-ID: <20260513205916.926F0C19425@smtp.kernel.org> (raw)
In-Reply-To: <10-v3-4effdebad75a+e1-rdma_udata_rep_jgg@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removal of `memset` in `qedr_copy_qp_uresp` introduces a kernel stack information leak to user-space due to uninitialized struct padding bytes.
--
commit 5d1e218c098790b95c443563dc2cc0974927c81a
Author: Jason Gunthorpe <jgg@ziepe.ca>
RDMA: Replace memset with = {} pattern for ib_respond_udata()
This patch replaces multiple instances of memset() used for zeroing
response structures with the aggregate initialization pattern = {}. It
also removes a redundant memset() in qedr_copy_qp_uresp().
> diff --git a/drivers/infiniband/hw/qedr/verbs.c b/drivers/infiniband/hw/qedr/verbs.c
> index 79190c5b8b50b..1af908275ca72 100644
> --- a/drivers/infiniband/hw/qedr/verbs.c
> +++ b/drivers/infiniband/hw/qedr/verbs.c
[ ... ]
> @@ -1283,8 +1281,6 @@ static int qedr_copy_qp_uresp(struct qedr_dev *dev,
> struct qedr_qp *qp, struct ib_udata *udata,
> struct qedr_create_qp_uresp *uresp)
> {
> - memset(uresp, 0, sizeof(*uresp));
> -
> if (qedr_qp_has_sq(qp))
> qedr_copy_sq_uresp(dev, uresp, qp);
Does this change expose kernel stack memory to userspace?
The commit message notes that qedr_copy_qp_uresp() is already called with
zeroed memory. If the caller is using aggregate initialization (= {}) on
the stack, this may not completely zero the memory.
Unlike memset(), the C standard does not guarantee that = {} will zero out
implicit padding bytes. The compiler might optimize the initialization by
only zeroing the named fields.
Looking at struct qedr_create_qp_uresp, there appear to be 4 bytes of
implicit padding due to field alignment:
include/uapi/rdma/qedr-abi.h:struct qedr_create_qp_uresp {
__u32 qp_id;
__u32 atomic_supported;
/* SQ */
__u32 sq_db_offset;
__u16 sq_icid;
<--- 2 bytes of padding here to align rq_db_offset
/* RQ */
__u32 rq_db_offset;
__u16 rq_icid;
<--- 2 bytes of padding here to align rq_db2_offset
__u32 rq_db2_offset;
__u32 reserved;
...
Since ib_respond_udata() copies sizeof(*uresp) to userspace, could the
removal of memset() cause residual stack data in these padding holes to be
leaked?
--
Sashiko AI review · https://sashiko.dev/#/patchset/0-v3-4effdebad75a+e1-rdma_udata_rep_jgg@nvidia.com?part=10
next prev parent reply other threads:[~2026-05-13 20:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 0:09 [PATCH v3 00/10] Convert all drivers to the new udata response flow Jason Gunthorpe
2026-05-12 0:09 ` [PATCH v3 01/10] RDMA: Use ib_is_udata_in_empty() for places calling ib_is_udata_cleared() Jason Gunthorpe
2026-05-12 0:09 ` [PATCH v3 02/10] IB/rdmavt: Don't abuse udata and ib_respond_udata() Jason Gunthorpe
2026-05-13 3:12 ` sashiko-bot
2026-05-13 11:38 ` Jason Gunthorpe
2026-05-13 13:45 ` Dennis Dalessandro
2026-05-12 0:09 ` [PATCH v3 03/10] RDMA: Convert drivers using min to ib_respond_udata() Jason Gunthorpe
2026-05-12 0:09 ` [PATCH v3 04/10] RDMA: Convert drivers using sizeof() " Jason Gunthorpe
2026-05-12 0:09 ` [PATCH v3 05/10] RDMA/cxgb4: Convert " Jason Gunthorpe
2026-05-12 0:09 ` [PATCH v3 06/10] RDMA/qedr: Replace qedr_ib_copy_to_udata() with ib_respond_udata() Jason Gunthorpe
2026-05-13 19:07 ` sashiko-bot
2026-05-12 0:09 ` [PATCH v3 07/10] RDMA/mlx: Replace response_len " Jason Gunthorpe
2026-05-12 0:09 ` [PATCH v3 08/10] RDMA: Use proper driver data response structs instead of open coding Jason Gunthorpe
2026-05-12 0:09 ` [PATCH v3 09/10] RDMA: Add missed = {} initialization to uresp structs Jason Gunthorpe
2026-05-12 0:09 ` [PATCH v3 10/10] RDMA: Replace memset with = {} pattern for ib_respond_udata() Jason Gunthorpe
2026-05-13 20:59 ` sashiko-bot [this message]
2026-05-13 23:23 ` Jason Gunthorpe
2026-05-14 8:22 ` [PATCH v3 00/10] Convert all drivers to the new udata response flow 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=20260513205916.926F0C19425@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=jgg@nvidia.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=sashiko-reviews@lists.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.