All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Xiao Ni <xni@redhat.com>
Cc: blazej.kucman@intel.com, linux-raid@vger.kernel.org
Subject: Re: [PATCH 1/1] mdadm/platform-intel: Fix buffer overflow
Date: Tue, 28 May 2024 09:09:35 +0200	[thread overview]
Message-ID: <20240528090935.00002526@linux.intel.com> (raw)
In-Reply-To: <20240528022903.20039-1-xni@redhat.com>

On Tue, 28 May 2024 10:29:03 +0800
Xiao Ni <xni@redhat.com> wrote:

> It reports buffer overflow detected when creating raid with big
> nvme devices. In my test, the size of the nvme device is 1.5T.
> It can't reproduce this with nvme device which size is smaller
> than 1T.

Hi Xiao,

Size of disks should have nothing to do with this. We are just parsing sysfs.
Weird..

> 
> In function get_nvme_multipath_dev_hw_path it allocs memory in a for
> loop and the size it allocs is big. So if the iteration number is
> large, it has a risk that the stack space is larger than the limit.
> So move the memory allocation at the biginning of the funtion.

I would expect that memory is deallocated after each loop but the fix
is correct and I'm willing to take this because obviously it is a fix for
something.

I don't understand the problem but I trust you. Maybe varied size stack array is
a problem?

Probably, enough would be to just replace [strlen(dev_path) +
strlen(ent->d_name) + 1] by [PATH_MAX] but I'm quite confused why it is an
issue at all.

LGTM. Please fix typos raised by Paul and I will merge it.

Thanks,
Mariusz

> 
> Fixes: d835518b6b53 ('imsm: nvme multipath support')
> Reported-by: Guang Wu <guazhang@redhat.com>
> Signed-off-by: Xiao Ni <xni@redhat.com>
> ---
>  platform-intel.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/platform-intel.c b/platform-intel.c
> index 15a9fa5a..0732af2b 100644
> --- a/platform-intel.c
> +++ b/platform-intel.c
> @@ -898,6 +898,7 @@ char *get_nvme_multipath_dev_hw_path(const char *dev_path)
>  	DIR *dir;
>  	struct dirent *ent;
>  	char *rp = NULL;
> +	char buf[PATH_MAX];
>  
>  	if (strncmp(dev_path, NVME_SUBSYS_PATH, strlen(NVME_SUBSYS_PATH)) !=
> 0) return NULL;
> @@ -907,14 +908,13 @@ char *get_nvme_multipath_dev_hw_path(const char
> *dev_path) return NULL;
>  
>  	for (ent = readdir(dir); ent; ent = readdir(dir)) {
> -		char buf[strlen(dev_path) + strlen(ent->d_name) + 1];
>  
>  		/* Check if dir is a controller, ignore namespaces*/
>  		if (!(strncmp(ent->d_name, "nvme", 4) == 0) ||
>  		    (strrchr(ent->d_name, 'n') != &ent->d_name[0]))
>  			continue;
>  
> -		sprintf(buf, "%s/%s", dev_path, ent->d_name);
> +		snprintf(buf, PATH_MAX, "%s/%s", dev_path, ent->d_name);

>  		rp = realpath(buf, NULL);
>  		break;
>  	}


  parent reply	other threads:[~2024-05-28  7:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-28  2:29 [PATCH 1/1] mdadm/platform-intel: Fix buffer overflow Xiao Ni
2024-05-28  5:09 ` Paul Menzel
2024-05-28  6:58   ` Xiao Ni
2024-05-28  7:09 ` Mariusz Tkaczyk [this message]
2024-05-28  7:41   ` Xiao Ni
2024-05-28  7:57     ` Xiao Ni

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=20240528090935.00002526@linux.intel.com \
    --to=mariusz.tkaczyk@linux.intel.com \
    --cc=blazej.kucman@intel.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=xni@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 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.