From: Dominique Martinet <asmadeus@codewreck.org>
To: Greg Kurz <groug@kaod.org>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
v9fs-developer@lists.sourceforge.net,
Latchesar Ionkov <lucho@ionkov.net>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Eric Van Hensbergen <ericvh@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [V9fs-developer] [PATCH kernel] 9p/trans_fd: Check file mode at opening
Date: Wed, 29 Jul 2020 08:14:49 +0200 [thread overview]
Message-ID: <20200729061449.GA19682@nautica> (raw)
In-Reply-To: <20200728194235.52660c08@bahia.lan>
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
next prev parent reply other threads:[~2020-07-29 6:15 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-28 12:41 [PATCH kernel] 9p/trans_fd: Check file mode at opening Alexey Kardashevskiy
2020-07-28 17:42 ` [V9fs-developer] " Greg Kurz
2020-07-28 23:50 ` Alexey Kardashevskiy
2020-07-29 6:06 ` Greg Kurz
2020-07-29 6:14 ` Dominique Martinet [this message]
2020-07-29 6:38 ` Greg Kurz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200729061449.GA19682@nautica \
--to=asmadeus@codewreck.org \
--cc=aik@ozlabs.ru \
--cc=davem@davemloft.net \
--cc=ericvh@gmail.com \
--cc=groug@kaod.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=netdev@vger.kernel.org \
--cc=v9fs-developer@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox