From: Jan Kara <jack@suse.cz>
To: Matthew Wilcox <willy@infradead.org>
Cc: David Howells <dhowells@redhat.com>,
John Hubbard <jhubbard@nvidia.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
Jens Axboe <axboe@kernel.dk>, Jan Kara <jack@suse.cz>,
Jeff Layton <jlayton@kernel.org>,
Logan Gunthorpe <logang@deltatee.com>,
linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 0/8] iov_iter: Improve page extraction (ref, pin or just list)
Date: Mon, 23 Jan 2023 18:25:29 +0100 [thread overview]
Message-ID: <20230123172529.woo34hnycrn7xhwk@quack3> (raw)
In-Reply-To: <Y865EIsHv3oyz+8U@casper.infradead.org>
On Mon 23-01-23 16:42:56, Matthew Wilcox wrote:
> On Mon, Jan 23, 2023 at 04:38:47PM +0000, David Howells wrote:
> > Matthew Wilcox <willy@infradead.org> wrote:
> > Also you only mention DIO read - but what about "start DIO write; fork(); touch
> > buffer" in the parent - now the write buffer belongs to the child and they can
> > affect the parent's write.
>
> I'm struggling to see the problem here. If the child hasn't exec'd, the
> parent and child are still in the same security domain. The parent
> could have modified the buffer before calling fork().
Sadly they are not. Android in particular starts applications by forking
one big binary (zygote) that has multiple apps linked together and relies
on the fact the child cannot influence the parent after the fork. We've
already had CVEs with GUP & COW & fork due to this. David Hildebrand has a
lot of memories regarding this I believe ;)
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2023-01-23 17:25 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 17:55 [PATCH v7 0/8] iov_iter: Improve page extraction (ref, pin or just list) David Howells
2023-01-20 17:55 ` [PATCH v7 1/8] iov_iter: Define flags to qualify page extraction David Howells
2023-01-21 13:01 ` Christoph Hellwig
2023-01-20 17:55 ` [PATCH v7 2/8] iov_iter: Add a function to extract a page list from an iterator David Howells
2023-01-21 13:01 ` Christoph Hellwig
2023-01-21 13:10 ` Christoph Hellwig
2023-01-21 13:30 ` David Howells
2023-01-21 13:33 ` Christoph Hellwig
2023-01-23 11:28 ` David Hildenbrand
2023-01-23 11:51 ` David Howells
2023-01-23 13:11 ` David Hildenbrand
2023-01-23 13:19 ` David Howells
2023-01-23 13:24 ` David Hildenbrand
2023-01-23 19:56 ` John Hubbard
2023-01-26 22:15 ` Al Viro
2023-01-26 23:41 ` David Hildenbrand
2023-01-27 0:05 ` David Howells
2023-01-27 0:20 ` David Hildenbrand
2023-01-23 13:38 ` David Howells
2023-01-23 14:20 ` David Hildenbrand
2023-01-23 14:48 ` Christoph Hellwig
2023-01-23 16:11 ` Jan Kara
2023-01-23 16:17 ` Christoph Hellwig
2023-01-23 23:07 ` John Hubbard
2023-01-24 5:57 ` Christoph Hellwig
2023-01-24 6:55 ` John Hubbard
2023-01-23 12:00 ` David Howells
2023-01-20 17:55 ` [PATCH v7 3/8] mm: Provide a helper to drop a pin/ref on a page David Howells
2023-01-20 17:55 ` [PATCH v7 4/8] block: Rename BIO_NO_PAGE_REF to BIO_PAGE_REFFED and invert the meaning David Howells
2023-01-21 13:04 ` Christoph Hellwig
2023-01-23 9:38 ` David Howells
2023-01-23 9:56 ` Christoph Hellwig
2023-01-20 17:55 ` [PATCH v7 5/8] block: Add BIO_PAGE_PINNED David Howells
2023-01-21 13:05 ` Christoph Hellwig
2023-01-20 17:55 ` [PATCH v7 6/8] block: Make bio structs pin pages rather than ref'ing if appropriate David Howells
2023-01-21 13:07 ` Christoph Hellwig
2023-01-23 11:28 ` David Howells
2023-01-23 14:49 ` Christoph Hellwig
2023-01-20 17:55 ` [PATCH v7 7/8] block: Fix bio_flagged() so that gcc can better optimise it David Howells
2023-01-20 17:55 ` [PATCH v7 8/8] mm: Renumber FOLL_GET and FOLL_PIN down David Howells
2023-01-20 18:59 ` Matthew Wilcox
2023-01-20 19:18 ` David Howells
2023-01-23 16:31 ` [PATCH v7 0/8] iov_iter: Improve page extraction (ref, pin or just list) Matthew Wilcox
2023-01-23 16:42 ` Jan Kara
2023-01-23 17:33 ` Matthew Wilcox
2023-01-23 22:53 ` John Hubbard
2023-01-24 10:29 ` Jan Kara
2023-01-24 13:21 ` Christoph Hellwig
2023-01-23 16:38 ` David Howells
2023-01-23 16:42 ` Matthew Wilcox
2023-01-23 17:25 ` Jan Kara [this message]
2023-01-24 10:24 ` David Hildenbrand
2023-01-23 17:19 ` David Howells
2023-01-23 18:04 ` Matthew Wilcox
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=20230123172529.woo34hnycrn7xhwk@quack3 \
--to=jack@suse.cz \
--cc=axboe@kernel.dk \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=jhubbard@nvidia.com \
--cc=jlayton@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).