mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Aleksandr Nogikh <nogikh@google.com>
To: kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org
Cc: dvyukov@google.com, andreyknvl@gmail.com, elver@google.com,
	glider@google.com, tarasmadan@google.com, bigeasy@linutronix.de,
	nogikh@google.com
Subject: [PATCH v2 0/2] kcov: improve mmap processing
Date: Tue, 21 Dec 2021 17:03:46 +0000	[thread overview]
Message-ID: <20211221170348.1113266-1-nogikh@google.com> (raw)

Subsequent mmaps of the same kcov descriptor currently do not update the
virtual memory of the task and yet return 0 (success). This is
counter-intuitive and may lead to unexpected memory access errors.

Also, this unnecessarily limits the functionality of kcov to only the
simplest usage scenarios. Kcov instances are effectively forever attached
to their first address spaces and it becomes impossible to e.g. reuse the
same kcov handle in forked child processes without mmapping the memory
first. This is exactly what we tried to do in syzkaller and
inadvertently came upon this behavior.

This patch series addresses the problem described above.

v1 of the patch:
https://lore.kernel.org/lkml/20211220152153.910990-1-nogikh@google.com/

Changes from v1:
- Split into 2 commits.
- Minor coding style changes.

Aleksandr Nogikh (2):
  kcov: split ioctl handling into locked and unlocked parts
  kcov: properly handle subsequent mmap calls

 kernel/kcov.c | 99 +++++++++++++++++++++++++++++----------------------
 1 file changed, 57 insertions(+), 42 deletions(-)

-- 
2.34.1.307.g9b7440fafd-goog


             reply	other threads:[~2021-12-21 17:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-21 17:03 Aleksandr Nogikh [this message]
2021-12-21 17:03 ` [PATCH v2 1/2] kcov: split ioctl handling into locked and unlocked parts Aleksandr Nogikh
2021-12-21 20:19   ` Marco Elver
2021-12-22 12:28     ` Aleksandr Nogikh
2021-12-21 17:03 ` [PATCH v2 2/2] kcov: properly handle subsequent mmap calls Aleksandr Nogikh

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=20211221170348.1113266-1-nogikh@google.com \
    --to=nogikh@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@gmail.com \
    --cc=bigeasy@linutronix.de \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tarasmadan@google.com \
    /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®