Alexei Starovoitov

A vulnerability in the Linux kernel has been resolved. The issue is related to the use of `kmalloc(GFP ATOMIC)` in non-preemptible context in PREEMPT RT, which is not safe. The patch enforces the use of `bpf mem alloc` in `bpf local storage` when `CONFIG PREEMPT RT` is enabled. The problem has existed since the introduction of `bpf local storage` about 5 years ago. The patch targets `bpf-next` and uses `bpf mem alloc` to solve the issue.

The issue is related to a use-after-free (UAF) vulnerability in the Linux kernel's BPF uprobe attachments. Uprobes use `bpf prog run array uprobe()` under tasks-trace-RCU protection, but it is possible to attach a non-sleepable BPF program to a uprobe. Non-sleepable BPF programs are freed via normal RCU, which can lead to UAF of the `bpf prog` because a normal RCU grace period does not imply a tasks-trace-RCU grace period. The vulnerability can be exploited to impact the confidentiality, integrity, and availability of protected information.

The issue is caused by the Linux kernel's BPF allowing access to mptcp-level proto ops from a tcp subflow scope. This can lead to a denial of service. The root cause of the issue is that bpf allows accessing mptcp-level proto ops from a tcp subflow scope.

Name of the Vulnerable Software and Affected Versions: Linux kernel (affected versions not specified) Description: The issue is related to a race condition between `bpf timer cancel and free` and `bpf timer cancel` in the Linux kernel, which can lead to a Use After Free (UAF) on the `timer->timer`. This occurs when `bpf timer cancel` and `bpf timer cancel and free` are called concurrently, causing the `timer->timer` to be accessed after it has been freed. The patch resolves this issue by freeing the `timer->timer` after a rcu grace period in `bpf timer cancel and free`, and adding a `rcu read lock` in `bpf timer cancel` to prevent the race condition. Recommendations: At the moment, there is no information about a newer version that contains a fix for this vulnerability.

A panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted for perf sampling, a specific call sequence can occur, leading to an unhandled page fault. The issue arises from the access to an address in the vsyscall region. To fix the bug, filtering for vsyscalls can be done when determining the branch type, returning a "none" branch if a kernel address is found to lie in the vsyscall region. The vulnerable function names include ` insn get emulate prefix()`, `insn get emulate prefix()`, `insn get prefixes()`, `insn get opcode()`, `decode branch type()`, `get branch type()`, `intel pmu lbr filter()`, `intel pmu handle irq()`, and `perf event nmi handler()`. A macro `peek nbyte next(insn byte t, insn, i)` is also called, leading to a dereference of `(insn)->next byte`.

The issue is related to the Linux kernel's handling of unreachable code in the `kernel/bpf/verifier.c` component. This behavior is also considered an improper branch-pruning logic issue. It could be used by local users to cause a denial of service. The estimated number of potentially affected devices is not specified.