netdev - Re: [PATCH] net: Fix invalid ip_route_output

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

Message-ID: <ZBmWqBC8yKp3doYs@gauss3.secunet.de>
Date:   Tue, 21 Mar 2023 12:36:08 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Hyunwoo Kim <v4bel@...ori.io>
CC:     Eric Dumazet <edumazet@...gle.com>,
        Taehee Yoo <ap420073@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Dmitry Kozlov <xeb@...l.ru>,
        David Ahern <dsahern@...nel.org>, <tudordana@...gle.com>,
        <netdev@...r.kernel.org>, <imv4bel@...il.com>
Subject: Re: [PATCH] net: Fix invalid ip_route_output_ports() call

On Tue, Mar 21, 2023 at 04:14:30AM -0700, Hyunwoo Kim wrote:
> On Tue, Mar 21, 2023 at 11:52:02AM +0100, Steffen Klassert wrote:
> > 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@...ori.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?
> 
> I'm not sure what 'ip x p' means, as my understanding of XFRM is limited, sorry.
> 
> Instead, here is the (dirty) code I used to trigger this:

Thanks, you code created a policy with IPv4 selectors and
IPv6 transport mode templates:

src 255.1.0.0/0 dst 0.0.0.0/0
        dir out priority 0 ptype main
        mark 0/0x6
        tmpl src 0.0.0.0 dst 0.0.0.0
                proto comp reqid 0 mode beet
                level 16
        tmpl src fc00:: dst e000:2::
                proto ah reqid 0 mode tunnel
                level 32
        tmpl src ac14:14bb:: dst ac14:14fa::
                proto route2 reqid 0 mode transport
                level 3
        tmpl src :: dst 2001::1
                proto ah reqid 0 mode in_trigger
        tmpl src ff01::1 dst 7f00:1::
                proto comp reqid 0 mode transport

This is an invalid configuration. I'm working on a fix.

Thanks again!