[PATCH] rdma: infiniband: Added __alloc_cq request value Return value non-zero value determination

[PATCH] rdma: infiniband: Added __alloc_cq request value Return value non-zero value determination

[luoqing]

From: luoqing <luoqing@kylinos.cn>

Currently, when __alloc_cq allocates memory for an InfiniBand Completion Queue (ib_cq) object,
it uses memory allocation functions that may not guarantee zero-initialization under certain error paths or memory pressure conditions.
If the allocated ib_cq object contains non-zero garbage data due to incomplete initialization,
the function may return a non-NULL pointer even though the object is not in a valid state. This can lead to undefined behavior,
memory corruption, and potential kernel crashes when the driver subsequently accesses uninitialized fields.

This patch adds explicit validation to ensure that the allocated ib_cq object is properly zeroed before being considered valid.
If the object fails the zero-check (i.e., contains non-zero bytes beyond expected initialized fields),
the function returns an error code (e.g., -ENOMEM or -EINVAL), logs a warning message, and prevents further usage of the corrupted CQ.

Signed-off-by: luoqing <luoqing@kylinos.cn>
---
 drivers/infiniband/core/cq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/cq.c b/drivers/infiniband/core/cq.c
index 3d7b6cddd131..756bc33c850d 100644
--- a/drivers/infiniband/core/cq.c
+++ b/drivers/infiniband/core/cq.c
@@ -224,7 +224,7 @@ struct ib_cq *__ib_alloc_cq(struct ib_device *dev, void *private, int nr_cqe,
 		return ERR_PTR(-EINVAL);
 
 	cq = rdma_zalloc_drv_obj(dev, ib_cq);
-	if (!cq)
+	if (unlikely(ZERO_OR_NULL_PTR(cq)))
 		return ERR_PTR(ret);
 
 	cq->device = dev;
-- 
2.25.1

Re: [PATCH] rdma: infiniband: Added __alloc_cq request value Return value non-zero value determination

[Jason Gunthorpe]

On Tue, May 26, 2026 at 05:18:16PM +0800, luoqing wrote:
> From: luoqing <luoqing@kylinos.cn>
> 
> Currently, when __alloc_cq allocates memory for an InfiniBand Completion Queue (ib_cq) object,
> it uses memory allocation functions that may not guarantee zero-initialization under certain error paths or memory pressure conditions.
> If the allocated ib_cq object contains non-zero garbage data due to incomplete initialization,
> the function may return a non-NULL pointer even though the object is not in a valid state. This can lead to undefined behavior,
> memory corruption, and potential kernel crashes when the driver subsequently accesses uninitialized fields.
> 
> This patch adds explicit validation to ensure that the allocated ib_cq object is properly zeroed before being considered valid.
> If the object fails the zero-check (i.e., contains non-zero bytes beyond expected initialized fields),
> the function returns an error code (e.g., -ENOMEM or -EINVAL), logs a warning message, and prevents further usage of the corrupted CQ.
> 
> Signed-off-by: luoqing <luoqing@kylinos.cn>
> ---
>  drivers/infiniband/core/cq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/infiniband/core/cq.c b/drivers/infiniband/core/cq.c
> index 3d7b6cddd131..756bc33c850d 100644
> --- a/drivers/infiniband/core/cq.c
> +++ b/drivers/infiniband/core/cq.c
> @@ -224,7 +224,7 @@ struct ib_cq *__ib_alloc_cq(struct ib_device *dev, void *private, int nr_cqe,
>  		return ERR_PTR(-EINVAL);
>  
>  	cq = rdma_zalloc_drv_obj(dev, ib_cq);
> -	if (!cq)
> +	if (unlikely(ZERO_OR_NULL_PTR(cq)))
>  		return ERR_PTR(ret);

Wow, this entire report is unintelligible.

ZERO_OR_NULL_PTR() has nothing to do with the memory contents.

Jason

Re: [PATCH] rdma: infiniband: Added __alloc_cq request value Return value non-zero value determination

[luoqing]

On Tue, May 26, 2026 at 09:23:29AM -0300, Jason Gunthorpe wrote:
> On Tue, May 26, 2026 at 05:18:16PM +0800, luoqing wrote:
> > From: luoqing <luoqing@kylinos.cn>
> > 
> > Currently, when __alloc_cq allocates memory for an InfiniBand Completion Queue (ib_cq) object,
> > it uses memory allocation functions that may not guarantee zero-initialization under certain error paths or memory pressure conditions.
> > If the allocated ib_cq object contains non-zero garbage data due to incomplete initialization,
> > the function may return a non-NULL pointer even though the object is not in a valid state. This can lead to undefined behavior,
> > memory corruption, and potential kernel crashes when the driver subsequently accesses uninitialized fields.
> > 
> > This patch adds explicit validation to ensure that the allocated ib_cq object is properly zeroed before being considered valid.
> > If the object fails the zero-check (i.e., contains non-zero bytes beyond expected initialized fields),
> > the function returns an error code (e.g., -ENOMEM or -EINVAL), logs a warning message, and prevents further usage of the corrupted CQ.
> > 
> > Signed-off-by: luoqing <luoqing@kylinos.cn>
> > ---
> >  drivers/infiniband/core/cq.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/infiniband/core/cq.c b/drivers/infiniband/core/cq.c
> > index 3d7b6cddd131..756bc33c850d 100644
> > --- a/drivers/infiniband/core/cq.c
> > +++ b/drivers/infiniband/core/cq.c
> > @@ -224,7 +224,7 @@ struct ib_cq *__ib_alloc_cq(struct ib_device *dev, void *private, int nr_cqe,
> >  		return ERR_PTR(-EINVAL);
> >  
> >  	cq = rdma_zalloc_drv_obj(dev, ib_cq);
> > -	if (!cq)
> > +	if (unlikely(ZERO_OR_NULL_PTR(cq)))
> >  		return ERR_PTR(ret);
> 
> Wow, this entire report is unintelligible.
> 
> ZERO_OR_NULL_PTR() has nothing to do with the memory contents.
> 
> Jason

Hi Jason,

Thank you for your quick response, and sorry for the confusion in my previous explanation.
Let me try to restate the issue more clearly.

In __ib_alloc_cq(), we allocate an ib_cq object using rdma_zalloc_drv_obj(), which is supposed to return zero-initialized memory.
However, when rdma_zalloc_drv_obj() returns ZERO_SIZE_PTR ((void *)16), the current code only checks !cq and treats it as a successful allocation (non-NULL).
This happens when the allocation size is zero — a condition that might not be properly validated in some driver registration paths.

If a driver inadvertently registers with an incomplete or zero-sized object requirement, cq becomes ZERO_SIZE_PTR, not NULL.
Later, when the kernel tries to use this CQ (e.g., initializing fields), it may access invalid memory, leading to a kernel crash or memory corruption.

Although this is fundamentally a driver registration issue (drivers should specify correct sizes), adding an extra defensive check in __ib_alloc_cq() — like ZERO_OR_NULL_PTR(cq) — would:

Prevent crashes caused by incomplete driver initialization

Add no meaningful overhead

Improve kernel robustness, especially for out-of-tree or legacy drivers

I understand that ZERO_OR_NULL_PTR is not about memory contents, but about the special zero-size pointer case.
In this context, it acts as a safeguard against a specific class of programming error.

Would you accept a patch that replaces !cq with ZERO_OR_NULL_PTR(cq) (or an explicit if (IS_ERR_OR_NULL(cq))) to cover this corner case?

Thanks for your patience and guidance.

Best regards,

luoqing

Re: [PATCH] rdma: infiniband: Added __alloc_cq request value Return value non-zero value determination

[Jason Gunthorpe]

On Thu, May 28, 2026 at 02:54:35PM +0800, luoqing wrote:

> Although this is fundamentally a driver registration issue (drivers
> should specify correct sizes), adding an extra defensive check in
> __ib_alloc_cq() — like ZERO_OR_NULL_PTR(cq) — would:

Then check the driver specified the right sizes when it registered.

But I don't see much value in this avenue, drivers won't work at all
if they are so severely buggy.

This entire conversation is pure AI slop, please stop.

Jason

Re: [PATCH] rdma: infiniband: Added __alloc_cq request value Return value non-zero value determination

[Jason Gunthorpe]

On Mon, Apr 07, 2025 at 05:33:41PM +0800, luoqing wrote:
> From: luoqing <luoqing@kylinos.cn>
> 
> When the kernel allocates memory for completion queue object ib_cq on the specified
> InfiniBand device dev and ensures that the allocated memory is cleared to zero,
> if the ib_cq object is not initialized to 0, a non-null value is still returned,
> and the kernel should exit and give a warning.
> Avoid kernel crash when this memory is initialized.

?? This doesn't make any sense.

> ib_mad_init_device
> 	-->ib_mad_port_open
> 		-->__ib_alloc_cq
> 			-->rdma_zalloc_drv_obj(dev, ib_cq);

rdma_zalloc_drv_obj() must return memory that is validly castable to
the struct ib_cq.

> When ib_cq is zero, the return value of cq is ZERO_SIZE_PTR ((void *)16) and is not non-null
> cq = rdma_zalloc_drv_obj(dev, ib_cq);

It looks to me like the driver returned the wrong size for the ib_cq
in the ops->size_ib_cq. It is not allowed to be 0 if the driver is
supporting cq.

Arguably we should check that the size_* pointers have the requirement
minimum size when registering the driver.

Allocation time is too late.

Jason

[PATCH] rdma: infiniband: Added __alloc_cq request value Return value non-zero value determination

[luoqing]

From: luoqing <luoqing@kylinos.cn>

When the kernel allocates memory for completion queue object ib_cq on the specified
InfiniBand device dev and ensures that the allocated memory is cleared to zero,
if the ib_cq object is not initialized to 0, a non-null value is still returned,
and the kernel should exit and give a warning.
Avoid kernel crash when this memory is initialized.

ib_mad_init_device
	-->ib_mad_port_open
		-->__ib_alloc_cq
			-->rdma_zalloc_drv_obj(dev, ib_cq);

 #8 [ffff80211b3c7430] do_mem_abort at ffff4bedae5912c4
 #9 [ffff80211b3c7610] el1_ia at ffff4bedae592f8c
     PC: ffff4bed866f5aac  [__ib_alloc_cq+100]
     LR: ffff4bed866f5a98  [__ib_alloc_cq+80]
     SP: ffff80211b3c7620  PSTATE: 60400009
    X29: ffff80211b3c7620  X28: ffff4bedae5c7a70  X27: 0000000000000000
    X26: ffff4bed86737680  X25: ffff8020b62f4000  X24: 0000000000000002
    X23: 0000000000000280  X22: ffff4bedaf8a4d28  X21: ffff8020ca8d0000
    X20: 0000000000000000  X19: 0000000000000010  X18: ffff80211b3c7410
    X17: 00000000172acefd  X16: ffff4bedae8603e8  X15: 00000000b19d2ea3
    X14: 000000000950e09b  X13: 000000009bd4e304  X12: 00000000f81e149c
    X11: 0000000096b29e56  X10: 0000000000000f70   X9: ffff80211b3c7360
     X8: ffff80211b4e9350   X7: 0000000000000000   X6: ffff4bedaf2d08f0
     X5: ffff4bed86737680   X4: 0000000000000002   X3: 0000000000000000
     X2: 0000000000000280   X1: 00000000006080c0   X0: 0000000000000010
     X2: 0000000000000280   X1: 00000000006080c0   X0: 0000000000000010
 #10 [ffff80211b3c7620] __ib_alloc_cq at ffff4bed866f5aa8 [ib_core]
 #11 [ffff80211b3c7690] ib_mad_port_open at ffff4bed86711338 [ib_core]
 #12 [ffff80211b3c7710] ib_mad_init_device at ffff4bed867118d0 [ib_core]
 #13 [ffff80211b3c7760] add_client_context at ffff4bed866fca40 [ib_core]
 #14 [ffff80211b3c77a0] enable_device_and_get at ffff4bed866fcb90 [ib_core]
 #15 [ffff80211b3c77f0] ib_register_device at ffff4bed866fd750 [ib_core]
 #16 [ffff80211b3c78b0] irdma_ib_register_device at ffff4bed81ea3d20 [irdma]
 #17 [ffff80211b3c7920] irdma_probe at ffff4bed81e7130c [irdma]

When ib_cq is zero, the return value of cq is ZERO_SIZE_PTR ((void *)16) and is not non-null
cq = rdma_zalloc_drv_obj(dev, ib_cq);

Signed-off-by: luoqing <luoqing@kylinos.cn>
---
 drivers/infiniband/core/cq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/cq.c b/drivers/infiniband/core/cq.c
index a70876a0a231..90ea9fc99fb7 100644
--- a/drivers/infiniband/core/cq.c
+++ b/drivers/infiniband/core/cq.c
@@ -221,7 +221,7 @@ struct ib_cq *__ib_alloc_cq(struct ib_device *dev, void *private, int nr_cqe,
 	int ret = -ENOMEM;
 
 	cq = rdma_zalloc_drv_obj(dev, ib_cq);
-	if (!cq)
+	if (unlikely(ZERO_OR_NULL_PTR(cq)))
 		return ERR_PTR(ret);
 
 	cq->device = dev;
-- 
2.27.0