Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp875183ybg; Tue, 28 Jul 2020 23:17:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx57Hlxn7MyKIDFnU9YfpJBz3F/6tG9W2yRq/V38c5hH1tEeSSeSc8861wCFTF1J6GAmEt4 X-Received: by 2002:a17:906:694b:: with SMTP id c11mr9532748ejs.232.1596003452514; Tue, 28 Jul 2020 23:17:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596003452; cv=none; d=google.com; s=arc-20160816; b=XsFEPuzZCH1zfe+uBn+4WNemCjYtvspbMPKnt4IeNOsEOsNdsaqC2s2ue0G727pAkX NTHln6j4JxP3FaeGAo2dJujvw8PQWDEtTPASfUcQ3ul9hJSBJqb3Xvp0qE+lj4fS5AZN dlhRdCGqjykb2RkVMaqa9hEDcL5flEoT8i9rQrz2mVv3diM5A6u8mdif17rHhuY/QdVP C4SX9tBLW/g29RNT62kBHmvpWqMs+s+6/9Pe0ZfqPjvzwF+ieAy6LXl/g0vY86gbAwbK 03qZpKaTWCxWKxSwxzU6l19DOOd0e4IoUAIpwqiWuvkfaWm5T26zhhxLDs2jv+WsGjax cvsA== 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; bh=jrYdPy4sx+WpBMZYT+l1f5VJQEvST9WsAA6BUr2Afnc=; b=stHDYdOXbC20gkTOM4vYsxLJJnHbFJZpGgpAUiQhutKSWdh/EYUHIiy+TmAjz/iXVK vQleSnj4EllF1Ryj0UOEEEMV5RL075z3HA7S6GhkqG9YygjbqKxuxwOEvWRq7Fj1KkNI e53YwcbPNJCG48SBH5yDB6dowN1tjdZrYQ56j2JLMNUCtYqjppU8U/Od1Hw0c5PIEVVc msmPpQoCteYJi/HmCzCPF18hHGqUbZxbVR7Lqjm7JZqQie1ID6q4/k4+Tvc7LR67mhQz iZ+9FOCCF4jWk+mpND79cj3/fFhOcosPJTf7Ypi+cY1bGn8Mzh9KQM9kwjav9JzKqZwn EkWg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d19si458753ejj.468.2020.07.28.23.17.09; Tue, 28 Jul 2020 23:17:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726824AbgG2GPJ (ORCPT + 99 others); Wed, 29 Jul 2020 02:15:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40194 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726286AbgG2GPI (ORCPT ); Wed, 29 Jul 2020 02:15:08 -0400 Received: from nautica.notk.org (ipv6.notk.org [IPv6:2001:41d0:1:7a93::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B06BEC061794; Tue, 28 Jul 2020 23:15:07 -0700 (PDT) Received: by nautica.notk.org (Postfix, from userid 1001) id 31395C01F; Wed, 29 Jul 2020 08:15:04 +0200 (CEST) Date: Wed, 29 Jul 2020 08:14:49 +0200 From: Dominique Martinet To: Greg Kurz Cc: Alexey Kardashevskiy , v9fs-developer@lists.sourceforge.net, Latchesar Ionkov , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Eric Van Hensbergen , Jakub Kicinski , "David S. Miller" Subject: Re: [V9fs-developer] [PATCH kernel] 9p/trans_fd: Check file mode at opening Message-ID: <20200729061449.GA19682@nautica> References: <20200728124129.130856-1-aik@ozlabs.ru> <20200728194235.52660c08@bahia.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200728194235.52660c08@bahia.lan> 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 Greg Kurz wrote on Tue, Jul 28, 2020: > > The "fd" transport layer uses 2 file descriptors passed externally > > and calls kernel_write()/kernel_read() on these. If files were opened > > without FMODE_WRITE/FMODE_READ, WARN_ON_ONCE() will fire. There already is a fix in linux-next as a39c46067c84 ("net/9p: validate fds in p9_fd_open") > > This adds file mode checking in p9_fd_open; this returns -EBADF to > > preserve the original behavior. > > So this would cause open() to fail with EBADF, which might look a bit > weird to userspace since it didn't pass an fd... Is this to have a > different error than -EIO that is returned when either rfd or wfd > doesn't point to an open file descriptor ? If yes, why do we care ? FWIW the solution taken just returns EIO as it would if an invalid fd was given, but since it did pass an fd EBADF actually makes sense to me? However to the second question I'm not sure I care :) > > Found by syzkaller. I'm starting to understand where David comment came from the other day, I guess it's still time to change my mind and submit to linus now I've had time to test it... -- Dominique