[186/190] Revert "virt: vbox: Only copy_from_user the request-header once"
diff mbox series

Message ID 20210421130105.1226686-187-gregkh@linuxfoundation.org
State New, archived
Headers show
Series
  • Revertion of all of the umn.edu commits
Related show

Commit Message

Greg KH April 21, 2021, 1:01 p.m. UTC
This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.

Commits from @umn.edu addresses have been found to be submitted in "bad
faith" to try to test the kernel community's ability to review "known
malicious" changes.  The result of these submissions can be found in a
paper published at the 42nd IEEE Symposium on Security and Privacy
entitled, "Open Source Insecurity: Stealthily Introducing
Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
of Minnesota) and Kangjie Lu (University of Minnesota).

Because of this, all submissions from this group must be reverted from
the kernel tree and will need to be re-reviewed again to determine if
they actually are a valid fix.  Until that work is complete, remove this
change to ensure that no problems are being introduced into the
codebase.

Cc: Wenwen Wang <wang6495@umn.edu>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/virt/vboxguest/vboxguest_linux.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

Comments

Tavis Ormandy April 21, 2021, 3:14 p.m. UTC | #1
On 2021-04-21, Greg Kroah-Hartman wrote:
> This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
>
> -	*((struct vbg_ioctl_hdr *)buf) = hdr;
> -	if (copy_from_user(buf + sizeof(hdr), (void *)arg + sizeof(hdr),
> -			   hdr.size_in - sizeof(hdr))) {
> +	if (copy_from_user(buf, (void *)arg, hdr.size_in)) {
>  		ret = -EFAULT;
>  		goto out;
>  	}

This one seems like a real bugfix, otherwise there's a double-fetch from
userspace, and a TOCTOU with the hdr fields that could cause a OOB read.

Reviewed-by: Tavis Ormandy <taviso@gmail.com>

Tavis.
Hans de Goede April 21, 2021, 4:51 p.m. UTC | #2
Hi Greg,

On 4/21/21 3:01 PM, Greg Kroah-Hartman wrote:
> This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
> 
> Commits from @umn.edu addresses have been found to be submitted in "bad
> faith" to try to test the kernel community's ability to review "known
> malicious" changes.  The result of these submissions can be found in a
> paper published at the 42nd IEEE Symposium on Security and Privacy
> entitled, "Open Source Insecurity: Stealthily Introducing
> Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> of Minnesota) and Kangjie Lu (University of Minnesota).
> 
> Because of this, all submissions from this group must be reverted from
> the kernel tree and will need to be re-reviewed again to determine if
> they actually are a valid fix.  Until that work is complete, remove this
> change to ensure that no problems are being introduced into the
> codebase.
> 
> Cc: Wenwen Wang <wang6495@umn.edu>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Ugh what a mess (the whole umn.edu thing).

I still remember reviewing this patch during its original submission
and I've reviewed it again this morning when you just send it out.

And now after letting it sit for a bit I've reviewed it a third time
and it seems to do what it says on the label / in the original commit
msg; and if fixes a real, potentially security, issue.

I'm not sure what the process is for "good" patches in the set
which you are reverting. I would prefer for this patch to be dropped
from the set of reveert. But I can also submit a revert of the revert(?)
once this set of reverts has been merged.

Regards,

Hans



> ---
>  drivers/virt/vboxguest/vboxguest_linux.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/virt/vboxguest/vboxguest_linux.c b/drivers/virt/vboxguest/vboxguest_linux.c
> index 73eb34849eab..f5cd9cfa1ef6 100644
> --- a/drivers/virt/vboxguest/vboxguest_linux.c
> +++ b/drivers/virt/vboxguest/vboxguest_linux.c
> @@ -142,9 +142,7 @@ static long vbg_misc_device_ioctl(struct file *filp, unsigned int req,
>  	if (!buf)
>  		return -ENOMEM;
>  
> -	*((struct vbg_ioctl_hdr *)buf) = hdr;
> -	if (copy_from_user(buf + sizeof(hdr), (void *)arg + sizeof(hdr),
> -			   hdr.size_in - sizeof(hdr))) {
> +	if (copy_from_user(buf, (void *)arg, hdr.size_in)) {
>  		ret = -EFAULT;
>  		goto out;
>  	}
>
Greg KH April 21, 2021, 4:59 p.m. UTC | #3
On Wed, Apr 21, 2021 at 06:51:24PM +0200, Hans de Goede wrote:
> Hi Greg,
> 
> On 4/21/21 3:01 PM, Greg Kroah-Hartman wrote:
> > This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
> > 
> > Commits from @umn.edu addresses have been found to be submitted in "bad
> > faith" to try to test the kernel community's ability to review "known
> > malicious" changes.  The result of these submissions can be found in a
> > paper published at the 42nd IEEE Symposium on Security and Privacy
> > entitled, "Open Source Insecurity: Stealthily Introducing
> > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> > of Minnesota) and Kangjie Lu (University of Minnesota).
> > 
> > Because of this, all submissions from this group must be reverted from
> > the kernel tree and will need to be re-reviewed again to determine if
> > they actually are a valid fix.  Until that work is complete, remove this
> > change to ensure that no problems are being introduced into the
> > codebase.
> > 
> > Cc: Wenwen Wang <wang6495@umn.edu>
> > Cc: Hans de Goede <hdegoede@redhat.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> Ugh what a mess (the whole umn.edu thing).
> 
> I still remember reviewing this patch during its original submission
> and I've reviewed it again this morning when you just send it out.
> 
> And now after letting it sit for a bit I've reviewed it a third time
> and it seems to do what it says on the label / in the original commit
> msg; and if fixes a real, potentially security, issue.
> 
> I'm not sure what the process is for "good" patches in the set
> which you are reverting. I would prefer for this patch to be dropped
> from the set of reveert. But I can also submit a revert of the revert(?)
> once this set of reverts has been merged.

If you have reviewed it, and think it should stay, I will drop the
revert from my patch series.  Other maintainers/reviewers have asked the
same thing for their patches, which is fine.

Anything that I do end up reverting, that was not reviewed, will be
again reviewed by me and others to determine if it is "safe" to come
back in at a later point in time.

So thanks for the review, I'll drop this one.

thanks,

greg k-h
Al Viro April 22, 2021, 1:16 a.m. UTC | #4
On Wed, Apr 21, 2021 at 03:14:29PM -0000, Tavis Ormandy wrote:
> On 2021-04-21, Greg Kroah-Hartman wrote:
> > This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
> >
> > -	*((struct vbg_ioctl_hdr *)buf) = hdr;
> > -	if (copy_from_user(buf + sizeof(hdr), (void *)arg + sizeof(hdr),
> > -			   hdr.size_in - sizeof(hdr))) {
> > +	if (copy_from_user(buf, (void *)arg, hdr.size_in)) {
> >  		ret = -EFAULT;
> >  		goto out;
> >  	}
> 
> This one seems like a real bugfix, otherwise there's a double-fetch from
> userspace, and a TOCTOU with the hdr fields that could cause a OOB read.

	ACK, except that typecasts in there are messy as hell.  But that's,
alas, consistent with the rest of the function...

	Patch itself is correct, and AFAICS Wenwen Wang <wang6495@umn.edu>
might be an innocent collateral damage from that mess - commits from that
source appear to be fairly well-written.
Greg KH April 26, 2021, 5:08 p.m. UTC | #5
On Wed, Apr 21, 2021 at 06:59:58PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 06:51:24PM +0200, Hans de Goede wrote:
> > Hi Greg,
> > 
> > On 4/21/21 3:01 PM, Greg Kroah-Hartman wrote:
> > > This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
> > > 
> > > Commits from @umn.edu addresses have been found to be submitted in "bad
> > > faith" to try to test the kernel community's ability to review "known
> > > malicious" changes.  The result of these submissions can be found in a
> > > paper published at the 42nd IEEE Symposium on Security and Privacy
> > > entitled, "Open Source Insecurity: Stealthily Introducing
> > > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> > > of Minnesota) and Kangjie Lu (University of Minnesota).
> > > 
> > > Because of this, all submissions from this group must be reverted from
> > > the kernel tree and will need to be re-reviewed again to determine if
> > > they actually are a valid fix.  Until that work is complete, remove this
> > > change to ensure that no problems are being introduced into the
> > > codebase.
> > > 
> > > Cc: Wenwen Wang <wang6495@umn.edu>
> > > Cc: Hans de Goede <hdegoede@redhat.com>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > Ugh what a mess (the whole umn.edu thing).
> > 
> > I still remember reviewing this patch during its original submission
> > and I've reviewed it again this morning when you just send it out.
> > 
> > And now after letting it sit for a bit I've reviewed it a third time
> > and it seems to do what it says on the label / in the original commit
> > msg; and if fixes a real, potentially security, issue.
> > 
> > I'm not sure what the process is for "good" patches in the set
> > which you are reverting. I would prefer for this patch to be dropped
> > from the set of reveert. But I can also submit a revert of the revert(?)
> > once this set of reverts has been merged.
> 
> If you have reviewed it, and think it should stay, I will drop the
> revert from my patch series.  Other maintainers/reviewers have asked the
> same thing for their patches, which is fine.
> 
> Anything that I do end up reverting, that was not reviewed, will be
> again reviewed by me and others to determine if it is "safe" to come
> back in at a later point in time.
> 
> So thanks for the review, I'll drop this one.

Now dropped, thanks for the review.

greg k-h
Greg KH April 26, 2021, 5:08 p.m. UTC | #6
On Thu, Apr 22, 2021 at 01:16:01AM +0000, Al Viro wrote:
> On Wed, Apr 21, 2021 at 03:14:29PM -0000, Tavis Ormandy wrote:
> > On 2021-04-21, Greg Kroah-Hartman wrote:
> > > This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
> > >
> > > -	*((struct vbg_ioctl_hdr *)buf) = hdr;
> > > -	if (copy_from_user(buf + sizeof(hdr), (void *)arg + sizeof(hdr),
> > > -			   hdr.size_in - sizeof(hdr))) {
> > > +	if (copy_from_user(buf, (void *)arg, hdr.size_in)) {
> > >  		ret = -EFAULT;
> > >  		goto out;
> > >  	}
> > 
> > This one seems like a real bugfix, otherwise there's a double-fetch from
> > userspace, and a TOCTOU with the hdr fields that could cause a OOB read.
> 
> 	ACK, except that typecasts in there are messy as hell.  But that's,
> alas, consistent with the rest of the function...
> 
> 	Patch itself is correct, and AFAICS Wenwen Wang <wang6495@umn.edu>
> might be an innocent collateral damage from that mess - commits from that
> source appear to be fairly well-written.

I've dropped it from my tree now, thanks for the review.

greg k-h
Hans de Goede April 26, 2021, 5:19 p.m. UTC | #7
Hi,

On 4/26/21 7:08 PM, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 06:59:58PM +0200, Greg Kroah-Hartman wrote:
>> On Wed, Apr 21, 2021 at 06:51:24PM +0200, Hans de Goede wrote:
>>> Hi Greg,
>>>
>>> On 4/21/21 3:01 PM, Greg Kroah-Hartman wrote:
>>>> This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
>>>>
>>>> Commits from @umn.edu addresses have been found to be submitted in "bad
>>>> faith" to try to test the kernel community's ability to review "known
>>>> malicious" changes.  The result of these submissions can be found in a
>>>> paper published at the 42nd IEEE Symposium on Security and Privacy
>>>> entitled, "Open Source Insecurity: Stealthily Introducing
>>>> Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
>>>> of Minnesota) and Kangjie Lu (University of Minnesota).
>>>>
>>>> Because of this, all submissions from this group must be reverted from
>>>> the kernel tree and will need to be re-reviewed again to determine if
>>>> they actually are a valid fix.  Until that work is complete, remove this
>>>> change to ensure that no problems are being introduced into the
>>>> codebase.
>>>>
>>>> Cc: Wenwen Wang <wang6495@umn.edu>
>>>> Cc: Hans de Goede <hdegoede@redhat.com>
>>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>
>>> Ugh what a mess (the whole umn.edu thing).
>>>
>>> I still remember reviewing this patch during its original submission
>>> and I've reviewed it again this morning when you just send it out.
>>>
>>> And now after letting it sit for a bit I've reviewed it a third time
>>> and it seems to do what it says on the label / in the original commit
>>> msg; and if fixes a real, potentially security, issue.
>>>
>>> I'm not sure what the process is for "good" patches in the set
>>> which you are reverting. I would prefer for this patch to be dropped
>>> from the set of reveert. But I can also submit a revert of the revert(?)
>>> once this set of reverts has been merged.
>>
>> If you have reviewed it, and think it should stay, I will drop the
>> revert from my patch series.  Other maintainers/reviewers have asked the
>> same thing for their patches, which is fine.
>>
>> Anything that I do end up reverting, that was not reviewed, will be
>> again reviewed by me and others to determine if it is "safe" to come
>> back in at a later point in time.
>>
>> So thanks for the review, I'll drop this one.
> 
> Now dropped, thanks for the review.

Great, thank you.

Regards,

Hans

Patch
diff mbox series

diff --git a/drivers/virt/vboxguest/vboxguest_linux.c b/drivers/virt/vboxguest/vboxguest_linux.c
index 73eb34849eab..f5cd9cfa1ef6 100644
--- a/drivers/virt/vboxguest/vboxguest_linux.c
+++ b/drivers/virt/vboxguest/vboxguest_linux.c
@@ -142,9 +142,7 @@  static long vbg_misc_device_ioctl(struct file *filp, unsigned int req,
 	if (!buf)
 		return -ENOMEM;
 
-	*((struct vbg_ioctl_hdr *)buf) = hdr;
-	if (copy_from_user(buf + sizeof(hdr), (void *)arg + sizeof(hdr),
-			   hdr.size_in - sizeof(hdr))) {
+	if (copy_from_user(buf, (void *)arg, hdr.size_in)) {
 		ret = -EFAULT;
 		goto out;
 	}