From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60AF0C4332F for ; Mon, 27 Sep 2021 11:53:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 47F6260F9B for ; Mon, 27 Sep 2021 11:53:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234146AbhI0LzH (ORCPT ); Mon, 27 Sep 2021 07:55:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:56210 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234015AbhI0LzG (ORCPT ); Mon, 27 Sep 2021 07:55:06 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BA30360F6C; Mon, 27 Sep 2021 11:53:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1632743608; bh=Q2dHeySo3zRsXGknIbLs6i+yTpWx2dDgGoEFYPDr5/8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YaUXTiQmxWntMdcP1V6UabAj5J8Y25L1/E0AYpGsph11k51k6VvuI8uPokBfxbcAk m2uUNUxT0DP/R0xJf6IGUC8maz/OqFGDLCwx0qK2IoUljTtiFro1XMJp+GmLED5ssx T1ku5NlihRu34GIj81fPeIw7ebnIWBENHWl+gsXCpbVoVK2JoPlPV9W9/7Ky2991FF arzkdMMFq4EaH/2DLzzcuKPhUe4TrV024+K0jMiavouR22LFvA7VwYQ1mEsRJO8slE 0+cd42Ha63JskwWD96PNT2Osmj6PMhlOW5OdUO22AYB3Y6mybJGQC1TChNKODmw7Ew 1Cj5jreVMvoQQ== Date: Mon, 27 Sep 2021 14:53:24 +0300 From: Leon Romanovsky To: Simon Horman Cc: "David S . Miller" , Jakub Kicinski , Alexandre Belloni , Andrew Lunn , Ariel Elior , Bin Luo , Claudiu Manoil , Coiby Xu , Derek Chickles , drivers@pensando.io, Felix Manlunas , Florian Fainelli , Geetha sowjanya , Greg Kroah-Hartman , GR-everest-linux-l2@marvell.com, GR-Linux-NIC-Dev@marvell.com, hariprasad , Ido Schimmel , Intel Corporation , intel-wired-lan@lists.osuosl.org, Ioana Ciornei , Jerin Jacob , Jesse Brandeburg , Jiri Pirko , Jonathan Lemon , Linu Cherian , linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, linux-rdma@vger.kernel.org, linux-staging@lists.linux.dev, Loic Poulain , Manish Chopra , M Chetan Kumar , Michael Chan , Michael Guralnik , netdev@vger.kernel.org, oss-drivers@corigine.com, Richard Cochran , Saeed Mahameed , Satanand Burla , Sergey Ryazanov , Shannon Nelson , Subbaraya Sundeep , Sunil Goutham , Taras Chornyi , Tariq Toukan , Tony Nguyen , UNGLinuxDriver@microchip.com, Vadym Kochan , Vivien Didelot , Vladimir Oltean Subject: Re: [PATCH net-next v1 13/21] nfp: Move delink_register to be last command Message-ID: References: <20210927083923.GC17484@corigine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210927083923.GC17484@corigine.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 > > > > 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 > > > Signed-off-by: Leon Romanovsky