All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <hca@linux.ibm.com>
To: Bui Quang Minh <minhquangbui99@gmail.com>
Cc: Javed Hasan <jhasan@marvell.com>,
	linux-kernel@vger.kernel.org,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Eric Dumazet <edumazet@google.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Vineeth Vijayan <vneethv@linux.ibm.com>,
	linux-scsi@vger.kernel.org,
	Saurav Kashyap <saurav.kashyap@cavium.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	linux-s390@vger.kernel.org,
	Sudarsana Kalluru <sudarsana.kalluru@qlogic.com>,
	intel-wired-lan@lists.osuosl.org,
	Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Arun Easi <arun.easi@cavium.com>,
	Fabian Frederick <fabf@skynet.be>,
	Krishna Gudipati <kgudipat@brocade.com>,
	Manish Rangankar <manish.rangankar@cavium.com>,
	Jens Axboe <axboe@kernel.dk>,
	Nilesh Javali <nilesh.javali@cavium.com>,
	GR-Linux-NIC-Dev@marvell.com,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Saurav Kashyap <skashyap@marvell.com>,
	Rasesh Mody <rmody@marvell.com>,
	netdev@vger.kernel.org,
	Anil Gurumurthy <anil.gurumurthy@qlogic.com>,
	Peter Oberparleiter <oberpar@linux.ibm.com>,
	"David S. Miller" <davem@davemloft.net>,
	GR-QLogic-Storage-Upstream@marvell.com,
	Sven Schnelle <svens@linux.ibm.com>,
	Sudarsana Kalluru <skalluru@marvell.com>
Subject: Re: [Intel-wired-lan] [PATCH 5/5] drivers/s390/cio: ensure the copied buf is NULL terminated
Date: Tue, 23 Apr 2024 08:50:52 +0200	[thread overview]
Message-ID: <20240423065052.10211-C-hca@linux.ibm.com> (raw)
In-Reply-To: <20240422-fix-oob-read-v1-5-e02854c30174@gmail.com>

On Mon, Apr 22, 2024 at 11:41:40PM +0700, Bui Quang Minh wrote:
> Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
> userspace to that buffer. Later, we use scanf on this buffer but we don't
> ensure that the string is terminated inside the buffer, this can lead to
> OOB read when using scanf. Fix this issue by allocating 1 more byte to at
> the end of buffer and write NULL terminator to the end of buffer after
> userspace copying.
> 
> Fixes: a4f17cc72671 ("s390/cio: add CRW inject functionality")
> Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
> ---
>  drivers/s390/cio/cio_inject.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/s390/cio/cio_inject.c b/drivers/s390/cio/cio_inject.c
> index 8613fa937237..9b69fbf49f60 100644
> --- a/drivers/s390/cio/cio_inject.c
> +++ b/drivers/s390/cio/cio_inject.c
> @@ -95,10 +95,11 @@ static ssize_t crw_inject_write(struct file *file, const char __user *buf,
>  		return -EINVAL;
>  	}
>  
> -	buffer = vmemdup_user(buf, lbuf);
> +	buffer = vmemdup_user(buf, lbuf + 1);
>  	if (IS_ERR(buffer))
>  		return -ENOMEM;
>  
> +	buffer[lbuf] = '\0';

This would read one byte too much from user space, and could potentially
fault.

Why isn't this simply memdup_user_nul() like all others, which would do the
right thing?

WARNING: multiple messages have this Message-ID (diff)
From: Heiko Carstens <hca@linux.ibm.com>
To: Bui Quang Minh <minhquangbui99@gmail.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com>,
	Rasesh Mody <rmody@marvell.com>,
	Sudarsana Kalluru <skalluru@marvell.com>,
	GR-Linux-NIC-Dev@marvell.com,
	Krishna Gudipati <kgudipat@brocade.com>,
	Anil Gurumurthy <anil.gurumurthy@qlogic.com>,
	Sudarsana Kalluru <sudarsana.kalluru@qlogic.com>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Fabian Frederick <fabf@skynet.be>,
	Saurav Kashyap <skashyap@marvell.com>,
	Javed Hasan <jhasan@marvell.com>,
	GR-QLogic-Storage-Upstream@marvell.com,
	Nilesh Javali <nilesh.javali@cavium.com>,
	Arun Easi <arun.easi@cavium.com>,
	Manish Rangankar <manish.rangankar@cavium.com>,
	Vineeth Vijayan <vneethv@linux.ibm.com>,
	Peter Oberparleiter <oberpar@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	Saurav Kashyap <saurav.kashyap@cavium.com>,
	linux-s390@vger.kernel.org, Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH 5/5] drivers/s390/cio: ensure the copied buf is NULL terminated
Date: Tue, 23 Apr 2024 08:50:52 +0200	[thread overview]
Message-ID: <20240423065052.10211-C-hca@linux.ibm.com> (raw)
In-Reply-To: <20240422-fix-oob-read-v1-5-e02854c30174@gmail.com>

On Mon, Apr 22, 2024 at 11:41:40PM +0700, Bui Quang Minh wrote:
> Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
> userspace to that buffer. Later, we use scanf on this buffer but we don't
> ensure that the string is terminated inside the buffer, this can lead to
> OOB read when using scanf. Fix this issue by allocating 1 more byte to at
> the end of buffer and write NULL terminator to the end of buffer after
> userspace copying.
> 
> Fixes: a4f17cc72671 ("s390/cio: add CRW inject functionality")
> Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com>
> ---
>  drivers/s390/cio/cio_inject.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/s390/cio/cio_inject.c b/drivers/s390/cio/cio_inject.c
> index 8613fa937237..9b69fbf49f60 100644
> --- a/drivers/s390/cio/cio_inject.c
> +++ b/drivers/s390/cio/cio_inject.c
> @@ -95,10 +95,11 @@ static ssize_t crw_inject_write(struct file *file, const char __user *buf,
>  		return -EINVAL;
>  	}
>  
> -	buffer = vmemdup_user(buf, lbuf);
> +	buffer = vmemdup_user(buf, lbuf + 1);
>  	if (IS_ERR(buffer))
>  		return -ENOMEM;
>  
> +	buffer[lbuf] = '\0';

This would read one byte too much from user space, and could potentially
fault.

Why isn't this simply memdup_user_nul() like all others, which would do the
right thing?

  reply	other threads:[~2024-04-23 15:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-22 16:41 [Intel-wired-lan] [PATCH 0/5] Ensure the copied buf is NULL terminated Bui Quang Minh
2024-04-22 16:41 ` Bui Quang Minh
2024-04-22 16:41 ` [Intel-wired-lan] [PATCH 1/5] drivers/net/ethernet/intel-ice: ensure " Bui Quang Minh
2024-04-22 16:41   ` Bui Quang Minh
2024-04-23  9:20   ` [Intel-wired-lan] " Przemek Kitszel
2024-04-23  9:20     ` Przemek Kitszel
2024-04-22 16:41 ` [Intel-wired-lan] [PATCH 2/5] drivers/net/brocade-bnad: " Bui Quang Minh
2024-04-22 16:41   ` Bui Quang Minh
2024-04-22 16:41 ` [Intel-wired-lan] [PATCH 3/5] drivers/scsi/bfa/bfad: " Bui Quang Minh
2024-04-22 16:41   ` Bui Quang Minh
2024-04-22 16:41 ` [Intel-wired-lan] [PATCH 4/5] drivers/scsi/qedf: " Bui Quang Minh
2024-04-22 16:41   ` Bui Quang Minh
2024-04-22 16:41 ` [Intel-wired-lan] [PATCH 5/5] drivers/s390/cio: " Bui Quang Minh
2024-04-22 16:41   ` Bui Quang Minh
2024-04-23  6:50   ` Heiko Carstens [this message]
2024-04-23  6:50     ` Heiko Carstens
2024-04-23 14:46     ` [Intel-wired-lan] " Bui Quang Minh
2024-04-23 14:46       ` Bui Quang Minh
2024-04-24 11:55       ` [Intel-wired-lan] " Heiko Carstens
2024-04-24 11:55         ` Heiko Carstens
2024-04-23 11:10 ` [Intel-wired-lan] [PATCH 0/5] Ensure " Marcin Szycik
2024-04-23 11:25   ` Przemek Kitszel
2024-04-23 11:25     ` Przemek Kitszel

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=20240423065052.10211-C-hca@linux.ibm.com \
    --to=hca@linux.ibm.com \
    --cc=GR-Linux-NIC-Dev@marvell.com \
    --cc=GR-QLogic-Storage-Upstream@marvell.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=agordeev@linux.ibm.com \
    --cc=anil.gurumurthy@qlogic.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=arun.easi@cavium.com \
    --cc=axboe@kernel.dk \
    --cc=borntraeger@linux.ibm.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=fabf@skynet.be \
    --cc=gor@linux.ibm.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jhasan@marvell.com \
    --cc=kgudipat@brocade.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=manish.rangankar@cavium.com \
    --cc=martin.petersen@oracle.com \
    --cc=minhquangbui99@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nilesh.javali@cavium.com \
    --cc=oberpar@linux.ibm.com \
    --cc=pabeni@redhat.com \
    --cc=paul.m.stillwell.jr@intel.com \
    --cc=rmody@marvell.com \
    --cc=saurav.kashyap@cavium.com \
    --cc=skalluru@marvell.com \
    --cc=skashyap@marvell.com \
    --cc=sudarsana.kalluru@qlogic.com \
    --cc=svens@linux.ibm.com \
    --cc=vneethv@linux.ibm.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.