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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox