Two new vulnerabilities have been identified in the eBPF subsystem, which allows you to run handlers inside the Linux kernel in a special virtual machine with JIT. Both vulnerabilities make it possible to execute your code with kernel rights, outside of an isolated eBPF virtual machine. Information about the problems was published by the Zero Day Initiative team, which runs the Pwn2Own competition, during which this year three attacks on Ubuntu Linux were demonstrated that used previously unknown vulnerabilities (whether the vulnerabilities in eBPF are related to these attacks is not reported).
- CVE-2021-3490 - The vulnerability is caused by a lack of 32-bit out-of-bounds checking when performing bitwise AND, OR, and XOR operations in eBPF ALU32. An attacker can take advantage of this error to read and write data outside the bounds of the allocated buffer. The problem with XOR operations appears starting from kernel version 5.7-rc1, and AND and OR - starting from 5.10-rc1.
- CVE-2021-3489 - The vulnerability is caused by an error in the implementation of the ring buffer and is due to the fact that the bpf_ringbuf_reserve function did not check the possibility that the size of the allocated memory region could be less than the actual size of the ringbuf. The problem appears since release 5.8-rc1.
The status of patching vulnerabilities in distributions can be tracked on these pages: Ubuntu, Debian, RHEL, Fedora, SUSE, Arch). Fixes are also available as patches (CVE-2021-3489, CVE-2021-3490). Whether the issue can be exploited depends on whether the eBPF system call is accessible to the user. For example, in the default configuration in RHEL, exploitation of the vulnerability requires the user to have CAP_SYS_ADMIN rights.
Separately, we can note another vulnerability in the Linux kernel - CVE-2021-32606, which allows a local user to raise their privileges to the root level. The problem has been evident since Linux kernel 5.11 and is caused by a race condition in the implementation of the CAN ISOTP protocol, which makes it possible to change the socket binding parameters due to the lack of setting the proper locks in the isotp_setsockopt() function when processing the CAN_ISOTP_SF_BROADCAST flag.
After the ISOTP socket is closed, the binding to the recipient socket remains in effect, which can continue to use the structures associated with the socket after the memory associated with them is freed (use-after-free due to the call to an isotp_sock structure that has already been freed when isotp_rcv() is called). Through data manipulation, you can override the pointer to the sk_error_report() function and execute your code at the kernel level.
Source: opennet.ru