linux-kernel - Re: [PATCH net-next v1 13/21] nfp: Move delink

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]

Message-ID: <20210927122041.GA12315@corigine.com>
Date:   Mon, 27 Sep 2021 14:20:42 +0200
From:   Simon Horman <simon.horman@...igine.com>
To:     Leon Romanovsky <leon@...nel.org>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>, Ariel Elior <aelior@...vell.com>,
        Bin Luo <luobin9@...wei.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Coiby Xu <coiby.xu@...il.com>,
        Derek Chickles <dchickles@...vell.com>, drivers@...sando.io,
        Felix Manlunas <fmanlunas@...vell.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Geetha sowjanya <gakula@...vell.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        GR-everest-linux-l2@...vell.com, GR-Linux-NIC-Dev@...vell.com,
        hariprasad <hkelam@...vell.com>,
        Ido Schimmel <idosch@...dia.com>,
        Intel Corporation <linuxwwan@...el.com>,
        intel-wired-lan@...ts.osuosl.org,
        Ioana Ciornei <ioana.ciornei@....com>,
        Jerin Jacob <jerinj@...vell.com>,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Jiri Pirko <jiri@...dia.com>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        Linu Cherian <lcherian@...vell.com>,
        linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
        linux-rdma@...r.kernel.org, linux-staging@...ts.linux.dev,
        Loic Poulain <loic.poulain@...aro.org>,
        Manish Chopra <manishc@...vell.com>,
        M Chetan Kumar <m.chetan.kumar@...el.com>,
        Michael Chan <michael.chan@...adcom.com>,
        Michael Guralnik <michaelgur@...lanox.com>,
        netdev@...r.kernel.org, oss-drivers@...igine.com,
        Richard Cochran <richardcochran@...il.com>,
        Saeed Mahameed <saeedm@...dia.com>,
        Satanand Burla <sburla@...vell.com>,
        Sergey Ryazanov <ryazanov.s.a@...il.com>,
        Shannon Nelson <snelson@...sando.io>,
        Subbaraya Sundeep <sbhatta@...vell.com>,
        Sunil Goutham <sgoutham@...vell.com>,
        Taras Chornyi <tchornyi@...vell.com>,
        Tariq Toukan <tariqt@...dia.com>,
        Tony Nguyen <anthony.l.nguyen@...el.com>,
        UNGLinuxDriver@...rochip.com, Vadym Kochan <vkochan@...vell.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: [PATCH net-next v1 13/21] nfp: Move delink_register to be last
 command

On Mon, Sep 27, 2021 at 02:53:24PM +0300, Leon Romanovsky wrote:
> On Mon, Sep 27, 2021 at 10:39:24AM +0200, Simon Horman wrote:
> > On Sat, Sep 25, 2021 at 02:22:53PM +0300, Leon Romanovsky wrote:
> > > From: Leon Romanovsky <leonro@...dia.com>
> > > 
> > > Open user space access to the devlink after driver is probed.
> > 
> > Hi Leon,
> > 
> > I think a description of why is warranted here.
> 
> After devlink_register(), users can send GET and SET netlink commands to
> the uninitialized driver. In some cases, nothing will happen, but not in
> all and hard to prove that ALL drivers are safe with such early access.
> 
> It means that local users can (in theory for some and in practice for
> others) crash the system (or leverage permissions) with early devlink_register()
> by accessing internal to driver pointers that are not set yet.
> 
> Like I said in the commit message, I'm not fixing all drivers.
> https://lore.kernel.org/netdev/cover.1632565508.git.leonro@nvidia.com/T/#m063eb4e67389bafcc3b3ddc07197bf43181b7209
> 
> Because some of the driver authors made a wonderful job to obfuscate their
> driver and write completely unmanageable code.
> 
> I do move devlink_register() to be last devlink command for all drivers,
> to allow me to clean devlink core locking and API in next series.
> 
> This series should raise your eyebrow and trigger a question: "is my
> driver vulnerable too?". And the answer will depend on devlink_register()
> position in the .probe() call.
> 
> Thanks

Thanks for the explanation.
And thanks for taking time to update the NFP driver.

> > > Signed-off-by: Leon Romanovsky <leonro@...dia.com>

Acked-by: Simon Horman <simon.horman@...igine.com>