From patchwork Tue Feb 25 06:41:11 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "fan.du" X-Patchwork-Id: 323842 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 9B3682C0172 for ; Tue, 25 Feb 2014 17:41:37 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751463AbaBYGld (ORCPT ); Tue, 25 Feb 2014 01:41:33 -0500 Received: from mail.windriver.com ([147.11.1.11]:63701 "EHLO mail.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750898AbaBYGlc (ORCPT ); Tue, 25 Feb 2014 01:41:32 -0500 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail.windriver.com (8.14.5/8.14.5) with ESMTP id s1P6fRJ5008441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 22:41:27 -0800 (PST) Received: from [128.224.162.147] (128.224.162.147) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server (TLS) id 14.2.347.0; Mon, 24 Feb 2014 22:41:26 -0800 Message-ID: <530C3B07.3090406@windriver.com> Date: Tue, 25 Feb 2014 14:41:11 +0800 From: Fan Du User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Steffen Klassert CC: , Subject: Re: [PATCH net-next] xfrm: Correctly parse netlink msg from 32bits ip command on 64bits host References: <1392801176-2656-1-git-send-email-fan.du@windriver.com> <20140220095934.GF32371@secunet.com> In-Reply-To: <20140220095934.GF32371@secunet.com> X-Originating-IP: [128.224.162.147] Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 2014年02月20日 17:59, Steffen Klassert wrote: > For now I think we should just refuse to do anything if someone tries > to configure ipsec with 32 bit tools on a 64 bit machine. I'm fine with your point, and it would be a good choice to inform user about this behavior other than just creating non-working SA and SP for user. From 873812ec0fe8738f476de58a217e58ec47665180 Mon Sep 17 00:00:00 2001 From: Fan Du Date: Tue, 25 Feb 2014 14:34:41 +0800 Subject: [PATCH net-next] xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host structure like xfrm_usersa_info or xfrm_userpolicy_info has different sizeof when compiled as 32bits and 64bits due to not appending pack attribute in their definition. This will result in broken SA and SP information when user trying to configure them through netlink interface. Before forging a compatibility layer like we have it for system calls to map this correct. Inform user land about this situation instead of keeping silent, then the upper test scripts could behave accordingly. Signed-off-by: Fan Du --- net/xfrm/xfrm_user.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c index 1ae3ec7..0249712 100644 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -2347,6 +2347,10 @@ static int xfrm_user_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh) const struct xfrm_link *link; int type, err; +#ifdef CONFIG_COMPAT + if (is_compat_task()) + return -EPERM; +#endif type = nlh->nlmsg_type; if (type > XFRM_MSG_MAX) return -EINVAL;