From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
bpf@vger.kernel.org
Subject: Re: [PATCH bpf] libbpf: Fix signedness confusion when using libbpf_is_mem_zeroed()
Date: Thu, 15 Dec 2022 00:18:33 +0100 [thread overview]
Message-ID: <87zgbpefqu.fsf@toke.dk> (raw)
In-Reply-To: <CAEf4BzZOYD7YEgzWz08Q7sZ8wMVf+kiP7Aw1tm4_wN0_mNDrhA@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> On Tue, Dec 13, 2022 at 5:01 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> The commit in the Fixes tag refactored the check for zeroed memory in
>> libbpf_validate_opts() into a separate libbpf_is_mem_zeroed() function.
>> This function has a 'len' argument of the signed 'ssize_t' type, which in
>> both callers is computed by subtracting two unsigned size_t values from
>> each other. In both subtractions, one of the values being subtracted is
>> converted to 'ssize_t', while the other stays 'size_t'.
>>
>> The problem with this is that, because both sizes are the same
>> rank ('ssize_t' is defined as 'long' and 'size_t' is 'unsigned long'), the
>> type of the mixed-sign arithmetic operation ends up being converted back to
>> unsigned. This means it can underflow if the user-specified size in
>> opts->sz is smaller than the size of the type as defined by libbpf. If that
>> happens, it will cause out-of-bounds reads in libbpf_is_mem_zeroed().
>
> hmm... but libbpf_is_mem_zeroed expects signed ssize_t, so that
> "underflow" will turn into a proper negative ssize_t value. What am I
> missing? Seems to be working fine:
>
> $ cat test.c
> #include <stdio.h>
>
> void testit(ssize_t sz)
> {
> printf("%zd\n", sz);
> }
>
> int main()
> {
> ssize_t slarge = 100;
> size_t ularge = 100;
> ssize_t ssmall = 50;
> size_t usmall = 50;
>
> testit(ssmall - slarge);
> testit(ssmall - ularge);
> testit(usmall - slarge);
> testit(usmall - ularge);
> }
>
> $ cc test.c && ./a.out
> -50
> -50
> -50
> -50
Hmnm, yeah, you're right. Not sure how I managed to convince myself
there was an actual bug there :(
Sorry for the noise!
-Toke
prev parent reply other threads:[~2022-12-14 23:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 1:00 [PATCH bpf] libbpf: Fix signedness confusion when using libbpf_is_mem_zeroed() Toke Høiland-Jørgensen
2022-12-14 19:30 ` Andrii Nakryiko
2022-12-14 23:18 ` Toke Høiland-Jørgensen [this message]
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=87zgbpefqu.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=yhs@fb.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 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.