CVE-2021-47146

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mld: fix panic in mld_newpack()<br /> <br /> mld_newpack() doesn&amp;#39;t allow to allocate high order page,<br /> only order-0 allocation is allowed.<br /> If headroom size is too large, a kernel panic could occur in skb_put().<br /> <br /> Test commands:<br /> ip netns del A<br /> ip netns del B<br /> ip netns add A<br /> ip netns add B<br /> ip link add veth0 type veth peer name veth1<br /> ip link set veth0 netns A<br /> ip link set veth1 netns B<br /> <br /> ip netns exec A ip link set lo up<br /> ip netns exec A ip link set veth0 up<br /> ip netns exec A ip -6 a a 2001:db8:0::1/64 dev veth0<br /> ip netns exec B ip link set lo up<br /> ip netns exec B ip link set veth1 up<br /> ip netns exec B ip -6 a a 2001:db8:0::2/64 dev veth1<br /> for i in {1..99}<br /> do<br /> let A=$i-1<br /> ip netns exec A ip link add ip6gre$i type ip6gre \<br /> local 2001:db8:$A::1 remote 2001:db8:$A::2 encaplimit 100<br /> ip netns exec A ip -6 a a 2001:db8:$i::1/64 dev ip6gre$i<br /> ip netns exec A ip link set ip6gre$i up<br /> <br /> ip netns exec B ip link add ip6gre$i type ip6gre \<br /> local 2001:db8:$A::2 remote 2001:db8:$A::1 encaplimit 100<br /> ip netns exec B ip -6 a a 2001:db8:$i::2/64 dev ip6gre$i<br /> ip netns exec B ip link set ip6gre$i up<br /> done<br /> <br /> Splat looks like:<br /> kernel BUG at net/core/skbuff.c:110!<br /> invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI<br /> CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.12.0+ #891<br /> Workqueue: ipv6_addrconf addrconf_dad_work<br /> RIP: 0010:skb_panic+0x15d/0x15f<br /> Code: 92 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 00 ae 79 83<br /> 41 57 41 56 41 55 48 8b 54 24 a6 26 f9 ff 0b 48 8b 6c 24 20 89<br /> 34 24 e8 4a 4e 92 fe 8b 34 24 48 c7 c1 20<br /> RSP: 0018:ffff88810091f820 EFLAGS: 00010282<br /> RAX: 0000000000000089 RBX: ffff8881086e9000 RCX: 0000000000000000<br /> RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed1020123efb<br /> RBP: ffff888005f6eac0 R08: ffffed1022fc0031 R09: ffffed1022fc0031<br /> R10: ffff888117e00187 R11: ffffed1022fc0030 R12: 0000000000000028<br /> R13: ffff888008284eb0 R14: 0000000000000ed8 R15: 0000000000000ec0<br /> FS: 0000000000000000(0000) GS:ffff888117c00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f8b801c5640 CR3: 0000000033c2c006 CR4: 00000000003706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600<br /> ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600<br /> skb_put.cold.104+0x22/0x22<br /> ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600<br /> ? rcu_read_lock_sched_held+0x91/0xc0<br /> mld_newpack+0x398/0x8f0<br /> ? ip6_mc_hdr.isra.26.constprop.46+0x600/0x600<br /> ? lock_contended+0xc40/0xc40<br /> add_grhead.isra.33+0x280/0x380<br /> add_grec+0x5ca/0xff0<br /> ? mld_sendpack+0xf40/0xf40<br /> ? lock_downgrade+0x690/0x690<br /> mld_send_initial_cr.part.34+0xb9/0x180<br /> ipv6_mc_dad_complete+0x15d/0x1b0<br /> addrconf_dad_completed+0x8d2/0xbb0<br /> ? lock_downgrade+0x690/0x690<br /> ? addrconf_rs_timer+0x660/0x660<br /> ? addrconf_dad_work+0x73c/0x10e0<br /> addrconf_dad_work+0x73c/0x10e0<br /> <br /> Allowing high order page allocation could fix this problem.