bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	KP Singh <kpsingh@kernel.org>
Cc: bpf <bpf@vger.kernel.org>, Gilad Reti <gilad.reti@gmail.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>
Subject: Re: [PATCH bpf v3 1/3] bpf: update local storage test to check handling of null ptrs
Date: Mon, 1 Feb 2021 23:10:21 -0800	[thread overview]
Message-ID: <c66fdb89-db8e-8a7e-f1b6-0905e841d855@fb.com> (raw)
In-Reply-To: <CAEf4BzYBAKNRvGCweY0NyDQ751ChB4QKt41cVbU+VRTsDAcpGg@mail.gmail.com>



On 2/1/21 10:37 PM, Andrii Nakryiko wrote:
> On Sun, Jan 31, 2021 at 5:09 PM KP Singh <kpsingh@kernel.org> wrote:
>>
>> On Thu, Jan 28, 2021 at 2:46 AM Andrii Nakryiko
>> <andrii.nakryiko@gmail.com> wrote:
>>>
>>> On Mon, Jan 11, 2021 at 11:55 PM KP Singh <kpsingh@kernel.org> wrote:
>>>>
>>>> It was found in [1] that bpf_inode_storage_get helper did not check
>>>> the nullness of the passed owner ptr which caused an oops when
>>>> dereferenced. This change incorporates the example suggested in [1] into
>>>> the local storage selftest.
>>>>
>>>> The test is updated to create a temporary directory instead of just
>>>> using a tempfile. In order to replicate the issue this copied rm binary
>>>> is renamed tiggering the inode_rename with a null pointer for the
>>>> new_inode. The logic to verify the setting and deletion of the inode
>>>> local storage of the old inode is also moved to this LSM hook.
>>>>
>>>> The change also removes the copy_rm function and simply shells out
>>>> to copy files and recursively delete directories and consolidates the
>>>> logic of setting the initial inode storage to the bprm_committed_creds
>>>> hook and removes the file_open hook.
>>>>
>>>> [1]: https://lore.kernel.org/bpf/CANaYP3HWkH91SN=wTNO9FL_2ztHfqcXKX38SSE-JJ2voh+vssw@mail.gmail.com
>>>>
>>>> Suggested-by: Gilad Reti <gilad.reti@gmail.com>
>>>> Acked-by: Yonghong Song <yhs@fb.com>
>>>> Signed-off-by: KP Singh <kpsingh@kernel.org>
>>>> ---
>>>
>>> Hi KP,
>>>
>>> I'm getting a compilation warning when building selftests. Can you
>>> please take a look and send a fix? Thanks!
>>>
>>> /data/users/andriin/linux/tools/testing/selftests/bpf/prog_tests/test_local_storage.c:
>>> In function ‘test_test_local_storage’:
>>> /data/users/andriin/linux/tools/testing/selftests/bpf/prog_tests/test_local_storage.c:143:52:
>>> warning: ‘/copy_of_rm’ directive output may be truncated writing 11
>>> bytes into a region of size between 1 and 64 [-Wformat-truncation=]
>>>    143 |  snprintf(tmp_exec_path, sizeof(tmp_exec_path), "%s/copy_of_rm",
>>>        |                                                    ^~~~~~~~~~~
>>> /data/users/andriin/linux/tools/testing/selftests/bpf/prog_tests/test_local_storage.c:143:2:
>>> note: ‘snprintf’ output between 12 and 75 bytes into a destination of
>>> size 64
>>>    143 |  snprintf(tmp_exec_path, sizeof(tmp_exec_path), "%s/copy_of_rm",
>>>        |  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>    144 |    tmp_dir_path);
>>>        |    ~~~~~~~~~~~~~
>>>
>>
>> I don't seem to get this warning, so maybe we are using different compilers.
>>
>> Mine is gcc 10.2.1 20201224 (from debian)
> 
> Funny enough, but I can't repro it locally anymore. I have gcc 10.2.0.
> But your suggested fix below does look like a correct one, so feel
> free to send it over, thanks!
> 
>>
>> That said, I understand why it's complaining, it's for something that
>> cannot really happen:
>>
>> tmp_dir_path cannot be 64 because we actually know its length so the
>> tmp_exec_path cannot really overflow 64 bytes.
>>
>> Can you check if the following patch makes it go away?
>>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/test_local_storage.c
>> b/tools/testing/selftests/bpf/prog_tests/test_local_storage.c
>> index 3bfcf00c0a67..d2c16eaae367 100644
>> --- a/tools/testing/selftests/bpf/prog_tests/test_local_storage.c
>> +++ b/tools/testing/selftests/bpf/prog_tests/test_local_storage.c
>> @@ -113,7 +113,7 @@ static bool check_syscall_operations(int map_fd, int obj_fd)
>>
>>   void test_test_local_storage(void)
>>   {
>> -       char tmp_dir_path[64] = "/tmp/local_storageXXXXXX";
>> +       char tmp_dir_path[] = "/tmp/local_storageXXXXXX";
>>          int err, serv_sk = -1, task_fd = -1, rm_fd = -1;
>>          struct local_storage *skel = NULL;
>>          char tmp_exec_path[64];
>>
>> If so, I can send you a fix.

I have gcc 8.2.1 which can reproduce the issue.
With the above fix, the warning is gone. So yes, please send
a fix. Thanks!

>>
>> - KP
>>
>>>
>>>>   .../bpf/prog_tests/test_local_storage.c       | 96 +++++--------------
>>>>   .../selftests/bpf/progs/local_storage.c       | 62 ++++++------
>>>>   2 files changed, 61 insertions(+), 97 deletions(-)
>>>>
>>>
>>> [...]

  reply	other threads:[~2021-02-02  7:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-12  7:55 [PATCH bpf v3 0/3] Fix local storage helper OOPs KP Singh
2021-01-12  7:55 ` [PATCH bpf v3 1/3] bpf: update local storage test to check handling of null ptrs KP Singh
2021-01-28  1:46   ` Andrii Nakryiko
2021-02-01  1:09     ` KP Singh
2021-02-02  6:37       ` Andrii Nakryiko
2021-02-02  7:10         ` Yonghong Song [this message]
2021-01-12  7:55 ` [PATCH bpf v3 2/3] bpf: local storage helpers should check nullness of owner ptr passed KP Singh
2021-01-12  7:55 ` [PATCH bpf v3 3/3] bpf: Fix typo in bpf_inode_storage.c KP Singh
2021-01-12 15:20 ` [PATCH bpf v3 0/3] Fix local storage helper OOPs patchwork-bot+netdevbpf

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=c66fdb89-db8e-8a7e-f1b6-0905e841d855@fb.com \
    --to=yhs@fb.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=gilad.reti@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@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;
as well as URLs for NNTP newsgroup(s).