netdev - Re: Kernel Panic with vti Interfaces

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

Message-ID: <20150226114052.GB20631@secunet.com>
Date:	Thu, 26 Feb 2015 12:40:53 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Andre Valentin <avalentin@...cant.net>
CC:	<herbert@...dor.apana.org.au>, <davem@...emloft.net>,
	<netdev@...r.kernel.org>
Subject: Re: Kernel Panic with vti Interfaces

Ccing netdev.

On Tue, Feb 24, 2015 at 11:03:15AM +0100, Andre Valentin wrote:
> Hi!
> 
> I noticed kernel panics on my mips platform while using vti interfaces. After taking a deeper look,
> it seems that if the SA changes or the WAN interface changes I get this error. I could find the
> code where it crashes. But I'm not sure if my solution is right. Perhaps you could take a look.
> 


> From: =?utf8?q?Andr=C3=A9=20Valentin?= <avalentin@...cant.net>
> Date: Tue, 24 Feb 2015 00:24:08 +0100
> Subject: [PATCH] kernel: fix xfrm tunnel checks if vti parent SA/device is in transition
> 
> The outer_mode check results in the error if it is not checked for validity.
> Because I do not know how to handle this situation, I decided to return
> -EINVAL if outer_mode is null.
> 
> ---
>  .../618-net_fixup_xfrm_tunnel_check.patch          |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
>  create mode 100644 target/linux/generic/patches-3.18/618-net_fixup_xfrm_tunnel_check.patch
> 
> diff --git a/target/linux/generic/patches-3.18/618-net_fixup_xfrm_tunnel_check.patch b/target/linux/generic/patches-3.18/618-net_fixup_xfrm_tunnel_check.patch
> new file mode 100644
> index 0000000..f79b1f7
> --- /dev/null
> +++ b/target/linux/generic/patches-3.18/618-net_fixup_xfrm_tunnel_check.patch
> @@ -0,0 +1,16 @@
> +--- a/include/net/xfrm.h	2015-02-11 08:01:12.000000000 +0100
> ++++ b/include/net/xfrm.h	2015-02-24 00:04:03.102709830 +0100
> +@@ -1805,8 +1805,12 @@ static inline int xfrm_tunnel_check(stru
> + 			tunnel = true;
> + 		break;
> + 	}
> +-	if (tunnel && !(x->outer_mode->flags & XFRM_MODE_FLAG_TUNNEL))
> ++	if (tunnel && !x->outer_mode) {
> ++                printk(KERN_NOTICE "xfrm_tunnel_check: outer_mode is 0, returning -EINVAL\n");
> + 		return -EINVAL;

Returning -EINVAL here would just paper over the real bug.

We should never get a state without outer_mode from a lookup.
Using such a state will lead to a crash anyway, even without
using vti devices. Looks like you get an uninitialized state
with the lookup. When a xfrm_state is initialized, the outer
mode is added and after that inserted to the lookup tables.
It should never loose the outer_mode pointer.

I have never seen this, is the patch above the only locally
applied patch?

Is this reproducible?

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html