Niedrig14 / 100Konfidenz: Mittel

CVSS7.8EPSS0.2 %Ohne Zutun des Nutzers

Hoechster CVSS-Basiswert 7.8+14

Bewertung v1.2, deterministisch berechnet. Bedrohungswert und Konfidenz sind getrennte Größen.· 2026-09-18 12:37 UTCMethodik

[UPDATE] [mittel] Linux Kernel: Mehrere Schwachstellen

CERT-Bund·18. September 2026, 12:37

Originalartikel lesen bei CERT-Bund

Im Linux Kernel wurden mehrere Schwachstellen entdeckt, die es einem entfernten Angreifer ermöglichen, Denial-of-Service-Angriffe auszulösen. Betroffen sind verschiedene Versionen des Open Source Linux Kernels sowie spezifische Dell Secure Connect Gateway Appliances und SUSE/Ubuntu Linux Distributionen. Nutzern wird dringend empfohlen, die bereitgestellten Herstellerinformationen zu prüfen und umgehend Updates einzuspielen, um die Systeme zu schützen.

SecBoard-Einordnung

Diese Schwachstellen ermöglichen es entfernten Angreifern, Denial-of-Service-Angriffe auszulösen, was zu einer Unterbrechung der Verfügbarkeit kritischer Systeme führen kann.

Realistisch schlimmster Fall: Der schlimmste Fall ist ein erfolgreicher Denial-of-Service-Angriff, der die vollständige Nichtverfügbarkeit betroffener Systeme und Dienste zur Folge hat.

Empfehlung: Prüfen Sie die Herstellerinformationen für Ihre spezifischen Linux-Distributionen oder Dell-Appliances und spielen Sie umgehend alle verfügbaren Sicherheitsupdates ein.

Key Facts

CVE-2024-58100

CVSS: 7.8 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2024-58098

CVSS: 7.8 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

CVE-2024-58237

CVSS: 7.8 · HIGH
EPSS: 0.2%
Über das Netz: nein
Anmeldung nötig: ja
Nutzerinteraktion nötig: nein
Angriffskomplexität: niedrig
Beeinträchtigt: Vertraulichkeit, Integrität, Verfügbarkeit
Patch: unbekannt

Betroffen

Verschiedene Open Source Linux Kernel Versionen, Dell Secure Connect Gateway Appliances, SUSE Linux und Ubuntu Linux sind betroffen.

Hersteller

Linux

Produkte

Linux Kernel

▸ CPE-Rohbezeichner anzeigen (3)

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.13:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.13:rc2:*:*:*:*:*:*

Prüfen

▸Überprüfen Sie die Versionen Ihrer Linux-Kernel und installierten Distributionen (z.B. SUSE, Ubuntu) auf die Betroffenheit durch die genannten Schwachstellen.
▸Stellen Sie sicher, dass alle Dell Secure Connect Gateway Appliances auf dem neuesten Stand sind und die empfohlenen Patches angewendet wurden.

▸ 1 weitere

▸Implementieren Sie Intrusion Detection/Prevention Systeme (IDS/IPS), um ungewöhnliche Netzwerkaktivitäten oder DoS-Angriffsmuster zu erkennen und zu blockieren.

Offene Punkte

▸ anzeigen

▸Die genauen CVE-IDs der Schwachstellen sind nicht angegeben.
▸Die spezifischen 'anderen nicht näher bezeichneten Auswirkungen' außer Denial-of-Service sind nicht detailliert.
▸Es ist nicht spezifiziert, welche genauen Versionen des Open Source Linux Kernels betroffen sind.

Red-Team-Relevanz

Was heißt das für dein nächstes Assessment?

▸ Einordnung anzeigen

Initial Access möglich?Unklar
Privilege Escalation relevant?Unklar
Exploit öffentlich verfügbar?Möglich
Detection / Logging prüfbar?Möglich
Für Purple-Team-Szenario geeignet?Unklar

Kundenfragen

Sind wir hiervon betroffen — und können wir es detektieren?

MITRE ATT&CK(1)

Techniken aus allen Quellen zusammengeführt — nach Stärke des Belegs sortiert.

T1499Denial of Servicezugeordnet

„Denial-of-Service-Angriffe auszulösen“

Mehrere Herkünfte bei derselben Technik heißt: mehrere unabhängige Wege führen dorthin.

Quellen & Belege· 1 Quelle

CERT-BundPrimärbelegPUBLICZuverlässigkeit Adiese Meldung

Behoerdliche Veroeffentlichung mit Amtspflicht zur Richtigkeit, frei zugaenglich.

Nur eine Quelle — der Sachverhalt ist an keiner zweiten Stelle gegengelesen.

Verknüpfte Intelligence

Dieselben Entitäten an anderer Stelle auf SecBoard.

CVE-Profile

CVE-2024-58100 CVE-2024-58098 CVE-2024-58237

Themen

mittel

Vollständigen Artikel lesen bei CERT-Bund

Erwähnte CVEs (3)

CVE-2024-58100HIGH(7.8)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: bpf: check changes_pkt_data property for extension programs When processing calls to global sub-programs, verifier decides whether to invalidate all packet pointers in current state depending on the changes_pkt_data property of the global sub-program. Because of this, an extension program replacing a global sub-program must be compatible with changes_pkt_data property of the sub-program being replaced. This commit: - adds changes_pkt_data flag to struct bpf_prog_aux: - this flag is set in check_cfg() for main sub-program; - in jit_subprogs() for other sub-programs; - modifies bpf_check_attach_btf_id() to check changes_pkt_data flag; - moves call to check_attach_btf_id() after the call to check_cfg(), because it needs changes_pkt_data flag to be set: bpf_check: ... ... - check_attach_btf_id resolve_pseudo_ldimm64 resolve_pseudo_ldimm64 --> bpf_prog_is_offloaded bpf_prog_is_offloaded check_cfg check_cfg + check_attach_btf_id ... ... The following fields are set by check_attach_btf_id(): - env->ops - prog->aux->attach_btf_trace - prog->aux->attach_func_name - prog->aux->attach_func_proto - prog->aux->dst_trampoline - prog->aux->mod - prog->aux->saved_dst_attach_type - prog->aux->saved_dst_prog_type - prog->expected_attach_type Neither of these fields are used by resolve_pseudo_ldimm64() or bpf_prog_offload_verifier_prep() (for netronome and netdevsim drivers), so the reordering is safe.

Details NVD

CVE-2024-58098HIGH(7.8)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: bpf: track changes_pkt_data property for global functions When processing calls to certain helpers, verifier invalidates all packet pointers in a current state. For example, consider the following program: __attribute__((__noinline__)) long skb_pull_data(struct __sk_buff *sk, __u32 len) { return bpf_skb_pull_data(sk, len); } SEC("tc") int test_invalidate_checks(struct __sk_buff *sk) { int *p = (void *)(long)sk->data; if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP; skb_pull_data(sk, 0); *p = 42; return TCX_PASS; } After a call to bpf_skb_pull_data() the pointer 'p' can't be used safely. See function filter.c:bpf_helper_changes_pkt_data() for a list of such helpers. At the moment verifier invalidates packet pointers when processing helper function calls, and does not traverse global sub-programs when processing calls to global sub-programs. This means that calls to helpers done from global sub-programs do not invalidate pointers in the caller state. E.g. the program above is unsafe, but is not rejected by verifier. This commit fixes the omission by computing field bpf_subprog_info->changes_pkt_data for each sub-program before main verification pass. changes_pkt_data should be set if: - subprogram calls helper for which bpf_helper_changes_pkt_data returns true; - subprogram calls a global function, for which bpf_subprog_info->changes_pkt_data should be set. The verifier.c:check_cfg() pass is modified to compute this information. The commit relies on depth first instruction traversal done by check_cfg() and absence of recursive function calls: - check_cfg() would eventually visit every call to subprogram S in a state when S is fully explored; - when S is fully explored: - every direct helper call within S is explored (and thus changes_pkt_data is set if needed); - every call to subprogram S1 called by S was visited with S1 fully explored (and thus S inherits changes_pkt_data from S1). The downside of such approach is that dead code elimination is not taken into account: if a helper call inside global function is dead because of current configuration, verifier would conservatively assume that the call occurs for the purpose of the changes_pkt_data computation.

Details NVD

CVE-2024-58237HIGH(7.8)

EPSS 0.2%

In the Linux kernel, the following vulnerability has been resolved: bpf: consider that tail calls invalidate packet pointers Tail-called programs could execute any of the helpers that invalidate packet pointers. Hence, conservatively assume that each tail call invalidates packet pointers. Making the change in bpf_helper_changes_pkt_data() automatically makes use of check_cfg() logic that computes 'changes_pkt_data' effect for global sub-programs, such that the following program could be rejected: int tail_call(struct __sk_buff *sk) { bpf_tail_call_static(sk, &jmp_table, 0); return 0; } SEC("tc") int not_safe(struct __sk_buff *sk) { int *p = (void *)(long)sk->data; ... make p valid ... tail_call(sk); *p = 42; /* this is unsafe */ ... } The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that can invalidate packet pointers. Otherwise, it can't be freplaced with tailcall_freplace.c:entry_freplace() that does a tail call.

Details NVD