netdev - Re: [PATCH net-next] xfrm: Correctly parse netlink msg from 32bits ip command on 64bits host

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 25 Feb 2014 17:15:47 +0000
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Fan Du <fan.du@...driver.com>
Cc:	Steffen Klassert <steffen.klassert@...unet.com>,
	davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] xfrm: Correctly parse netlink msg from 32bits
 ip command on 64bits host

On Tue, 2014-02-25 at 14:41 +0800, Fan Du wrote:
> 
> 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 <fan.du@...driver.com>
> 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 <fan.du@...driver.com>
> ---
>   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;

I think this needs a log message, as it is not at all obvious that EPERM
means you ran a binary from the 'wrong' architecture.

Ben.

> +#endif
>   	type = nlh->nlmsg_type;
>   	if (type > XFRM_MSG_MAX)
>   		return -EINVAL;

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
                                                           - Albert Einstein

Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)