Re: [PATCH] net: Fix invalid ip_route_output_ports() call

[Steffen Klassert <steffen.klassert@secunet.com>]

On Mon, Mar 20, 2023 at 10:08:03PM -0700, Hyunwoo Kim wrote:
> On Mon, Mar 20, 2023 at 08:17:15PM -0700, Eric Dumazet wrote:
> > On Mon, Mar 20, 2023 at 7:49 PM Hyunwoo Kim <v4bel@theori.io> wrote:
> 
> struct rtable *ip_route_output_flow(struct net *net, struct flowi4 *flp4,
> 				    const struct sock *sk)
> {
> 	struct rtable *rt = __ip_route_output_key(net, flp4);
> 
> 	if (IS_ERR(rt))
> 		return rt;
> 
> 	if (flp4->flowi4_proto) {
> 		flp4->flowi4_oif = rt->dst.dev->ifindex;
> 		rt = (struct rtable *)xfrm_lookup_route(net, &rt->dst,
> 							flowi4_to_flowi(flp4),  // <===[4]
> 							sk, 0);
> 	}
> 
> 	return rt;
> }
> EXPORT_SYMBOL_GPL(ip_route_output_flow);
> ```
> This is the cause of the stack OOB. Because we calculated the struct flowi pointer address based on struct flowi4 declared as a stack variable, 
> if we accessed a member of flowi that exceeds the size of flowi4, we would get an OOB.
> 
> 
> Finally, xfrm_state_find()[5] uses daddr, which is a pointer to `&fl->u.ip4.saddr`.
> Here, the encap_family variable can be entered by the user using the netlink socket. 
> If the user chose AF_INET6 instead of AF_INET, the xfrm_dst_hash() function would be called on an AF_INET6 basis[6], 
> which could cause an OOB in the `struct flowi4 fl4` variable of igmpv3_newpack()[2].

Thanks for the great analysis!

Looks like a missing sanity check when the policy gets inserted.
Can you send the output of 'ip x p' for that policy?