[113/190] Revert "x86/hpet: Prevent potential NULL pointer dereference"
diff mbox series

Message ID 20210421130105.1226686-114-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, 12:59 p.m. UTC
This reverts commit 2e84f116afca3719c9d0a1a78b47b48f75fd5724.

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: Aditya Pakki <pakki001@umn.edu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: kjlu@umn.edu
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Joe Perches <joe@perches.com>
Cc: Nicolai Stange <nstange@suse.de>
Cc: Roland Dreier <roland@purestorage.com>
Cc: https
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 arch/x86/kernel/hpet.c | 2 --
 1 file changed, 2 deletions(-)

Comments

Kees Cook April 21, 2021, 7:49 p.m. UTC | #1
On Wed, Apr 21, 2021 at 02:59:48PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 2e84f116afca3719c9d0a1a78b47b48f75fd5724.
> 
> 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: Aditya Pakki <pakki001@umn.edu>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: kjlu@umn.edu
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Joe Perches <joe@perches.com>
> Cc: Nicolai Stange <nstange@suse.de>
> Cc: Roland Dreier <roland@purestorage.com>
> Cc: https
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  arch/x86/kernel/hpet.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> index 08651a4e6aa0..0515a97bf6f5 100644
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -930,8 +930,6 @@ int __init hpet_enable(void)
>  		return 0;
>  
>  	hpet_set_mapping();
> -	if (!hpet_virt_address)
> -		return 0;
>  
>  	/* Validate that the config register is working */
>  	if (!hpet_cfg_working())

FWIW, this patch looks harmless. It is checking for a failure in
hpet_set_mapping(), and avoids the following code from performing
0-offset reads. hpet_set_mapping() is likely to never fail in real-world
situations. *shrug*

I think it would make more sense for the check to live in
hpet_cfg_working(), though.
Thomas Gleixner April 22, 2021, 11:33 p.m. UTC | #2
On Wed, Apr 21 2021 at 12:49, Kees Cook wrote:
> On Wed, Apr 21, 2021 at 02:59:48PM +0200, Greg Kroah-Hartman wrote:
>> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
>> index 08651a4e6aa0..0515a97bf6f5 100644
>> --- a/arch/x86/kernel/hpet.c
>> +++ b/arch/x86/kernel/hpet.c
>> @@ -930,8 +930,6 @@ int __init hpet_enable(void)
>>  		return 0;
>>  
>>  	hpet_set_mapping();
>> -	if (!hpet_virt_address)
>> -		return 0;
>>  
>>  	/* Validate that the config register is working */
>>  	if (!hpet_cfg_working())
>
> FWIW, this patch looks harmless. It is checking for a failure in
> hpet_set_mapping(), and avoids the following code from performing
> 0-offset reads. hpet_set_mapping() is likely to never fail in real-world
> situations. *shrug*

'likely never to fail' is clearly a receipe for disaster and you should
know that.

> I think it would make more sense for the check to live in
> hpet_cfg_working(), though.

No. That does not make any sense at all.

The proper change would have been to make hpet_set_mapping() return
an error/success code and act on that.

But that does _NOT_ make the patch invalid.

I'm pretty sure that I looked at it and thought about the proper
solution (see above) and then shrugged it off because of overload...

Thanks,

        tglx
Kees Cook April 23, 2021, 9:03 a.m. UTC | #3
On Fri, Apr 23, 2021 at 01:33:07AM +0200, Thomas Gleixner wrote:
> On Wed, Apr 21 2021 at 12:49, Kees Cook wrote:
> > On Wed, Apr 21, 2021 at 02:59:48PM +0200, Greg Kroah-Hartman wrote:
> >> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> >> index 08651a4e6aa0..0515a97bf6f5 100644
> >> --- a/arch/x86/kernel/hpet.c
> >> +++ b/arch/x86/kernel/hpet.c
> >> @@ -930,8 +930,6 @@ int __init hpet_enable(void)
> >>  		return 0;
> >>  
> >>  	hpet_set_mapping();
> >> -	if (!hpet_virt_address)
> >> -		return 0;
> >>  
> >>  	/* Validate that the config register is working */
> >>  	if (!hpet_cfg_working())
> >
> > FWIW, this patch looks harmless. It is checking for a failure in
> > hpet_set_mapping(), and avoids the following code from performing
> > 0-offset reads. hpet_set_mapping() is likely to never fail in real-world
> > situations. *shrug*
> 
> 'likely never to fail' is clearly a receipe for disaster and you should
> know that.

Of course -- I prefer to keep the sanity check. It just wasn't as good
as it could have been: it's not clear just by looking at the patch how
hpet_virt_address and hpet_set_mapping() are related.

> 
> > I think it would make more sense for the check to live in
> > hpet_cfg_working(), though.
> 
> No. That does not make any sense at all.
> 
> The proper change would have been to make hpet_set_mapping() return
> an error/success code and act on that.
> 
> But that does _NOT_ make the patch invalid.
> 
> I'm pretty sure that I looked at it and thought about the proper
> solution (see above) and then shrugged it off because of overload...

Right, no, I was saying the original patch should stay. It shouldn't be
reverted.

Greg, please drop this patch from the revert list.
Greg KH April 26, 2021, 4:55 p.m. UTC | #4
On Fri, Apr 23, 2021 at 02:03:50AM -0700, Kees Cook wrote:
> On Fri, Apr 23, 2021 at 01:33:07AM +0200, Thomas Gleixner wrote:
> > On Wed, Apr 21 2021 at 12:49, Kees Cook wrote:
> > > On Wed, Apr 21, 2021 at 02:59:48PM +0200, Greg Kroah-Hartman wrote:
> > >> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> > >> index 08651a4e6aa0..0515a97bf6f5 100644
> > >> --- a/arch/x86/kernel/hpet.c
> > >> +++ b/arch/x86/kernel/hpet.c
> > >> @@ -930,8 +930,6 @@ int __init hpet_enable(void)
> > >>  		return 0;
> > >>  
> > >>  	hpet_set_mapping();
> > >> -	if (!hpet_virt_address)
> > >> -		return 0;
> > >>  
> > >>  	/* Validate that the config register is working */
> > >>  	if (!hpet_cfg_working())
> > >
> > > FWIW, this patch looks harmless. It is checking for a failure in
> > > hpet_set_mapping(), and avoids the following code from performing
> > > 0-offset reads. hpet_set_mapping() is likely to never fail in real-world
> > > situations. *shrug*
> > 
> > 'likely never to fail' is clearly a receipe for disaster and you should
> > know that.
> 
> Of course -- I prefer to keep the sanity check. It just wasn't as good
> as it could have been: it's not clear just by looking at the patch how
> hpet_virt_address and hpet_set_mapping() are related.
> 
> > 
> > > I think it would make more sense for the check to live in
> > > hpet_cfg_working(), though.
> > 
> > No. That does not make any sense at all.
> > 
> > The proper change would have been to make hpet_set_mapping() return
> > an error/success code and act on that.
> > 
> > But that does _NOT_ make the patch invalid.
> > 
> > I'm pretty sure that I looked at it and thought about the proper
> > solution (see above) and then shrugged it off because of overload...
> 
> Right, no, I was saying the original patch should stay. It shouldn't be
> reverted.
> 
> Greg, please drop this patch from the revert list.

Now dropped, thanks for the review.

greg k-h

Patch
diff mbox series

diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 08651a4e6aa0..0515a97bf6f5 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -930,8 +930,6 @@  int __init hpet_enable(void)
 		return 0;
 
 	hpet_set_mapping();
-	if (!hpet_virt_address)
-		return 0;
 
 	/* Validate that the config register is working */
 	if (!hpet_cfg_working())