From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751758AbdFZUVJ (ORCPT ); Mon, 26 Jun 2017 16:21:09 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:47220 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751403AbdFZUVE (ORCPT ); Mon, 26 Jun 2017 16:21:04 -0400 Date: Mon, 26 Jun 2017 21:21:02 +0100 From: Al Viro To: Corey Minyard Cc: linux-kernel@vger.kernel.org Subject: [RFC] COMPAT_IPMICTL_RECEIVE_MSG semantics Message-ID: <20170626202102.GB10672@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?