CVE-2021-46936

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

net: fix use-after-free in tw_timer_handler

A real world panic issue was found as follow in Linux 5.4.

BUG: unable to handle page fault for address: ffffde49a863de28
PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0
RIP: 0010:tw_timer_handler+0x20/0x40
Call Trace:
 <IRQ>
 call_timer_fn+0x2b/0x120
 run_timer_softirq+0x1ef/0x450
 __do_softirq+0x10d/0x2b8
 irq_exit+0xc7/0xd0
 smp_apic_timer_interrupt+0x68/0x120
 apic_timer_interrupt+0xf/0x20

This issue was also reported since 2017 in the thread [1], unfortunately, the issue was still can be reproduced after fixing DCCP.

The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some inflight time-wait timers.

This bug is not introduced by commit f2bf415cfed7 (mib: add net to NET_ADD_STATS_BH) since the net_statistics is a global variable instead of dynamic allocation and freeing. Actually, commit 61a7e26028b9 (mib: put net statistics on struct net) introduces the bug since it put net statistics on struct net and free it when net namespace is destroyed.

Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is meaningless when init_ipv4_mibs() fails.

[1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1

Weakness

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.

Affected Software

Extended Description

The use of previously-freed memory can have any number of adverse consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system’s reuse of the freed memory. Use-after-free errors have two common and sometimes overlapping causes:

In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

Potential Mitigations

References

• https://git.kernel.org/stable/c/08eacbd141e2495d2fcdde84358a06c4f95cbb13
• https://git.kernel.org/stable/c/15579e1301f856ad9385d720c9267c11032a5022
• https://git.kernel.org/stable/c/2386e81a1d277f540e1285565c9d41d531bb69d4
• https://git.kernel.org/stable/c/5c2fe20ad37ff56070ae0acb34152333976929b4
• https://git.kernel.org/stable/c/a8e1944b44f94f5c5f530e434c5eaee787254566
• https://git.kernel.org/stable/c/e22e45fc9e41bf9fcc1e92cfb78eb92786728ef0
• https://git.kernel.org/stable/c/e73164e89d1be561228a4534e1091369ee4ba41a
• https://git.kernel.org/stable/c/fe5838c22b986c1190f1dce9aa09bf6a491c1a69