linux-kernel - [RFC] COMPAT_IPMICTL_RECEIVE

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>] [day] [month] [year] [list]

Message-ID: <20170626202102.GB10672@ZenIV.linux.org.uk>
Date:   Mon, 26 Jun 2017 21:21:02 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Corey Minyard <minyard@....org>
Cc:     linux-kernel@...r.kernel.org
Subject: [RFC] COMPAT_IPMICTL_RECEIVE_MSG semantics

	There's something odd about IPMICTL_RECEIVE_MSG and
its compat counterpart.  The former checks if copying
struct ipmi_recv back to userland succeeds and put the
message back into queue on failure.  The latter does not;
it copies native structure to userland stack and then
(after having freed msg) copies it back to kernel, converts
to 32bit analogue and copies _that_ to userland.

	To trigger that just use it with ipmi_recv sitting
in read-only mapping; native ioctl will fail with EFAULT
and requeue the message, compat one will fail with EFAULT
and discard the sucker.

	Do we really care in either case?  If not, it would
be easier to leave copyout to after freeing msg and if it
fails, so be it.  Compat would avoid all the dances with
copying in, copying native out, copying it back in, copying
32bit out, stack allocations, etc.

	If we do, we need to do conversion and final copyout
before freeing msg.  Also not hard to do.  Either way, the
current variant is inconsistent.  Which way would you prefer
it to go?