Re: stable-rc: ptrace: peeksiginfo failed on 4.19, 4.14, 4.9 and 4.4

[ebiederm@xmission.com (Eric W. Biederman)]

Naresh Kamboju <naresh.kamboju@linaro.org> writes:

> selftests: ptrace: peeksiginfo failed on x86_64, i386, arm64 and arm.
> FAILED on stable rc branches 4.19, 4.14, 4.9 and 4.4.
> PASS on mainline, next and 5.1 stable rc branch.

Greg.

Looking in my email it appears 4.19, 4.14, 4.9, and 4.4 patches are
missing the "found=1" line from the original change.   This explains
the test failure.

Can you handle this?

Thanks,
Eric


> Test output:
> ------------------
> cd /opt/kselftests/mainline/ptrace
> ./peeksiginfo
> Error (peeksiginfo.c:143): Only 0 signals were read
>
> The git bisect show that below commit caused this test to fail.
>
>  git bisect bad
> 5b6b0eac235ef1f915f24eda6d501a754022cbf0 is the first bad commit
> commit 5b6b0eac235ef1f915f24eda6d501a754022cbf0
> Author: Eric W. Biederman <ebiederm@xmission.com>
> Date:   Tue May 28 18:46:37 2019 -0500
>
>     signal/ptrace: Don't leak unitialized kernel memory with PTRACE_PEEK_SIGINFO
>
>     commit f6e2aa91a46d2bc79fce9b93a988dbe7655c90c0 upstream.
>
>     Recently syzbot in conjunction with KMSAN reported that
>     ptrace_peek_siginfo can copy an uninitialized siginfo to userspace.
>     Inspecting ptrace_peek_siginfo confirms this.
>
>     The problem is that off when initialized from args.off can be
>     initialized to a negaive value.  At which point the "if (off >= 0)"
>     test to see if off became negative fails because off started off
>     negative.
>
>     Prevent the core problem by adding a variable found that is only true
>     if a siginfo is found and copied to a temporary in preparation for
>     being copied to userspace.
>
>     Prevent args.off from being truncated when being assigned to off by
>     testing that off is <= the maximum possible value of off.  Convert off
>     to an unsigned long so that we should not have to truncate args.off,
>     we have well defined overflow behavior so if we add another check we
>     won't risk fighting undefined compiler behavior, and so that we have a
>     type whose maximum value is easy to test for.
>
>     Cc: Andrei Vagin <avagin@gmail.com>
>     Cc: stable@vger.kernel.org
>     Reported-by: syzbot+0d602a1b0d8c95bdf299@syzkaller.appspotmail.com
>     Fixes: 84c751bd4aeb ("ptrace: add ability to retrieve signals
> without removing from a queue (v4)")
>     Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> :040000 040000 ff9f3109f210274d0b87851d226c35e7305ce44a
> b36de2c855fe2a0b332f145f0966dc1a0304d4bd M kernel
>
> Test case link,
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/ptrace/peeksiginfo.c#n143
>
> Test output log link,
> https://lkft.validation.linaro.org/scheduler/job/777223#L1084
>
> Test results comparison on different branches,
> https://qa-reports.linaro.org/_/comparetest/?project=22&project=6&project=58&project=135&project=40&project=23&project=167&suite=kselftest&test=ptrace_peeksiginfo
>
> Best regards
> Naresh Kamboju