Linux Kernel bis 6.2.8 bpf bpf_jit_limit erweiterte Rechte

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
6.8$0-$5k0.00

Zusammenfassunginfo

Eine Schwachstelle wurde in Linux Kernel bis 6.2.8 gefunden. Sie wurde als kritisch eingestuft. Es ist betroffen die Funktion bpf_jit_limit der Komponente bpf. Mittels Manipulieren mit unbekannten Daten kann eine erweiterte Rechte-Schwachstelle ausgenutzt werden. Die Identifikation der Schwachstelle findet als CVE-2023-53076 statt. Es steht kein Exploit zur Verfügung. Es wird geraten, die betroffene Komponente zu aktualisieren.

Detailsinfo

Es wurde eine Schwachstelle in Linux Kernel bis 6.2.8 ausgemacht. Sie wurde als kritisch eingestuft. Hiervon betroffen ist die Funktion bpf_jit_limit der Komponente bpf. Mit der Manipulation mit einer unbekannten Eingabe kann eine erweiterte Rechte-Schwachstelle ausgenutzt werden. Im Rahmen von CWE wurde eine Klassifizierung als CWE-371 vorgenommen. Auswirkungen hat dies auf Vertraulichkeit, Integrität und Verfügbarkeit. Die Zusammenfassung von CVE lautet:

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.

Bereitgestellt wird das Advisory unter git.kernel.org. Die Identifikation der Schwachstelle wird seit dem 02.05.2025 mit CVE-2023-53076 vorgenommen. Sie ist schwierig auszunutzen. Es sind zwar technische Details, jedoch kein verfügbarer Exploit zur Schwachstelle bekannt. Ein Exploit zur Schwachstelle wird momentan etwa USD $0-$5k kosten (Preisberechnung vom 02.05.2025).

Ein Aktualisieren auf die Version 4.14.312, 4.19.280, 5.4.240, 5.10.177, 5.15.105, 6.1.22 oder 6.2.9 vermag dieses Problem zu lösen. Die Schwachstelle lässt sich auch durch das Einspielen des Patches 374ed036309fce73f9db04c3054018a71912d46b/42049e65d338870e93732b0b80c6c41faf6aa781/d69c2ded95b17d51cc6632c7848cbd476381ecd6/a4bbab27c4bf69486f5846d44134eb31c37e9b22/54869daa6a437887614274f65298ba44a3fac63a/9cda812c76067c8a771eae43bb6943481cc7effc/68ed00a37d2d1c932ff7be40be4b90c4bec48c56/10ec8ca8ec1a2f04c4ed90897225231c58c124a7 lösen. Dieser kann von git.kernel.org bezogen werden. Als bestmögliche Massnahme wird das Upgrade auf eine neue Version empfohlen.

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

Produktinfo

Typ

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍

CVSSv3info

VulDB Meta Base Score: 7.1
VulDB Meta Temp Score: 6.8

VulDB Base Score: 7.1
VulDB Temp Score: 6.8
VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔍
VulDB Temp Score: 🔍
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Erweiterte Rechte
CWE: CWE-371
CAPEC: 🔍
ATT&CK: 🔍

Physisch: Nein
Lokal: Nein
Remote: Teilweise

Verfügbarkeit: 🔍
Status: Nicht definiert
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔍

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔍

Upgrade: Kernel 4.14.312/4.19.280/5.4.240/5.10.177/5.15.105/6.1.22/6.2.9
Patch: 374ed036309fce73f9db04c3054018a71912d46b/42049e65d338870e93732b0b80c6c41faf6aa781/d69c2ded95b17d51cc6632c7848cbd476381ecd6/a4bbab27c4bf69486f5846d44134eb31c37e9b22/54869daa6a437887614274f65298ba44a3fac63a/9cda812c76067c8a771eae43bb6943481cc7effc/68ed00a37d2d1c932ff7be40be4b90c4bec48c56/10ec8ca8ec1a2f04c4ed90897225231c58c124a7

Timelineinfo

02.05.2025 🔍
02.05.2025 +0 Tage 🔍
02.05.2025 +0 Tage 🔍
02.05.2025 +0 Tage 🔍

Quelleninfo

Hersteller: kernel.org

Advisory: git.kernel.org
Status: Bestätigt

CVE: CVE-2023-53076 (🔍)
GCVE (CVE): GCVE-0-2023-53076
GCVE (VulDB): GCVE-100-307221

Eintraginfo

Erstellt: 02.05.2025 19:49
Anpassungen: 02.05.2025 19:49 (58)
Komplett: 🔍
Cache ID: 216::103

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

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

◂ ZurückÜbersichtWeiter ▸

Want to know what is going to be exploited?

We predict KEV entries!