From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
patches@lists.linux.dev, Florian Westphal <fw@strlen.de>,
Simon Horman <horms@kernel.org>, Jakub Kicinski <kuba@kernel.org>,
Sasha Levin <sashal@kernel.org>,
syzbot+bfde3bef047a81b8fde6@syzkaller.appspotmail.com
Subject: [PATCH 5.4 02/25] net: ip_tunnel: prevent perpetual headroom growth
Date: Mon, 4 Mar 2024 21:23:38 +0000 [thread overview]
Message-ID: <20240304211535.821009358@linuxfoundation.org> (raw)
In-Reply-To: <20240304211535.741936181@linuxfoundation.org>
5.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Westphal <fw@strlen.de>
[ Upstream commit 5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f ]
syzkaller triggered following kasan splat:
BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191
[..]
kasan_report+0xda/0x110 mm/kasan/report.c:588
__skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170
skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline]
___skb_get_hash net/core/flow_dissector.c:1791 [inline]
__skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856
skb_get_hash include/linux/skbuff.h:1556 [inline]
ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748
ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
__dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592
...
ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235
ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323
..
iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82
ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831
ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564
...
The splat occurs because skb->data points past skb->head allocated area.
This is because neigh layer does:
__skb_pull(skb, skb_network_offset(skb));
... but skb_network_offset() returns a negative offset and __skb_pull()
arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.
The negative value is returned because skb->head and skb->data distance is
more than 64k and skb->network_header (u16) has wrapped around.
The bug is in the ip_tunnel infrastructure, which can cause
dev->needed_headroom to increment ad infinitum.
The syzkaller reproducer consists of packets getting routed via a gre
tunnel, and route of gre encapsulated packets pointing at another (ipip)
tunnel. The ipip encapsulation finds gre0 as next output device.
This results in the following pattern:
1). First packet is to be sent out via gre0.
Route lookup found an output device, ipip0.
2).
ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future
output device, rt.dev->needed_headroom (ipip0).
3).
ip output / start_xmit moves skb on to ipip0. which runs the same
code path again (xmit recursion).
4).
Routing step for the post-gre0-encap packet finds gre0 as output device
to use for ipip0 encapsulated packet.
tunl0->needed_headroom is then incremented based on the (already bumped)
gre0 device headroom.
This repeats for every future packet:
gre0->needed_headroom gets inflated because previous packets' ipip0 step
incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0
needed_headroom was increased.
For each subsequent packet, gre/ipip0->needed_headroom grows until
post-expand-head reallocations result in a skb->head/data distance of
more than 64k.
Once that happens, skb->network_header (u16) wraps around when
pskb_expand_head tries to make sure that skb_network_offset() is unchanged
after the headroom expansion/reallocation.
After this skb_network_offset(skb) returns a different (and negative)
result post headroom expansion.
The next trip to neigh layer (or anything else that would __skb_pull the
network header) makes skb->data point to a memory location outside
skb->head area.
v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to
prevent perpetual increase instead of dropping the headroom increment
completely.
Reported-and-tested-by: syzbot+bfde3bef047a81b8fde6@syzkaller.appspotmail.com
Closes: https://groups.google.com/g/syzkaller-bugs/c/fL9G6GtWskY/m/VKk_PR5FBAAJ
Fixes: 243aad830e8a ("ip_gre: include route header_len in max_headroom calculation")
Signed-off-by: Florian Westphal <fw@strlen.de>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://lore.kernel.org/r/20240220135606.4939-1-fw@strlen.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/ipv4/ip_tunnel.c | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 4559edad8cec5..ba1decf81fe32 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -547,6 +547,20 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
return 0;
}
+static void ip_tunnel_adj_headroom(struct net_device *dev, unsigned int headroom)
+{
+ /* we must cap headroom to some upperlimit, else pskb_expand_head
+ * will overflow header offsets in skb_headers_offset_update().
+ */
+ static const unsigned int max_allowed = 512;
+
+ if (headroom > max_allowed)
+ headroom = max_allowed;
+
+ if (headroom > READ_ONCE(dev->needed_headroom))
+ WRITE_ONCE(dev->needed_headroom, headroom);
+}
+
void ip_md_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
u8 proto, int tunnel_hlen)
{
@@ -620,13 +634,13 @@ void ip_md_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
}
headroom += LL_RESERVED_SPACE(rt->dst.dev) + rt->dst.header_len;
- if (headroom > READ_ONCE(dev->needed_headroom))
- WRITE_ONCE(dev->needed_headroom, headroom);
-
- if (skb_cow_head(skb, READ_ONCE(dev->needed_headroom))) {
+ if (skb_cow_head(skb, headroom)) {
ip_rt_put(rt);
goto tx_dropped;
}
+
+ ip_tunnel_adj_headroom(dev, headroom);
+
iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr, proto, tos, ttl,
df, !net_eq(tunnel->net, dev_net(dev)));
return;
@@ -804,16 +818,16 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
max_headroom = LL_RESERVED_SPACE(rt->dst.dev) + sizeof(struct iphdr)
+ rt->dst.header_len + ip_encap_hlen(&tunnel->encap);
- if (max_headroom > READ_ONCE(dev->needed_headroom))
- WRITE_ONCE(dev->needed_headroom, max_headroom);
- if (skb_cow_head(skb, READ_ONCE(dev->needed_headroom))) {
+ if (skb_cow_head(skb, max_headroom)) {
ip_rt_put(rt);
dev->stats.tx_dropped++;
kfree_skb(skb);
return;
}
+ ip_tunnel_adj_headroom(dev, max_headroom);
+
iptunnel_xmit(NULL, rt, skb, fl4.saddr, fl4.daddr, protocol, tos, ttl,
df, !net_eq(tunnel->net, dev_net(dev)));
return;
--
2.43.0
next prev parent reply other threads:[~2024-03-04 21:33 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 21:23 [PATCH 5.4 00/25] 5.4.271-rc1 review Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 01/25] netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter Greg Kroah-Hartman
2024-03-04 21:23 ` Greg Kroah-Hartman [this message]
2024-03-04 21:23 ` [PATCH 5.4 03/25] tun: Fix xdp_rxq_infos queue_index when detaching Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 04/25] ipv6: fix potential "struct net" leak in inet6_rtm_getaddr() Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 05/25] lan78xx: enable auto speed configuration for LAN7850 if no EEPROM is detected Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 06/25] net: usb: dm9601: fix wrong return value in dm9601_mdio_read Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 07/25] Bluetooth: Avoid potential use-after-free in hci_error_reset Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 08/25] Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 09/25] Bluetooth: Enforce validation on max value of connection interval Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 10/25] netfilter: nf_tables: allow NFPROTO_INET in nft_(match/target)_validate() Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 11/25] rtnetlink: fix error logic of IFLA_BRIDGE_FLAGS writing back Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 12/25] efi/capsule-loader: fix incorrect allocation size Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 13/25] power: supply: bq27xxx-i2c: Do not free non existing IRQ Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 14/25] ALSA: Drop leftover snd-rtctimer stuff from Makefile Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 15/25] afs: Fix endless loop in directory parsing Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 16/25] gtp: fix use-after-free and null-ptr-deref in gtp_newlink() Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 17/25] wifi: nl80211: reject iftype change with mesh ID change Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 18/25] btrfs: dev-replace: properly validate device names Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 19/25] dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 20/25] dmaengine: fsl-qdma: init irq after reg initialization Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 21/25] mmc: core: Fix eMMC initialization with 1-bit bus connection Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 22/25] x86/cpu/intel: Detect TME keyid bits before setting MTRR mask registers Greg Kroah-Hartman
2024-03-04 21:23 ` [PATCH 5.4 23/25] cachefiles: fix memory leak in cachefiles_add_cache() Greg Kroah-Hartman
2024-03-04 21:24 ` [PATCH 5.4 24/25] fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super Greg Kroah-Hartman
2024-03-04 21:24 ` [PATCH 5.4 25/25] gpio: 74x164: Enable output pins after registers are reset Greg Kroah-Hartman
2024-03-05 10:58 ` [PATCH 5.4 00/25] 5.4.271-rc1 review Jon Hunter
2024-03-05 19:08 ` Shuah Khan
2024-03-05 20:06 ` Harshit Mogalapalli
2024-03-05 20:19 ` Florian Fainelli
2024-03-06 10:47 ` Naresh Kamboju
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240304211535.821009358@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=patches@lists.linux.dev \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+bfde3bef047a81b8fde6@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.