linux-kernel - Re: [PATCH 22/22] signal: Unify and correct copy_siginfo_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180119180322.GK13338@ZenIV.linux.org.uk>
Date:   Fri, 19 Jan 2018 18:03:22 +0000
From:   Al Viro <viro@...IV.linux.org.uk>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     linux-kernel@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>,
        linux-arch@...r.kernel.org
Subject: Re: [PATCH 22/22] signal: Unify and correct copy_siginfo_to_user32

On Mon, Jan 15, 2018 at 06:40:09PM -0600, Eric W. Biederman wrote:
> Among the existing architecture specific versions of
> copy_siginfo_to_user32 there are several different implementation
> problems.  Some architectures fail to handle all of the cases in in
> the siginfo union.  Some architectures perform a blind copy of the
> siginfo union when the si_code is negative.  A blind copy suggests the
> data is expected to be in 32bit siginfo format, which means that
> receiving such a signal via signalfd won't work, or that the data is
> in 64bit siginfo and the code is copying nonsense to userspace.

Huh?  Negative si_code comes from rt_sigqueueinfo(2); in that case
the sucker is supposed to pass user-supplied opaque chunk of data
in ->_sifields._pad.  "Copy everything when ->si_code is negative"
is exactly the right behaviour.  Failing to copy it out (and in, for
copy_siginfo_from_user32()) is a bug.

32bit tasks should behave on 64bit host like they would on 32bit one
when we have biarch compat.  And "application using sigqueueinfo() to
pass data might be using different layouts of the payload" is not
an excuse for failing to transmit it in the first place.