Linux Kernel up to 6.2.8 bpf bpf_jit_limit state issue

Summaryinfo

A vulnerability was found in Linux Kernel up to 6.2.8. It has been classified as critical. This affects the function bpf_jit_limit of the component bpf. Performing a manipulation results in state issue. This vulnerability is identified as CVE-2023-53076. There is not any exploit available. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability was found in Linux Kernel up to 6.2.8. It has been classified as critical. This affects the function bpf_jit_limit of the component bpf. The manipulation with an unknown input leads to a state issue vulnerability. CWE is classifying the issue as CWE-371. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: bpf: Adjust insufficient default bpf_jit_limit We've seen recent AWS EKS (Kubernetes) user reports like the following: After upgrading EKS nodes from v20230203 to v20230217 on our 1.24 EKS clusters after a few days a number of the nodes have containers stuck in ContainerCreating state or liveness/readiness probes reporting the following error: Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: failed to start exec "4a11039f730203ffc003b7[...]": OCI runtime exec failed: exec failed: unable to start container process: unable to init seccomp: error loading seccomp filter into kernel: error loading seccomp filter: errno 524: unknown However, we had not been seeing this issue on previous AMIs and it only started to occur on v20230217 (following the upgrade from kernel 5.4 to 5.10) with no other changes to the underlying cluster or workloads. We tried the suggestions from that issue (sysctl net.core.bpf_jit_limit=452534528) which helped to immediately allow containers to be created and probes to execute but after approximately a day the issue returned and the value returned by cat /proc/vmallocinfo | grep bpf_jit | awk '{s+=$2} END {print s}' was steadily increasing. I tested bpf tree to observe bpf_jit_charge_modmem, bpf_jit_uncharge_modmem their sizes passed in as well as bpf_jit_current under tcpdump BPF filter, seccomp BPF and native (e)BPF programs, and the behavior all looks sane and expected, that is nothing "leaking" from an upstream perspective. The bpf_jit_limit knob was originally added in order to avoid a situation where unprivileged applications loading BPF programs (e.g. seccomp BPF policies) consuming all the module memory space via BPF JIT such that loading of kernel modules would be prevented. The default limit was defined back in 2018 and while good enough back then, we are generally seeing far more BPF consumers today. Adjust the limit for the BPF JIT pool from originally 1/4 to now 1/2 of the module memory space to better reflect today's needs and avoid more users running into potentially hard to debug issues.

The advisory is shared at git.kernel.org. This vulnerability is uniquely identified as CVE-2023-53076 since 05/02/2025. The exploitability is told to be difficult. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 05/02/2025).

Upgrading to version 4.14.312, 4.19.280, 5.4.240, 5.10.177, 5.15.105, 6.1.22 or 6.2.9 eliminates this vulnerability. Applying the patch 374ed036309fce73f9db04c3054018a71912d46b/42049e65d338870e93732b0b80c6c41faf6aa781/d69c2ded95b17d51cc6632c7848cbd476381ecd6/a4bbab27c4bf69486f5846d44134eb31c37e9b22/54869daa6a437887614274f65298ba44a3fac63a/9cda812c76067c8a771eae43bb6943481cc7effc/68ed00a37d2d1c932ff7be40be4b90c4bec48c56/10ec8ca8ec1a2f04c4ed90897225231c58c124a7 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 4.14.311
• 4.19.279
• 5.4.239
• 5.10.176
• 5.15.104
• 6.1.0
• 6.1.1
• 6.1.2
• 6.1.3
• 6.1.4
• 6.1.5
• 6.1.6
• 6.1.7
• 6.1.8
• 6.1.9
• 6.1.10
• 6.1.11
• 6.1.12
• 6.1.13
• 6.1.14
• 6.1.15
• 6.1.16
• 6.1.17
• 6.1.18
• 6.1.19
• 6.1.20
• 6.1.21
• 6.2.0
• 6.2.1
• 6.2.2
• 6.2.3
• 6.2.4
• 6.2.5
• 6.2.6
• 6.2.7
• 6.2.8

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion