linux-kernel - Re: [PATCH 4.14 07/15] driver core: Extend device_is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <YCLcqvgEB6fVtWMx@gerhold.net>
Date:   Tue, 9 Feb 2021 20:04:10 +0100
From:   Stephan Gerhold <stephan@...hold.net>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>
Subject: Re: [PATCH 4.14 07/15] driver core: Extend device_is_dependent()

On Fri, Feb 05, 2021 at 09:52:56AM -0800, Saravana Kannan wrote:
> On Fri, Feb 5, 2021 at 6:14 AM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> >
> > From: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
> >
> > commit 3d1cf435e201d1fd63e4346b141881aed086effd upstream
> >
> > If the device passed as the target (second argument) to
> > device_is_dependent() is not completely registered (that is, it has
> > been initialized, but not added yet), but the parent pointer of it
> > is set, it may be missing from the list of the parent's children
> > and device_for_each_child() called by device_is_dependent() cannot
> > be relied on to catch that dependency.
> >
> > For this reason, modify device_is_dependent() to check the ancestors
> > of the target device by following its parent pointer in addition to
> > the device_for_each_child() walk.
> >
> > Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support")
> > Reported-by: Stephan Gerhold <stephan@...hold.net>
> > Tested-by: Stephan Gerhold <stephan@...hold.net>
> > Reviewed-by: Saravana Kannan <saravanak@...gle.com>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > Link: https://lore.kernel.org/r/17705994.d592GUb2YH@kreacher
> > Cc: stable <stable@...r.kernel.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@...il.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > ---
> >  drivers/base/core.c |   17 ++++++++++++++++-
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -96,6 +96,16 @@ void device_links_read_unlock(int not_us
> >  }
> >  #endif /* !CONFIG_SRCU */
> >
> > +static bool device_is_ancestor(struct device *dev, struct device *target)
> > +{
> > +       while (target->parent) {
> > +               target = target->parent;
> > +               if (dev == target)
> > +                       return true;
> > +       }
> > +       return false;
> > +}
> > +
> >  /**
> >   * device_is_dependent - Check if one device depends on another one
> >   * @dev: Device to check dependencies for.
> > @@ -109,7 +119,12 @@ static int device_is_dependent(struct de
> >         struct device_link *link;
> >         int ret;
> >
> > -       if (dev == target)
> > +       /*
> > +        * The "ancestors" check is needed to catch the case when the target
> > +        * device has not been completely initialized yet and it is still
> > +        * missing from the list of children of its parent device.
> > +        */
> > +       if (dev == target || device_is_ancestor(dev, target))
> >                 return 1;
> >
> >         ret = device_for_each_child(dev, target, device_is_dependent);
> >
> >
> 
> I think 4.14 device links API is so busted it's not worth patching
> this. It's not a memory leak or any kind of security issue.
> 
> Stephan, are you seeing this issue in 4.14 or even care about it?
> 

I guess I'm too late here (sorry about this), but in any case:

Actually, the issue I had only caused problems in some of the early 5.11
release candidates. The cyclic device link was also created on earlier
kernel versions, but (seemingly) did not cause any issues so far.

I try to stay on RCs/stable kernel versions so as far as
I'm concerned there is no need to backport this to 4.14.

Thanks!
Stephan