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: Wed, 24 Apr 2024 13:55:57 +0200 [thread overview]
Message-ID: <20240424115557.26193-A-hca@linux.ibm.com> (raw)
In-Reply-To: <e4f5cbd0-c803-4c3c-9703-f52e56864106@gmail.com>
On Tue, Apr 23, 2024 at 09:46:35PM +0700, Bui Quang Minh wrote:
> > > - 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?
...
> For this case, as the original code uses vmemdup_user, which internally uses
> kvmalloc not kmalloc, so I try to keep the original behavior. And
> vmemdup_user does not have the counterpart vmemdup_user_nul. I can
> kvmalloc(lbuf + 1), then copy_to_user(lbuf) and set buffer[lbuf] = '\0' or
> do you think I should create vmemdup_user_nul?
There is no need for vmalloc() instead of kmalloc() for this particular
case. The input string is supposed to be rather short (see the sscanf()
call). So converting to memdup_user_nul() is sufficient and solves the
potential problem.
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: Wed, 24 Apr 2024 13:55:57 +0200 [thread overview]
Message-ID: <20240424115557.26193-A-hca@linux.ibm.com> (raw)
In-Reply-To: <e4f5cbd0-c803-4c3c-9703-f52e56864106@gmail.com>
On Tue, Apr 23, 2024 at 09:46:35PM +0700, Bui Quang Minh wrote:
> > > - 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?
...
> For this case, as the original code uses vmemdup_user, which internally uses
> kvmalloc not kmalloc, so I try to keep the original behavior. And
> vmemdup_user does not have the counterpart vmemdup_user_nul. I can
> kvmalloc(lbuf + 1), then copy_to_user(lbuf) and set buffer[lbuf] = '\0' or
> do you think I should create vmemdup_user_nul?
There is no need for vmalloc() instead of kmalloc() for this particular
case. The input string is supposed to be rather short (see the sscanf()
call). So converting to memdup_user_nul() is sufficient and solves the
potential problem.
next prev parent reply other threads:[~2024-04-24 15:19 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 ` [Intel-wired-lan] " Heiko Carstens
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 ` Heiko Carstens [this message]
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=20240424115557.26193-A-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.