From: Alexey Dobriyan <adobriyan@gmail.com>
To: Alexey Izbyshev <izbyshev@ispras.ru>
Cc: Oleg Nesterov <oleg@redhat.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
security@kernel.org
Subject: Re: [PATCH] proc: Fix uninitialized byte read in get_mm_cmdline()
Date: Sat, 13 Jul 2019 10:26:06 +0300 [thread overview]
Message-ID: <20190713072606.GA23167@avx2> (raw)
In-Reply-To: <3de2d71b-37be-6238-7fd8-0a40c9b94a98@ispras.ru>
On Fri, Jul 12, 2019 at 09:43:03PM +0300, Alexey Izbyshev wrote:
> On 7/12/19 8:46 PM, Alexey Dobriyan wrote:
> > On Fri, Jul 12, 2019 at 06:36:26PM +0200, Oleg Nesterov wrote:
> >> On 07/12, Alexey Izbyshev wrote:
> >>>
> >>> --- a/fs/proc/base.c
> >>> +++ b/fs/proc/base.c
> >>> @@ -275,6 +275,8 @@ static ssize_t get_mm_cmdline(struct mm_struct *mm, char __user *buf,
> >>> if (got <= offset)
> >>> break;
> >>> got -= offset;
> >>> + if (got < size)
> >>> + size = got;
> >>
> >> Acked-by: Oleg Nesterov <oleg@redhat.com>
> >
> > The proper fix to all /proc/*/cmdline problems is to revert
> >
> > f5b65348fd77839b50e79bc0a5e536832ea52d8d
> > proc: fix missing final NUL in get_mm_cmdline() rewrite
> >
> > 5ab8271899658042fabc5ae7e6a99066a210bc0e
> > fs/proc: simplify and clarify get_mm_cmdline() function
> >
> Should this be interpreted as an actual suggestion to revert the patches,
> fix the conflicts, test and submit them, or is this more like thinking out
> loud?
Of course! Do you have a reproducer?
> In the former case, will it be OK for long term branches?
For everyone.
If a rewrite causes 1 bug, 1 user visible change and a infoleak, it is
called revert.
> get_mm_cmdline() does seem easier to read for me before 5ab8271899658042.
> But it also has different semantics in corner cases, for example:
All semantics changes are recent.
> - If there is no NUL at arg_end-1, it reads only the first string in
> the combined arg/env block, and doesn't terminate it with NUL.
That's because fixed-length /proc/*/cmdline did that.
> - If there is any problem with access_remote_vm() or copy_to_user(),
> it returns -EFAULT even if some data were copied to userspace.
>
> On the other hand, 5ab8271899658042 was merged not too long ago (about a year),
> so it's possible that the current semantics isn't heavily relied upon.
next prev parent reply other threads:[~2019-07-13 7:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-12 16:09 [PATCH] proc: Fix uninitialized byte read in get_mm_cmdline() Alexey Izbyshev
2019-07-12 16:36 ` Oleg Nesterov
2019-07-12 17:46 ` Alexey Dobriyan
2019-07-12 18:43 ` Alexey Izbyshev
2019-07-12 21:17 ` Jakub Jankowski
2019-07-12 22:29 ` Alexey Izbyshev
2019-07-13 7:26 ` Alexey Dobriyan [this message]
2019-07-13 14:09 ` Alexey Izbyshev
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=20190713072606.GA23167@avx2 \
--to=adobriyan@gmail.com \
--cc=izbyshev@ispras.ru \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=security@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.