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] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 20 Aug 2021 11:10:53 -0700
From:   Saravana Kannan <saravanak@...gle.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Alvin Šipraga <ALSI@...g-olufsen.dk>,
        Vladimir Oltean <olteanv@...il.com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Frank Rowand <frowand.list@...il.com>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH net] net: dsa: sja1105: fix use-after-free after calling
 of_find_compatible_node, or worse

On Fri, Aug 20, 2021 at 10:54 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> > 3. If dsa_register_switch() fails, we can't defer the probe (because
> > it already succeeded). But I'm not sure if it's a likely error code.
>
> That is not a safe assumption. The tagging driver can be a module, and

I don't know what "tagging driver" means. And yes, this is just a test
patch for now.

> not be loaded yet. So we defer probing to allow it to load.
>
> Ethernet switches can be a big graph of parts, not a nice tree of
> parts.

fw_devlink can handle graphs well. It has cycle detection for a reason
:) Look at slide 10 for a complicated example:
https://linuxplumbersconf.org/event/7/contributions/787/attachments/529/942/LPC_2020_-_fw_devlink.pdf

However, after sending that email I realized that fw_devlink=on would
make sure all the dependencies of this device would have probed first
before it allows this to probe. So EPROBE_DEFER can't really happen.
But for now I just want to see if it fixes the issue Alvin was seeing.

-Saravana

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ