CVE-2021-47146

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