From: Shuah Khan <shuah@kernel.org>
To: Dominik Brodowski <linux@dominikbrodowski.net>,
Ingo Molnar <mingo@kernel.org>,
linux-kselftest@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
Andrew Lutomirski <luto@kernel.org>,
Shuah Khan <shuahkh@osg.samsung.com>,
Shuah Khan <shuah@kernel.org>
Subject: Re: [PATCH] selftests/x86: clarify that there is no buffer overflow on sscanf usage
Date: Mon, 12 Feb 2018 10:58:17 -0700 [thread overview]
Message-ID: <14b56564-cfa0-e6aa-7f5d-57431be7eb03@kernel.org> (raw)
In-Reply-To: <20180211205924.GA23210@light.dominikbrodowski.net>
On 02/11/2018 01:59 PM, Dominik Brodowski wrote:
>
> Suggested-by: Ingo Molnar <mingo@kernel.org>
> CC: Andy Lutomirski <luto@kernel.org>
> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
>
Missing commit log. Please add one.
thanks,
-- Shuah
> ---
>
>> Yeah, probably - but still, this connection and the sscanf() guarantee is not
>> obvious at first sight, so please improve this to derive from the same value
>> (define a LINE_MAX size or such), plus maybe add a comment to the sscanf() line
>> that this is safe because strlen(name) >= strlen(line).
>
> Sounds reasonable. Patch (which applies on top of the five patches for
> selftests/x86 I sent out earlier today) is attached.
>
> Thanks,
> Dominik
>
> diff --git a/tools/testing/selftests/x86/test_vdso.c b/tools/testing/selftests/x86/test_vdso.c
> index 558c8207e7b9..7ade625f10ed 100644
> --- a/tools/testing/selftests/x86/test_vdso.c
> +++ b/tools/testing/selftests/x86/test_vdso.c
> @@ -26,6 +26,9 @@
> # endif
> #endif
>
> +/* max length of lines in /proc/self/maps - anything longer is skipped here */
> +#define MAPS_LINE_LEN 128
> +
> int nerrs = 0;
>
> typedef long (*getcpu_t)(unsigned *, unsigned *, void *);
> @@ -37,17 +40,19 @@ static void *vsyscall_getcpu(void)
> {
> #ifdef __x86_64__
> FILE *maps;
> - char line[128];
> + char line[MAPS_LINE_LEN];
> bool found = false;
>
> maps = fopen("/proc/self/maps", "r");
> if (!maps) /* might still be present, but ignore it here, as we test vDSO not vsyscall */
> return NULL;
>
> - while (fgets(line, sizeof(line), maps)) {
> + while (fgets(line, MAPS_LINE_LEN, maps)) {
> char r, x;
> void *start, *end;
> - char name[128];
> + char name[MAPS_LINE_LEN];
> +
> + /* sscanf is safe here as strlen(name) >= strlen(line) */
> if (sscanf(line, "%p-%p %c-%cp %*x %*x:%*x %*u %s",
> &start, &end, &r, &x, name) != 5)
> continue;
> diff --git a/tools/testing/selftests/x86/test_vsyscall.c b/tools/testing/selftests/x86/test_vsyscall.c
> index 7a744fa7b786..ee92e4727f18 100644
> --- a/tools/testing/selftests/x86/test_vsyscall.c
> +++ b/tools/testing/selftests/x86/test_vsyscall.c
> @@ -33,6 +33,9 @@
> # endif
> #endif
>
> +/* max length of lines in /proc/self/maps - anything longer is skipped here */
> +#define MAPS_LINE_LEN 128
> +
> static void sethandler(int sig, void (*handler)(int, siginfo_t *, void *),
> int flags)
> {
> @@ -98,7 +101,7 @@ static int init_vsys(void)
> #ifdef __x86_64__
> int nerrs = 0;
> FILE *maps;
> - char line[128];
> + char line[MAPS_LINE_LEN];
> bool found = false;
>
> maps = fopen("/proc/self/maps", "r");
> @@ -108,10 +111,12 @@ static int init_vsys(void)
> return 0;
> }
>
> - while (fgets(line, sizeof(line), maps)) {
> + while (fgets(line, MAPS_LINE_LEN, maps)) {
> char r, x;
> void *start, *end;
> - char name[128];
> + char name[MAPS_LINE_LEN];
> +
> + /* sscanf is safe here as strlen(name) >= strlen(line) */
> if (sscanf(line, "%p-%p %c-%cp %*x %*x:%*x %*u %s",
> &start, &end, &r, &x, name) != 5)
> continue;
>
>
next prev parent reply other threads:[~2018-02-12 17:58 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-11 11:10 [PATCH 0/5] selftests/x86: fixes for !CONFIG_IA32_EMULATION and vsyscall=none Dominik Brodowski
2018-02-11 11:10 ` [PATCH 1/5] selftests/x86: 5lvl test has been moved Dominik Brodowski
2018-02-11 12:13 ` [tip:x86/urgent] selftests/x86: Fix build bug caused by the 5lvl test which has been moved to the VM directory tip-bot for Dominik Brodowski
2018-02-13 9:05 ` [tip:x86/pti] " tip-bot for Dominik Brodowski
2018-02-11 11:10 ` [PATCH 2/5] selftests/x86: fix vDSO selftest segfault for vsyscall=none Dominik Brodowski
2018-02-11 11:21 ` Ingo Molnar
2018-02-11 12:17 ` Dominik Brodowski
2018-02-11 13:00 ` Dominik Brodowski
2018-02-11 18:24 ` Ingo Molnar
2018-02-11 20:59 ` [PATCH] selftests/x86: clarify that there is no buffer overflow on sscanf usage Dominik Brodowski
2018-02-12 17:58 ` Shuah Khan [this message]
2018-02-13 9:04 ` [tip:x86/pti] selftests/x86: Clean up and document sscanf() usage tip-bot for Dominik Brodowski
2018-02-13 9:04 ` [tip:x86/pti] selftests/x86: Fix vDSO selftest segfault for vsyscall=none tip-bot for Dominik Brodowski
2018-02-11 11:10 ` [PATCH 3/5] selftests/x86: do not rely on int $0x80 in test_mremap_vdso.c Dominik Brodowski
2018-02-11 12:13 ` [tip:x86/urgent] selftests/x86: Do not rely on "int $0x80" " tip-bot for Dominik Brodowski
2018-02-13 9:06 ` [tip:x86/pti] " tip-bot for Dominik Brodowski
2018-02-11 11:10 ` [PATCH 4/5] selftests/x86: do not rely on int $0x80 in single_step_syscall.c Dominik Brodowski
2018-02-11 12:14 ` [tip:x86/urgent] selftests/x86: Do not rely on "int $0x80" " tip-bot for Dominik Brodowski
2018-02-13 9:06 ` [tip:x86/pti] " tip-bot for Ingo Molnar
2018-02-15 0:25 ` tip-bot for Dominik Brodowski
2018-02-11 11:10 ` [PATCH 5/5] selftests/x86: disable tests requiring 32bit support on pure 64bit systems Dominik Brodowski
2018-02-11 12:14 ` [tip:x86/urgent] selftests/x86: Disable tests requiring 32-bit support on pure 64-bit systems tip-bot for Dominik Brodowski
2018-02-13 9:07 ` [tip:x86/pti] " tip-bot for Ingo Molnar
2018-02-15 0:25 ` tip-bot for Dominik Brodowski
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=14b56564-cfa0-e6aa-7f5d-57431be7eb03@kernel.org \
--to=shuah@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=shuahkh@osg.samsung.com \
--cc=x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome