mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
To: "idryomov@gmail.com" <idryomov@gmail.com>,
	Xiubo Li <xiubli@redhat.com>,
	"islituo@gmail.com" <islituo@gmail.com>
Cc: "ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re:  [PATCH] net: ceph: Fix a possible null-pointer dereference in decode_choose_args()
Date: Thu, 18 Dec 2025 19:11:31 +0000	[thread overview]
Message-ID: <f9f2ef979100a8809d7e3ac6106362f7a273e1e0.camel@ibm.com> (raw)
In-Reply-To: <20251218075603.8797-1-islituo@gmail.com>

On Thu, 2025-12-18 at 15:56 +0800, Tuo Li wrote:
> In decode_choose_args(), arg_map->size is updated before memory is
> allocated for arg_map->args using kcalloc(). If kcalloc() fails, execution
> jumps to the fail label, where free_choose_arg_map() is called to release
> resources. However, free_choose_arg_map() unconditionally iterates over
> arg_map->args using arg_map->size, which can lead to a NULL pointer
> dereference when arg_map->args is NULL:
> 
>   for (i = 0; i < arg_map->size; i++) {
>     struct crush_choose_arg *arg = &arg_map->args[i];
> 
> 	for (j = 0; j < arg->weight_set_size; j++)
> 	  kfree(arg->weight_set[j].weights);
>     kfree(arg->weight_set);
> 	kfree(arg->ids);
>   }
> 
> To prevent this potential NULL pointer dereference, move the assignment to
> arg_map->size to after successful allocation of arg_map->args. This ensures
> that when allocation fails, arg_map->size remains zero and the loop in 
> free_choose_arg_map() is not executed.
> 
> Signed-off-by: Tuo Li <islituo@gmail.com>
> ---
>  net/ceph/osdmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c
> index d245fa508e1c..f67a87b3a7c8 100644
> --- a/net/ceph/osdmap.c
> +++ b/net/ceph/osdmap.c
> @@ -363,13 +363,13 @@ static int decode_choose_args(void **p, void *end, struct crush_map *c)
>  
>  		ceph_decode_64_safe(p, end, arg_map->choose_args_index,
>  				    e_inval);
> -		arg_map->size = c->max_buckets;

The arg_map->size defines the size of memory allocation. If you remove the
assignment here, then which size kcalloc() will allocate. I assume we could have
two possible scenarios here: (1) arg_map->size is equal to zero -> no allocation
happens, (2) arg_map->size contains garbage value -> any failure could happen.

Have you reproduced the declared issue that you are trying to fix? Are you sure
that your patch can fix the issue? Have you tested your patch at all?

Thanks,
Slava.

>  		arg_map->args = kcalloc(arg_map->size, sizeof(*arg_map->args),
>  					GFP_NOIO);
>  		if (!arg_map->args) {
>  			ret = -ENOMEM;
>  			goto fail;
>  		}
> +		arg_map->size = c->max_buckets;
>  
>  		ceph_decode_32_safe(p, end, num_buckets, e_inval);
>  		while (num_buckets--) {

  reply	other threads:[~2025-12-18 19:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-18  7:56 Tuo Li
2025-12-18 19:11 ` Viacheslav Dubeyko [this message]
2025-12-19  6:26   ` Tuo Li
2025-12-19 13:35     ` Ilya Dryomov
2025-12-20  6:24       ` Tuo Li

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=f9f2ef979100a8809d7e3ac6106362f7a273e1e0.camel@ibm.com \
    --to=slava.dubeyko@ibm.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=idryomov@gmail.com \
    --cc=islituo@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xiubli@redhat.com \
    /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

all inboxes | Powered by JetHome®