From: Greg Kroah-Hartman Date: Fri, 3 Feb 2023 08:02:55 +0000 (+0100) Subject: 4.14-stable patches X-Git-Tag: v4.14.305~20 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f0acecfb66565ed4d7f748544c065d1e2216780b;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: ipv6-ensure-sane-device-mtu-in-tunnels.patch mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags.patch --- diff --git a/queue-4.14/ipv6-ensure-sane-device-mtu-in-tunnels.patch b/queue-4.14/ipv6-ensure-sane-device-mtu-in-tunnels.patch new file mode 100644 index 00000000000..25180807de2 --- /dev/null +++ b/queue-4.14/ipv6-ensure-sane-device-mtu-in-tunnels.patch @@ -0,0 +1,151 @@ +From d89d7ff01235f218dad37de84457717f699dee79 Mon Sep 17 00:00:00 2001 +From: Eric Dumazet +Date: Sun, 23 Oct 2022 19:01:24 -0700 +Subject: ipv6: ensure sane device mtu in tunnels + +From: Eric Dumazet + +commit d89d7ff01235f218dad37de84457717f699dee79 upstream. + +Another syzbot report [1] with no reproducer hints +at a bug in ip6_gre tunnel (dev:ip6gretap0) + +Since ipv6 mcast code makes sure to read dev->mtu once +and applies a sanity check on it (see commit b9b312a7a451 +"ipv6: mcast: better catch silly mtu values"), a remaining +possibility is that a layer is able to set dev->mtu to +an underflowed value (high order bit set). + +This could happen indeed in ip6gre_tnl_link_config_route(), +ip6_tnl_link_config() and ipip6_tunnel_bind_dev() + +Make sure to sanitize mtu value in a local variable before +it is written once on dev->mtu, as lockless readers could +catch wrong temporary value. + +[1] +skbuff: skb_over_panic: text:ffff80000b7a2f38 len:40 put:40 head:ffff000149dcf200 data:ffff000149dcf2b0 tail:0xd8 end:0xc0 dev:ip6gretap0 +------------[ cut here ]------------ +kernel BUG at net/core/skbuff.c:120 +Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP +Modules linked in: +CPU: 1 PID: 10241 Comm: kworker/1:1 Not tainted 6.0.0-rc7-syzkaller-18095-gbbed346d5a96 #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/30/2022 +Workqueue: mld mld_ifc_work +pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) +pc : skb_panic+0x4c/0x50 net/core/skbuff.c:116 +lr : skb_panic+0x4c/0x50 net/core/skbuff.c:116 +sp : ffff800020dd3b60 +x29: ffff800020dd3b70 x28: 0000000000000000 x27: ffff00010df2a800 +x26: 00000000000000c0 x25: 00000000000000b0 x24: ffff000149dcf200 +x23: 00000000000000c0 x22: 00000000000000d8 x21: ffff80000b7a2f38 +x20: ffff00014c2f7800 x19: 0000000000000028 x18: 00000000000001a9 +x17: 0000000000000000 x16: ffff80000db49158 x15: ffff000113bf1a80 +x14: 0000000000000000 x13: 00000000ffffffff x12: ffff000113bf1a80 +x11: ff808000081c0d5c x10: 0000000000000000 x9 : 73f125dc5c63ba00 +x8 : 73f125dc5c63ba00 x7 : ffff800008161d1c x6 : 0000000000000000 +x5 : 0000000000000080 x4 : 0000000000000001 x3 : 0000000000000000 +x2 : ffff0001fefddcd0 x1 : 0000000100000000 x0 : 0000000000000089 +Call trace: +skb_panic+0x4c/0x50 net/core/skbuff.c:116 +skb_over_panic net/core/skbuff.c:125 [inline] +skb_put+0xd4/0xdc net/core/skbuff.c:2049 +ip6_mc_hdr net/ipv6/mcast.c:1714 [inline] +mld_newpack+0x14c/0x270 net/ipv6/mcast.c:1765 +add_grhead net/ipv6/mcast.c:1851 [inline] +add_grec+0xa20/0xae0 net/ipv6/mcast.c:1989 +mld_send_cr+0x438/0x5a8 net/ipv6/mcast.c:2115 +mld_ifc_work+0x38/0x290 net/ipv6/mcast.c:2653 +process_one_work+0x2d8/0x504 kernel/workqueue.c:2289 +worker_thread+0x340/0x610 kernel/workqueue.c:2436 +kthread+0x12c/0x158 kernel/kthread.c:376 +ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 +Code: 91011400 aa0803e1 a90027ea 94373093 (d4210000) + +Fixes: c12b395a4664 ("gre: Support GRE over IPv6") +Reported-by: syzbot +Signed-off-by: Eric Dumazet +Link: https://lore.kernel.org/r/20221024020124.3756833-1-eric.dumazet@gmail.com +Signed-off-by: Jakub Kicinski +[ta: Backport patch for stable kernels < 5.10.y. Fix conflict in +net/ipv6/ip6_tunnel.c, mtu initialized with: +mtu = rt->dst.dev->mtu - t_hlen;] +Cc: # 4.14.y, 4.19.y, 5.4.y +Signed-off-by: Tudor Ambarus +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv6/ip6_gre.c | 12 +++++++----- + net/ipv6/ip6_tunnel.c | 10 ++++++---- + net/ipv6/sit.c | 8 +++++--- + 3 files changed, 18 insertions(+), 12 deletions(-) + +--- a/net/ipv6/ip6_gre.c ++++ b/net/ipv6/ip6_gre.c +@@ -771,14 +771,16 @@ static void ip6gre_tnl_link_config(struc + t_hlen; + + if (set_mtu) { +- dev->mtu = rt->dst.dev->mtu - t_hlen; ++ int mtu = rt->dst.dev->mtu - t_hlen; ++ + if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT)) +- dev->mtu -= 8; ++ mtu -= 8; + if (dev->type == ARPHRD_ETHER) +- dev->mtu -= ETH_HLEN; ++ mtu -= ETH_HLEN; + +- if (dev->mtu < IPV6_MIN_MTU) +- dev->mtu = IPV6_MIN_MTU; ++ if (mtu < IPV6_MIN_MTU) ++ mtu = IPV6_MIN_MTU; ++ WRITE_ONCE(dev->mtu, mtu); + } + } + ip6_rt_put(rt); +--- a/net/ipv6/ip6_tunnel.c ++++ b/net/ipv6/ip6_tunnel.c +@@ -1431,6 +1431,7 @@ static void ip6_tnl_link_config(struct i + struct __ip6_tnl_parm *p = &t->parms; + struct flowi6 *fl6 = &t->fl.u.ip6; + int t_hlen; ++ int mtu; + + memcpy(dev->dev_addr, &p->laddr, sizeof(struct in6_addr)); + memcpy(dev->broadcast, &p->raddr, sizeof(struct in6_addr)); +@@ -1473,12 +1474,13 @@ static void ip6_tnl_link_config(struct i + dev->hard_header_len = rt->dst.dev->hard_header_len + + t_hlen; + +- dev->mtu = rt->dst.dev->mtu - t_hlen; ++ mtu = rt->dst.dev->mtu - t_hlen; + if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT)) +- dev->mtu -= 8; ++ mtu -= 8; + +- if (dev->mtu < IPV6_MIN_MTU) +- dev->mtu = IPV6_MIN_MTU; ++ if (mtu < IPV6_MIN_MTU) ++ mtu = IPV6_MIN_MTU; ++ WRITE_ONCE(dev->mtu, mtu); + } + ip6_rt_put(rt); + } +--- a/net/ipv6/sit.c ++++ b/net/ipv6/sit.c +@@ -1068,10 +1068,12 @@ static void ipip6_tunnel_bind_dev(struct + + if (tdev && !netif_is_l3_master(tdev)) { + int t_hlen = tunnel->hlen + sizeof(struct iphdr); ++ int mtu; + +- dev->mtu = tdev->mtu - t_hlen; +- if (dev->mtu < IPV6_MIN_MTU) +- dev->mtu = IPV6_MIN_MTU; ++ mtu = tdev->mtu - t_hlen; ++ if (mtu < IPV6_MIN_MTU) ++ mtu = IPV6_MIN_MTU; ++ WRITE_ONCE(dev->mtu, mtu); + } + } + diff --git a/queue-4.14/mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags.patch b/queue-4.14/mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags.patch new file mode 100644 index 00000000000..81971a79221 --- /dev/null +++ b/queue-4.14/mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags.patch @@ -0,0 +1,59 @@ +From ce91f6ee5b3bbbad8caff61b1c46d845c8db19bf Mon Sep 17 00:00:00 2001 +From: Michal Hocko +Date: Thu, 7 Jun 2018 17:09:40 -0700 +Subject: mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags + +From: Michal Hocko + +commit ce91f6ee5b3bbbad8caff61b1c46d845c8db19bf upstream. + +kvmalloc warned about incompatible gfp_mask to catch abusers (mostly +GFP_NOFS) with an intention that this will motivate authors of the code +to fix those. Linus argues that this just motivates people to do even +more hacks like + + if (gfp == GFP_KERNEL) + kvmalloc + else + kmalloc + +I haven't seen this happening much (Linus pointed to bucket_lock special +cases an atomic allocation but my git foo hasn't found much more) but it +is true that we can grow those in future. Therefore Linus suggested to +simply not fallback to vmalloc for incompatible gfp flags and rather +stick with the kmalloc path. + +Link: http://lkml.kernel.org/r/20180601115329.27807-1-mhocko@kernel.org +Signed-off-by: Michal Hocko +Suggested-by: Linus Torvalds +Cc: Tom Herbert +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Rishabh Bhatnagar +Signed-off-by: Greg Kroah-Hartman +--- + mm/util.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/mm/util.c ++++ b/mm/util.c +@@ -400,7 +400,8 @@ EXPORT_SYMBOL(vm_mmap); + * __GFP_RETRY_MAYFAIL is supported, and it should be used only if kmalloc is + * preferable to the vmalloc fallback, due to visible performance drawbacks. + * +- * Any use of gfp flags outside of GFP_KERNEL should be consulted with mm people. ++ * Please note that any use of gfp flags outside of GFP_KERNEL is careful to not ++ * fall back to vmalloc. + */ + void *kvmalloc_node(size_t size, gfp_t flags, int node) + { +@@ -411,7 +412,8 @@ void *kvmalloc_node(size_t size, gfp_t f + * vmalloc uses GFP_KERNEL for some internal allocations (e.g page tables) + * so the given set of flags has to be compatible. + */ +- WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL); ++ if ((flags & GFP_KERNEL) != GFP_KERNEL) ++ return kmalloc_node(size, flags, node); + + /* + * We want to attempt a large physically contiguous block first because diff --git a/queue-4.14/series b/queue-4.14/series index efa0786c5a8..2f5bb516f47 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -57,3 +57,5 @@ panic-introduce-warn_limit.patch panic-expose-warn_count-to-sysfs.patch docs-fix-path-paste-o-for-sys-kernel-warn_count.patch exit-use-read_once-for-all-oops-warn-limit-reads.patch +mm-kvmalloc-does-not-fallback-to-vmalloc-for-incompatible-gfp-flags.patch +ipv6-ensure-sane-device-mtu-in-tunnels.patch