CVE-2021-47146

In the Linux kernel, the following vulnerability has been resolved:

mld: fix panic in mld_newpack()

mldnewpack() 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 skbput().

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 DEBUGPAGEALLOC KASAN PTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.12.0+ #891 Workqueue: ipv6addrconf addrconfdadwork RIP: 0010:skbpanic+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: ? ip6mchdr.isra.26.constprop.46+0x12a/0x600 ? ip6mchdr.isra.26.constprop.46+0x12a/0x600 skbput.cold.104+0x22/0x22 ip6mchdr.isra.26.constprop.46+0x12a/0x600 ? rcureadlockschedheld+0x91/0xc0 mldnewpack+0x398/0x8f0 ? ip6mchdr.isra.26.constprop.46+0x600/0x600 ? lockcontended+0xc40/0xc40 addgrhead.isra.33+0x280/0x380 addgrec+0x5ca/0xff0 ? mldsendpack+0xf40/0xf40 ? lockdowngrade+0x690/0x690 mldsendinitialcr.part.34+0xb9/0x180 ipv6mcdadcomplete+0x15d/0x1b0 addrconfdadcompleted+0x8d2/0xbb0 ? lockdowngrade+0x690/0x690 ? addrconfrstimer+0x660/0x660 ? addrconfdadwork+0x73c/0x10e0 addrconfdad_work+0x73c/0x10e0

Allowing high order page allocation could fix this problem.