Two new vulnerabilities have been identified in the eBPF subsystem, which allows executing handlers within the Linux kernel in a special virtual machine with JIT. Both vulnerabilities enable the execution of arbitrary code with kernel privileges, outside the isolated eBPF virtual machine. Information about the issues was published by the Zero Day Initiative team, which conducts the Pwn2Own competitions, where this year three attacks on Ubuntu Linux were demonstrated using previously unknown vulnerabilities (it is not reported whether the eBPF vulnerabilities are related to these attacks).
- CVE-2021-3490 — the vulnerability is caused by the lack of boundary checking for 32-bit values during the execution of AND, OR, and XOR bitwise operations in eBPF ALU32. An attacker can exploit this flaw to read and write data outside the bounds of the allocated buffer. The issue with the XOR operation manifests starting from kernel version 5.7-rc1, while AND and OR issues appear from version 5.10-rc1.
- CVE-2021-3489 — the vulnerability is due to an error in the implementation of the ring buffer and is related to the bpf_ringbuf_reserve function not checking the possibility that the size of the allocated memory area might be smaller than the actual size of the ring buffer. The problem manifests from version 5.8-rc1.
The status of vulnerability fixes 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). The exploitability of the issue depends on the user's access to the eBPF system call. For instance, in the default configuration in RHEL, exploitation of the vulnerability requires the user to have CAP_SYS_ADMIN privileges.
Another vulnerability in the Linux kernel worth noting is CVE-2021-32606, which allows a local user to elevate their privileges to root level. The issue manifests starting from Linux kernel 5.11 and is caused by a race condition in the implementation of the CAN ISOTP protocol, which allows for changing socket binding parameters due to the lack of proper locking in the isotp_setsockopt() function when handling the CAN_ISOTP_SF_BROADCAST flag.
After closing the ISOTP socket, the binding to the recipient socket continues to operate, which may allow the related structures to be used even after the associated memory has been freed (use-after-free due to accessing the already freed isotp_sock structure when calling isotp_rcv()). By manipulating the data, it is possible to override the pointer to the sk_error_report() function and execute custom code at the kernel level.
Source: opennet.ru
