Re: [PATCH rdma-next v9 03/16] RDMA/core: Introduce generic buffer descriptor infrastructure for umem

[Jiri Pirko <jiri@resnulli.us>]

Fri, May 29, 2026 at 03:42:59PM +0200, jiri@resnulli.us wrote:

[..]

>+struct ib_umem *ib_umem_get_desc(struct ib_device *device,
>+				 const struct ib_uverbs_buffer_desc *desc,
>+				 int access)
>+{
>+	struct ib_umem_dmabuf *umem_dmabuf;
>+
>+	if (desc->flags & ~IB_UVERBS_BUFFER_DESC_FLAGS_KNOWN_MASK)
>+		return ERR_PTR(-EINVAL);
>+
>+	if (overflows_type(desc->addr, unsigned long) ||
>+	    overflows_type(desc->length, size_t))
>+		return ERR_PTR(-EOVERFLOW);

Sashiko says:
Does this validation evaluate potentially uninitialized garbage data?
If a user passes an invalid, unsupported, or future buffer type, the
addr and length fields might be uninitialized garbage. Evaluating them
before validating desc->type might cause the kernel to return -EOVERFLOW
instead of -EINVAL, which can break userspace feature probing based on
error codes.
Should this validation be moved inside the cases of the switch statement
that actually use these fields?


Probably this may be hit in case some other type does not use addr
and length (how likely is that?).

I would sanitize it as a follow-up if nobody is oppose that.

[..]