[168/190] Revert "net: marvell: fix a missing check of acpi_match_device"
diff mbox series

Message ID 20210421130105.1226686-169-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 p.m. UTC
This reverts commit 92ee77d148bf06d8c52664be4d1b862583fd5c0e.

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: Kangjie Lu <kjlu@umn.edu>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 --
 1 file changed, 2 deletions(-)

Comments

Greg KH April 27, 2021, 2:52 p.m. UTC | #1
On Wed, Apr 21, 2021 at 03:00:43PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 92ee77d148bf06d8c52664be4d1b862583fd5c0e.
> 
> 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: Kangjie Lu <kjlu@umn.edu>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 1767c60056c5..f1a70b37227f 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -7328,8 +7328,6 @@ static int mvpp2_probe(struct platform_device *pdev)
>  	if (has_acpi_companion(&pdev->dev)) {
>  		acpi_id = acpi_match_device(pdev->dev.driver->acpi_match_table,
>  					    &pdev->dev);
> -		if (!acpi_id)
> -			return -EINVAL;
>  		priv->hw_version = (unsigned long)acpi_id->driver_data;
>  	} else {
>  		priv->hw_version =
> -- 
> 2.31.1
> 

The original commit here looks correct, so I'll drop this revert.

greg k-h
Russell King (Oracle) April 28, 2021, 10:50 a.m. UTC | #2
On Tue, Apr 27, 2021 at 04:52:14PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 03:00:43PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 92ee77d148bf06d8c52664be4d1b862583fd5c0e.
> > 
> > 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: Kangjie Lu <kjlu@umn.edu>
> > Cc: David S. Miller <davem@davemloft.net>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> >  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > index 1767c60056c5..f1a70b37227f 100644
> > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > @@ -7328,8 +7328,6 @@ static int mvpp2_probe(struct platform_device *pdev)
> >  	if (has_acpi_companion(&pdev->dev)) {
> >  		acpi_id = acpi_match_device(pdev->dev.driver->acpi_match_table,
> >  					    &pdev->dev);
> > -		if (!acpi_id)
> > -			return -EINVAL;
> >  		priv->hw_version = (unsigned long)acpi_id->driver_data;
> >  	} else {
> >  		priv->hw_version =
> > -- 
> > 2.31.1
> > 
> 
> The original commit here looks correct, so I'll drop this revert.

Agreed, the original patch looks fine to me and the revert is
unnecessary.
Dmitry Torokhov April 28, 2021, 7:50 p.m. UTC | #3
On Wed, Apr 28, 2021 at 6:47 AM Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Tue, Apr 27, 2021 at 04:52:14PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 21, 2021 at 03:00:43PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit 92ee77d148bf06d8c52664be4d1b862583fd5c0e.
> > >
> > > 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: Kangjie Lu <kjlu@umn.edu>
> > > Cc: David S. Miller <davem@davemloft.net>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > ---
> > >  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > index 1767c60056c5..f1a70b37227f 100644
> > > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > @@ -7328,8 +7328,6 @@ static int mvpp2_probe(struct platform_device *pdev)
> > >     if (has_acpi_companion(&pdev->dev)) {
> > >             acpi_id = acpi_match_device(pdev->dev.driver->acpi_match_table,
> > >                                         &pdev->dev);
> > > -           if (!acpi_id)
> > > -                   return -EINVAL;
> > >             priv->hw_version = (unsigned long)acpi_id->driver_data;
> > >     } else {
> > >             priv->hw_version =
> > > --
> > > 2.31.1
> > >
> >
> > The original commit here looks correct, so I'll drop this revert.
>
> Agreed, the original patch looks fine to me and the revert is
> unnecessary.

I wonder how useful these kinds of patches/checks are. If we are
dealing with ACPI platform device we must have matched on ACPI node
before getting into the probe, so we would match here as well. The
exception would be someone playing with "driver_override" device
attribute, but that someone must be root as therefore have many
options of shooting themselves into foot. So I guess the question is:
do we need to bloat the code with such checks?

Thanks.
Russell King (Oracle) April 28, 2021, 8:35 p.m. UTC | #4
On Wed, Apr 28, 2021 at 12:50:16PM -0700, Dmitry Torokhov wrote:
> On Wed, Apr 28, 2021 at 6:47 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Tue, Apr 27, 2021 at 04:52:14PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Apr 21, 2021 at 03:00:43PM +0200, Greg Kroah-Hartman wrote:
> > > > This reverts commit 92ee77d148bf06d8c52664be4d1b862583fd5c0e.
> > > >
> > > > 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: Kangjie Lu <kjlu@umn.edu>
> > > > Cc: David S. Miller <davem@davemloft.net>
> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > ---
> > > >  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 --
> > > >  1 file changed, 2 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > > index 1767c60056c5..f1a70b37227f 100644
> > > > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > > @@ -7328,8 +7328,6 @@ static int mvpp2_probe(struct platform_device *pdev)
> > > >     if (has_acpi_companion(&pdev->dev)) {
> > > >             acpi_id = acpi_match_device(pdev->dev.driver->acpi_match_table,
> > > >                                         &pdev->dev);
> > > > -           if (!acpi_id)
> > > > -                   return -EINVAL;
> > > >             priv->hw_version = (unsigned long)acpi_id->driver_data;
> > > >     } else {
> > > >             priv->hw_version =
> > > > --
> > > > 2.31.1
> > > >
> > >
> > > The original commit here looks correct, so I'll drop this revert.
> >
> > Agreed, the original patch looks fine to me and the revert is
> > unnecessary.
> 
> I wonder how useful these kinds of patches/checks are. If we are
> dealing with ACPI platform device we must have matched on ACPI node
> before getting into the probe, so we would match here as well. The
> exception would be someone playing with "driver_override" device
> attribute, but that someone must be root as therefore have many
> options of shooting themselves into foot. So I guess the question is:
> do we need to bloat the code with such checks?

It's probably way too late now to think about it (due to the quantity
of drivers) but in many cases, it seems there's a pattern. On probe,
re-lookup the matching ID to fetch the data pointer, and store it in
some way. Had we known that such a pattern would be common, it probably
would have been a good idea to provide a "match_data" member inside
struct device, which the bus probe code can set appropriately from the
match tables. That would also have the benefit of elimianting any
patches such as this, and likely would reduce bloat too.

As I say, likely way too late for that idea now though.

Patch
diff mbox series

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 1767c60056c5..f1a70b37227f 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -7328,8 +7328,6 @@  static int mvpp2_probe(struct platform_device *pdev)
 	if (has_acpi_companion(&pdev->dev)) {
 		acpi_id = acpi_match_device(pdev->dev.driver->acpi_match_table,
 					    &pdev->dev);
-		if (!acpi_id)
-			return -EINVAL;
 		priv->hw_version = (unsigned long)acpi_id->driver_data;
 	} else {
 		priv->hw_version =