re: xfrm: Assign the inner mode output function to the dst

re: xfrm: Assign the inner mode output function to the dst

[Dan Carpenter]

[ Hi.  Smatch is complaining about a really old patch here.  Sorry
  for that.  I will fix it to detect better which warnings are new
  but I saw that there was some work done in this function recently
  so I decided to send this email anyway.  --dan ]

Hello Steffen Klassert,

This is a semi-automatic email about new static checker warnings.

The patch 43a4dea4c9d4: "xfrm: Assign the inner mode output function 
to the dst entry" from May 9, 2011, leads to the following Smatch 
complaint:

net/ipv6/xfrm6_output.c +154 __xfrm6_output()
	 error: we previously assumed 'x' could be null (see line 149)

net/ipv6/xfrm6_output.c
   148	
   149		if ((x && x->props.mode = XFRM_MODE_TUNNEL) &&
                     ^
Check.

   150		    ((skb->len > mtu && !skb_is_gso(skb)) ||
   151			dst_allfrag(skb_dst(skb)))) {
   152				return ip6_fragment(skb, x->outer_mode->afinfo->output_finish);
   153		}
   154		return x->outer_mode->afinfo->output_finish(skb);
                       ^^^
New dereference.

   155	}
   156	

regards,
dan carpenter

Re: xfrm: Assign the inner mode output function to the dst

[Steffen Klassert]

Hi.

On Fri, Oct 28, 2011 at 06:18:24PM +0300, Dan Carpenter wrote:
> [ Hi.  Smatch is complaining about a really old patch here.  Sorry
>   for that.  I will fix it to detect better which warnings are new
>   but I saw that there was some work done in this function recently
>   so I decided to send this email anyway.  --dan ]
> 
> Hello Steffen Klassert,
> 
> This is a semi-automatic email about new static checker warnings.
> 
> The patch 43a4dea4c9d4: "xfrm: Assign the inner mode output function 
> to the dst entry" from May 9, 2011, leads to the following Smatch 
> complaint:
> 
> net/ipv6/xfrm6_output.c +154 __xfrm6_output()
> 	 error: we previously assumed 'x' could be null (see line 149)
> 
> net/ipv6/xfrm6_output.c
>    148	
>    149		if ((x && x->props.mode = XFRM_MODE_TUNNEL) &&
>                      ^

x can't be null here. It would be a bug if __xfrm6_output() is called without
a xfrm_state attached to the skb. I think we can just remove this null check.