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  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:   Mon, 21 Dec 2020 10:47:57 -0800
From:   Jakub Kicinski <>
To:     Russell King - ARM Linux admin <>,
Cc:     Marcin Wojtas <>, Sasha Levin <>,
        Antoine Tenart <>,
        Alexandre Belloni <>,
        "David S. Miller" <>,
        netdev <>,
        Gabor Samu <>,
        Jon Nettleton <>,
        Andrew Elwell <>,
        Greg Kroah-Hartman <>
Subject: Re: [PATCH net-next 2/4] net: mvpp2: add mvpp2_phylink_to_port()

On Mon, 21 Dec 2020 18:30:32 +0000 Russell King - ARM Linux admin wrote:
> On Mon, Dec 21, 2020 at 10:25:39AM -0800, Jakub Kicinski wrote:
> > We need to work with stable maintainers on this, let's see..
> > 
> > Greg asked for a clear description of what happens, from your 
> > previous response it sounds like a null-deref in mvpp2_mac_config(). 
> > Is the netdev -> config -> netdev linking not ready by the time
> > mvpp2_mac_config() is called?  
> We are going round in circles, so nothing is going to happen.
> I stated in detail in one of my emails on the 10th December why the
> problem occurs. So, Greg has the description already. There is no
> need to repeat it.
> Can we please move forward with this?

Well, the fact it wasn't quoted in Marcin's reply and that I didn't
spot it when scanning the 30 email thread should be a clear enough
indication whether pinging threads is a good strategy..

A clear, fresh backport request would had been much more successful 
and easier for Greg to process. If you still don't see a reply in
2 weeks, please just do that.

In case Greg is in fact reading this:

Greg, can we backport: 

6c2b49eb9671 ("net: mvpp2: add mvpp2_phylink_to_port() helper")

to 5.4? Quoting Russell:

The problem is that mvpp2_acpi_start() passes an un-initialised
(zeroed) port->phylink_config, as phylink is not used in ACPI setups.

Crash occurs because port-> (which is a NULL pointer
in this instance) is passed to to_net_dev():

#define to_net_dev(d) container_of(d, struct net_device, dev)

Which then means netdev_priv(dev) attempts to dereference a not-quite
NULL pointer, leading to an oops.

Folks here are willing to provide a more cut down fix if necessary.


Powered by blists - more mailing lists