BPF code can allow local privilege escalation (CVE-2021-29154) - TuxCare
TuxCare Blog News

BPF code can allow local privilege escalation (CVE-2021-29154)

April 12, 2021

Another vulnerability targeting the BPF subsystem has been disclosed publicly in the past few days (CVE-2021-29154). It allows users on a system running non-default configuration of the BPF subsystem to run specially crafted code as a BPF filter and run arbitrary executable code in the kernel context.   According to vendors, it affects all distributions running kernels up to version 5.11.12. Distribution vendors are starting to deliver patches through their update mechanisms, and KernelCare is also finalizing patches for it’s rebootless patching process to address this issue.  Because of the nature of the BPF functionality, which is to allow user code to interact with network packet processing within the kernel, there is a very big potential for attack given any weakness in the implementation. This specific functionality has been addressed recently in the specter mitigation code bug discussed here.  To be vulnerable, a system would have to be configured to allow BPF JIT compilation (for example, by setting “net.core.bpf_jit_enable = 1”). This is often the case in situations where regular users are doing work related to sockets’ manipulation or in seccomp (secure computing mode) environments where permissions are granted more granularly than normal.  The actual vulnerable code resides in arch/x86/net/bpf_jit_comp.c and arch/x86/net/bpf_jit_comp32.c in the kernel source code tree. The flaw comes from the way branch displacement happens when the user code is compiled, by making wrong assumptions regarding the address of code during optimization.  Proper exploitation of this vulnerability could even lead to container or chroots’ escape, since the kernel is shared between them, and running code in the kernel context permits it to escape containerization limits.  As a stop-gap procedure, you can quickly disable BPF JIT by running:  # echo 0 > /proc/sys/net/core/bpf_jit_enable   Which will persist until reversed or a system reboot. A more permanent removal can be achieved by using your distribution’s syscfg equivalent utility to set “net.core.bpf_jit_enable=0” at boot time. Of course, this type of solution solves the problem by disabling the functionality, which in itself is self-defeating. If you actually had your system configured to use BPF JIT, in all likelihood your use case needed that setting explicitly enabled, and you should rely instead on proper kernel patching, either through your distribution vendor’s patches or through KernelCare’s rebootless process.” width=”2600″ loading=”lazy” style=”width: 2600px;”></p>
<p style=Another vulnerability targeting the BPF subsystem has been disclosed publicly in the past few days (CVE-2021-29154). It allows users on a system running non-default configuration of the BPF subsystem to run specially crafted code as a BPF filter and run arbitrary executable code in the kernel context. 

 

According to vendors, it affects all distributions running kernels up to version 5.11.12. Distribution vendors are starting to deliver patches through their update mechanisms, and KernelCare is also finalizing patches for it’s rebootless patching process to address this issue.

Because of the nature of the BPF functionality, which is to allow user code to interact with network packet processing within the kernel, there is a very big potential for attack given any weakness in the implementation. This specific functionality has been addressed recently in the specter mitigation code bug discussed here.

 

To be vulnerable, a system would have to be configured to allow BPF JIT compilation (for example, by setting “net.core.bpf_jit_enable = 1”). This is often the case in situations where regular users are doing work related to sockets’ manipulation or in seccomp (secure computing mode) environments where permissions are granted more granularly than normal.

 

The actual vulnerable code resides in arch/x86/net/bpf_jit_comp.c and arch/x86/net/bpf_jit_comp32.c in the kernel source code tree. The flaw comes from the way branch displacement happens when the user code is compiled, by making wrong assumptions regarding the address of code during optimization.

 

Proper exploitation of this vulnerability could even lead to container or chroots’ escape, since the kernel is shared between them, and running code in the kernel context permits it to escape containerization limits.

 

As a stop-gap procedure, you can quickly disable BPF JIT by running:

 

# echo 0 > /proc/sys/net/core/bpf_jit_enable

 

 

which will persist until reversed or a system reboot happens. A more permanent removal can be achieved by using your distribution’s syscfg equivalent utility to set “net.core.bpf_jit_enable=0” at boot time. Of course, this type of solution solves the problem by disabling the functionality, which in itself is self-defeating. If you actually had your system configured to use BPF JIT, in all likelihood your use case needed that setting explicitly enabled, and you should rely instead on proper kernel patching, either through your distribution vendor’s patches or through KernelCare’s rebootless process.

TuxCare can help you reduce your risk window to data exfiltration and other cyber security threats.

TALK TO A CYBERSECURITY EXPERT

Expert knowledge of Linux security tips,
live patching education, and Cybersecurity news.

Stay updated with the latest news and announcements from TuxCare.com

Related Articles

The Bugs Behind the Vulnerabilities...

We continue to look at the code issues that cause...

November 14, 2022

Cybersecurity insurance and fine print:...

Catastrophic risks such as natural disasters and indeed cyberattacks require...

June 29, 2022

IT Automation With Live...

In a symphony orchestra, instruments harmonize to create one pleasing...

June 20, 2022

KernelCare ePortal updated – version...

We are pleased to announce that a new updated ePortal version...

June 16, 2022

KernelCare agent update – version...

We are pleased to announce that a new updated KernelCare agent...

June 2, 2022

KernelCare ePortal updated – version...

We are pleased to announce that a new updated ePortal version...

May 26, 2022

Resources

State of Enterprise Linux Cybersecurity ... Read More State of Enterprise Linux Cybersecurity ...
Dangerous remotely exploitable vulnerability ... Read More Dangerous remotely exploitable vulnerability ...
Securing confidential research data ... Read More Securing confidential research data ...
State of Enterprise Vulnerability Detection ... Read More State of Enterprise Vulnerability Detection ...
Demand for Rapid Risk Elimination for ... Read More Demand for Rapid Risk Elimination for ...
TuxCare Free Raspberry Pi Patching Read More TuxCare Free Raspberry Pi Patching