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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox