From: Dan Carpenter <dan.carpenter@oracle.com>
To: Wenwen Wang <wang6495@umn.edu>
Cc: "open list:STAGING SUBSYSTEM" <devel@driverdev.osuosl.org>,
Aastha Gupta <aastha.gupta4104@gmail.com>,
Roman Storozhenko <romeusmeister@gmail.com>,
Andreas Dilger <andreas.dilger@intel.com>,
Jeff Layton <jlayton@redhat.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Kangjie Lu <kjlu@umn.edu>, NeilBrown <neilb@suse.com>,
open list <linux-kernel@vger.kernel.org>,
Oleg Drokin <oleg.drokin@intel.com>,
"moderated list:STAGING - LUSTRE PARALLEL FILESYSTEM"
<lustre-devel@lists.lustre.org>
Subject: Re: [PATCH v2] staging: lustre: llite: fix potential missing-check bug when copying lumv
Date: Tue, 1 May 2018 11:46:21 +0300 [thread overview]
Message-ID: <20180501084621.jfxrm3qoqfmftnxh@mwanda> (raw)
In-Reply-To: <1525128971-8946-1-git-send-email-wang6495@umn.edu>
On Mon, Apr 30, 2018 at 05:56:10PM -0500, Wenwen Wang wrote:
> However, given that the user data resides in the user space, a malicious
> user-space process can race to change the data between the two copies. By
> doing so, the attacker can provide a data with an inconsistent version,
> e.g., v1 version + v3 data. This can lead to logical errors in the
> following execution in ll_dir_setstripe(), which performs different actions
> according to the version specified by the field lmm_magic.
This part is misleading. The fix is to improve readability and make
static checkers happy. You're over dramatizing it to make people think
it has a security impact when it doesn't.
If the user wants to specify v1 data they can just say that on the first
read. They don't need to do funny tricks and race between the two
reads. It's allowed.
In other words this allows the user to do something in a very
complicated way which they are already allowed to do in a very simple
straight forward way.
regards,
dan carpenter
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2018-05-01 8:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 22:56 Wenwen Wang
2018-05-01 4:06 ` Dilger, Andreas
2018-05-01 8:46 ` Dan Carpenter [this message]
2018-05-04 4:19 ` Wenwen Wang
2018-05-04 5:27 ` Dan Carpenter
2018-05-04 5:33 ` Wenwen Wang
2018-05-04 10:08 ` Dilger, Andreas
2018-05-04 14:11 ` Wenwen Wang
2018-05-04 15:01 Kangjie Lu
2018-05-05 8:29 ` Dan Carpenter
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=20180501084621.jfxrm3qoqfmftnxh@mwanda \
--to=dan.carpenter@oracle.com \
--cc=aastha.gupta4104@gmail.com \
--cc=andreas.dilger@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=jlayton@redhat.com \
--cc=kjlu@umn.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=lustre-devel@lists.lustre.org \
--cc=neilb@suse.com \
--cc=oleg.drokin@intel.com \
--cc=romeusmeister@gmail.com \
--cc=wang6495@umn.edu \
/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
all inboxes | Powered by JetHome®