Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp125126imm; Thu, 26 Jul 2018 15:16:49 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdlYcq9ytZKJsJcl4G7dbq3SQUl59/0F2aaHDZlBRli2QW89uI4JOYIXCQEHMfmipHQdRYH X-Received: by 2002:a63:3686:: with SMTP id d128-v6mr3495668pga.18.1532643409406; Thu, 26 Jul 2018 15:16:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532643409; cv=none; d=google.com; s=arc-20160816; b=MM+MnkuyCQy1wm6pJ51PUW+6dMnUR9IkVzoNt3qhdnsRmPZsb5gJYn4e4RaSMHQ0cg 5uVDzeWV24HLg1tE2vjQldcdSMTi3rLC/69MQVSlHW9dJzoL6UQIofmG0I75OaCj0ALQ /kf3BfiBM590lX5iaDVFN0fi4SJmsJH27wNqa907tAHNsFiyfamDup50ItTROALH+wpk IkNEmhRfRN+4VGSIyydEClX1Ph4yopfHqmTPlbIR3RdwMtqXWoPEPTixS2gm/jlLukli t7LY2mPARweXLrRm37HviZMdh2ldbRQNVuCCMmZa8lo5ayvJ23ZYEK/IV/9xSOYxomMQ ghDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=gC5PkLUncIAIMQbQra3M7ul1DRvGLGz2IQBwpmPAPXI=; b=qg1QfXr919HS/CvwUmWIx6vxH9ssDp2EQgU226Bk4b6xr5zzsIqSTGH7b6FOrjqvUi Y644z6k0d30R0FrsxDLKOBi6yejLVcrWJ7UQLvejg+k8UhKxLlR0+UuR+qhH7u9Ak6E8 YlKb5xyL7VJeBMw2KCX6VMw++lnaa+RlBo9yflG7/foAvYZXPjYK5bunIj9pQRxAgmfU UDTQZToAVJLxhVS+zWqTn5Ff5EiNrIp8H7frojtzt2LrqiuRgxk6F5HuwFOo3IXoRfLv 3WsHoQdt4Tdug9ZI7Nrspqy23h+fnWTDVnAY5tbpphMvPtIibPvKyFAiK1nnGgLJ6Tn9 Ko3Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f16-v6si2376245pff.13.2018.07.26.15.16.34; Thu, 26 Jul 2018 15:16:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731790AbeGZXee (ORCPT + 99 others); Thu, 26 Jul 2018 19:34:34 -0400 Received: from nautica.notk.org ([91.121.71.147]:55512 "EHLO nautica.notk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730581AbeGZXee (ORCPT ); Thu, 26 Jul 2018 19:34:34 -0400 Received: by nautica.notk.org (Postfix, from userid 1001) id 33ACCC009; Fri, 27 Jul 2018 00:15:42 +0200 (CEST) Date: Fri, 27 Jul 2018 00:15:27 +0200 From: Dominique Martinet To: Tomas Bortoli Cc: Dmitry Vyukov , David Miller , v9fs-developer@lists.sourceforge.net, netdev , LKML , syzkaller Subject: Re: [PATCH] 9p: fix NULL pointer dereferences Message-ID: <20180726221527.GA9426@nautica> References: <20180726081049.10527-1-tomasbortoli@gmail.com> <20180726081727.GA6699@nautica> <20180726094849.GA18334@nautica> <20180726142109.GA4235@nautica> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tomas Bortoli wrote on Thu, Jul 26, 2018: > > If we want to preserve the current behaviour for trans=fd (and I don't > > see why not) we just have to patch all the transports that use the > > device, that is all .create functions but p9_fd_create() > > > > Basically exactly what you did, just for a few more functions - I > > apparently was a little bit too optimistic thinking we could share > > this check. > > Does v9fs_mount() knows the transport ahead? Because in that case it'd > be possible to check if addr!=NULL && trans!=fd then return error > > Otherwise, patching all the .create, ok. 9p option parsing is all over the place, split in fs/9p/v9fs, net/9p/client and net/9p/trans_*... Which is actually somewhat of a problem because that means we can't warn on unused option as each parser does not know the full subset of options used, so if someone makes a typo they're on their own to figure it out :/ If you want to factor it in, v9fs_mount does not know which transport is used, but p9_client_create does know - although the functions/structs are all static so you need to check clnt->trans_mod->name with strcmp and I'm honestly not sure that's better than checking in each function.. But, as usual I'm happy as long as it works, so pick your poison :) -- Dominique Martinet