public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC] COMPAT_IPMICTL_RECEIVE_MSG semantics
@ 2017-06-26 20:21 Al Viro
  0 siblings, 0 replies; only message in thread
From: Al Viro @ 2017-06-26 20:21 UTC (permalink / raw)
  To: Corey Minyard; +Cc: linux-kernel

	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?

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2017-06-26 20:21 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-06-26 20:21 [RFC] COMPAT_IPMICTL_RECEIVE_MSG semantics Al Viro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox