Mittel25 / 100Konfidenz: Mittel

CVSS8.1EPSS0.4 %Über Netz erreichbarOhne AnmeldungOhne Zutun des Nutzers

▸Herleitung der Bewertung(2)

Wie der Wert zustande kommt

Hoechster CVSS-Basiswert 8.1+15
Ohne Anmeldung ueber das Netz ausnutzbar (CVE-2026-99246, CVSS-Vektor AV:N/PR:N)+10

Woraus sich die Konfidenz ergibt

Nur ein Herausgeber — keine Gegenlesung
Darunter eine behoerdliche Primaerquelle
Strukturierte CVE-Daten aus der NVD vorhanden

Die Konfidenz misst die Belegqualität, nicht die Schwere.

Einschränkungen

Schmale Datenlage: der Wert beruht auf wenigen Einzelsignalen.
Fuer 41 erkannte CVE(s) liegt noch kein CVSS-Basiswert vor (NVD-Rueckstau).

Bewertung v1.2, deterministisch berechnet. Bedrohungswert und Konfidenz sind getrennte Größen.· 2026-11-06 13:40 UTCMethodik

[NEU] [mittel] Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff

CERT-Bund·3. November 2026, 14:49

Originalartikel lesen bei CERT-Bund

Mehrere Schwachstellen im Linux Kernel ermöglichen Angreifern, nicht näher spezifizierte Angriffe durchzuführen, darunter Denial-of-Service, Datenmanipulation oder -offenlegung sowie die Ausführung von beliebigem Code. Betroffen sind alle Open Source Linux Kernel-Versionen. Nutzer sollten umgehend die bereitgestellten Herstellerinformationen prüfen und entsprechende Updates einspielen, um ihre Systeme zu schützen.

SecBoard-Einordnung

Diese Schwachstellen können zu schwerwiegenden Beeinträchtigungen der Systemverfügbarkeit, der Datenintegrität und der Vertraulichkeit führen, bis hin zur vollständigen Kompromittierung des Systems durch die Ausführung von beliebigem Code.

Realistisch schlimmster Fall: Im schlimmsten Fall könnten Angreifer die vollständige Kontrolle über betroffene Systeme erlangen, sensible Daten manipulieren oder exfiltrieren und die Systemverfügbarkeit durch Denial-of-Service-Angriffe beeinträchtigen.

Empfehlung: Überprüfen Sie umgehend die Herstellerinformationen für Ihre spezifischen Linux-Distributionen und spielen Sie alle verfügbaren Sicherheitsupdates für den Linux Kernel ein.

Key Facts· 12 / 53

Nach Dringlichkeit sortiert: KEV-Eintrag, dann CVSS, dann EPSS. Vollstaendige Liste im Meldungstext.

CVE-2026-99246

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

CVE-2026-99269

CVSS: 7.8 · HIGH
EPSS: 0.1%
Ü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-2026-99236

CVSS: 7.8 · HIGH
EPSS: 0.1%
Ü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-2026-99239

CVSS: 7.8 · HIGH
EPSS: 0.1%
Ü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-2026-99235

CVSS: 7.8 · HIGH
EPSS: 0.1%
Ü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-2026-99233

CVSS: 7.8 · HIGH
EPSS: 0.1%
Ü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-2026-99227

CVSS: 7.8 · HIGH
EPSS: 0.1%
Ü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-2026-99237

CVSS: 7.8 · HIGH
EPSS: 0.1%
Ü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-2026-99238

CVSS: 7.8 · HIGH
EPSS: 0.1%
Ü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-2026-99231

CVSS: 7.8 · HIGH
EPSS: 0.1%
Ü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-2026-99218

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

CVE-2026-99224

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

Betroffen

Alle Systeme, die den Open Source Linux Kernel verwenden, sind betroffen.

Prüfen

▸Überprüfen Sie die installierte Linux Kernel-Version auf allen Systemen.
▸Stellen Sie sicher, dass alle Linux-Systeme die neuesten Sicherheitsupdates und Patches des Herstellers erhalten haben.

▸ 1 weitere

▸Überwachen Sie Systemprotokolle auf ungewöhnliche Aktivitäten oder Anzeichen von Kompromittierung, insbesondere nach der Anwendung von Patches.

Offene Punkte

▸ anzeigen

▸Die spezifischen CVE-IDs der Schwachstellen sind nicht angegeben.
▸Die genauen Angriffsmethoden und die Komplexität der Ausnutzung sind nicht spezifiziert.
▸Es gibt keine Informationen über bekannte Exploits im Umlauf oder ob die Schwachstellen aktiv ausgenutzt werden.

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(4)

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

T1020Automated Exfiltrationzugeordnet

„Datenoffenlegung“

T1059Command and Scripting Interpreterzugeordnet

„Ausführung von beliebigem Code“

T1485Data Destructionzugeordnet

„Datenmanipulation“

T1499Denial of Servicezugeordnet

„Denial-of-Service“

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.

Themen

mittel

Vollständigen Artikel lesen bei CERT-Bund

Erwähnte CVEs (12)

CVE-2026-99246HIGH(8.1)

EPSS 0.4%

In the Linux kernel, the following vulnerability has been resolved: tipc: protect node reset trace dump with node lock The tipc_node_reset_links trace event asks tipc_node_dump() to walk the node's link entries. Unlike the other node events that request link data, this event runs without the node lock. This permits bearer teardown to free a link while the trace callback is dumping it: CPU 0 CPU 1 trace_tipc_node_reset_links() tipc_node_dump() l = n->links[0].link tipc_node_write_lock() kfree(l) n->links[0].link = NULL tipc_node_write_unlock() tipc_link_dump(l) tipc_link_dump() then dereferences the stale pointer. KASAN reported: BUG: KASAN: slab-use-after-free in tipc_link_dump Read of size 4 by task poc/115 Call Trace: tipc_link_dump+0x10cb/0x16b0 tipc_node_dump+0x4bb/0x740 trace_event_raw_event_tipc_node_class+0x258/0x360 tipc_node_reset_links+0x14d/0x1a0 tipc_rcv+0x13f5/0x3030 tipc_udp_recv+0x4e3/0x670 Allocated by task 0: tipc_link_create+0x1e1/0x1020 tipc_node_check_dest+0x7d2/0x11a0 tipc_disc_rcv+0xdbf/0x1430 Freed by task 89: kfree+0x131/0x3c0 tipc_node_link_down+0x267/0x4b0 tipc_node_delete_links+0xec/0x160 bearer_disable+0x107/0x260 Take the node write lock around the trace event. This serializes the dump against tipc_node_link_down(delete=true), which frees the link under the same write lock.

Details NVD

CVE-2026-99269HIGH(7.8)

EPSS 0.1%

In the Linux kernel, the following vulnerability has been resolved: sched_ext: Wait for SCX_OPSS_DISPATCHING before moving tasks off DSQs A task can be found on a non-local DSQ while the CPU which dispatched it is still running ops.dequeue() and hasn't cleared SCX_OPSS_DISPATCHING. The DSQ consume and move paths don't wait for the dispatch to finish and can operate on the task concurrently with the dispatcher. Call scx_wait_dispatching() in scx_move_local_task_to_local_dsq(), unlink_dsq_and_switch_rq_lock() and move_task_between_dsqs() before they operate on the task. In scx_move_local_task_to_local_dsq(), wait before scx_resolve_local_dsq() as it may update p->scx.flags.

Details NVD

CVE-2026-99236HIGH(7.8)

EPSS 0.1%

In the Linux kernel, the following vulnerability has been resolved: tracing: Reject incomplete event filter expressions A non-empty expression normally finishes in predicate_parse()'s inner loop, which resolves the pending logical operators before jumping to finalization. If the input ends after an operator, possibly followed by unary '!' tokens, the outer loop instead falls through with unresolved operator state. For example, "common_pid == 1 || common_pid == 2 &&" leaves prog[0].target equal to -1. The second pass then reads prog[-1] before the forward-jump check can reject it. Depending on adjacent slab contents, it can also copy an out-of-bounds word into a branch target that passes the forward-only check. A self-targeted perf tracepoint counting event can reach this path through PERF_EVENT_IOC_SET_FILTER. Reject the outer-loop fallthrough when a predicate has already been parsed. This ensures that non-empty expressions only reach finalization after the inner loop has resolved their operators. Keep the existing no-filter error for input that has no predicates. Add a regression test for trailing logical operators and unary negations.

Details NVD

CVE-2026-99239HIGH(7.8)

EPSS 0.1%

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: refuse __l2cap_chan_add if chan already has conn l2cap_chan may be linked to l2cap_conn at most once. This is assumed in several places, eg l2cap_chan_del cleanup. There is a TOCTOU race where the invariant is violated: [Task 1] [Task 2] l2cap_chan_connect l2cap_sock_bind l2cap_chan_lock lock_sock l2cap_state_change if (sk->sk_state != BT_OPEN) chan->state = BT_CONNECT l2cap_sock_state_change_cb chan->state = BT_BOUND sk->sk_state = BT_BOUND lock_sock <------------------ release_sock sk->sk_state = BT_CONNECT l2cap_sock_connect() does not check sk->sk_state, so since chan->state is now BT_BOUND, subsequent connect() ends up with second __l2cap_chan_add. Explicitly document and check the invariant in __l2cap_chan_add with WARN_ON_ONCE. The only callsite where it could be hit is l2cap_chan_connect, so add pre-check there to avoid relying on chan->state. chan->state read/write is not properly guarded currently so there can be other TOCTOUC problems. Add l2cap_lock_chan in l2cap_sock_bind() to guard chan->state write.

Details NVD

CVE-2026-99235HIGH(7.8)

EPSS 0.1%

In the Linux kernel, the following vulnerability has been resolved: tracing: Save the event file instead of the compatible histogram create_field_var_hist() creates a histogram on the matched event to supply a field variable, and records it on the target so it can be torn down later: hist_data = find_compatible_hist(target_hist_data, file); ... /* Save the compatible histogram information */ var_hist->hist_data = hist_data; hist_data is not the histogram it creates. It is one that was already there, whose keys the new one copies. The saved pointer has a single user, unregister_field_var_hists(), which runs when the target is removed: file = hist_data->field_var_hists[i]->hist_data->event_file; find_compatible_hist() matches on keys alone, so it can pick one with no variables of its own. check_var_refs() then returns false and the user can remove it while the target still points at it: BUG: KASAN: slab-use-after-free in event_hist_trigger_free+0x2b2/0x320 Read of size 8 at addr ffff8880093b90e0 by task init/1 Freed by task 1: kfree+0x154/0x420 event_hist_trigger_free+0x1d5/0x320 event_hist_trigger_parse+0x35f3/0x69e0 trigger_process_regex+0x1a6/0x250 Save the event file instead. It is all the dereference ever wanted, and it does not go away when the user removes a trigger.

Details NVD

CVE-2026-99233HIGH(7.8)

EPSS 0.1%

In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Verify event_call identity when updating synth_event refcount In event_hist_trigger_parse() and hist_unreg_all(), the histogram registration and unregistration paths look up find_synth_event() using trace_event_name(file->event_call) and adjust se->ref if a match is found. Because find_synth_event() only compares the event basename, registering or removing a histogram on a non-synthetic trace event whose basename matches a synthetic event erroneously modifies the synthetic event's reference count. If a histogram is registered on the non-synthetic event before the synthetic event is created and removed afterwards, se->ref is decremented without a matching increment, allowing the synthetic event to be freed while an active histogram action still holds a pointer to it. Introduce find_synth_event_call() to verify that &se->call matches file->event_call before adjusting se->ref.

Details NVD

CVE-2026-99227HIGH(7.8)

EPSS 0.1%

In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: prevent cancel reference wrap io_waitid packs the cancellation state into bit 31 of ->refs and uses bits 30:0 as a 31-bit reference counter: #define IO_WAITID_CANCEL_FLAG BIT(31) #define IO_WAITID_REF_MASK GENMASK(30, 0) __io_waitid_cancel() marks a request canceled, then increments the low bits of ->refs to claim completion ownership. When another path owns the request, the increment remains even though cancellation returns false. The request remains discoverable by cancellation, so repeated failed attempts can wrap the 31-bit reference field to zero. A later cancellation can claim ownership and complete the request a second time. Use atomic_fetch_or() when setting the cancel flag and inspect the old flag value. The first cancel attempt continues to the existing ownership increment, preserving its wake and issuer handoff semantics. Later attempts see the cancel flag and return without incrementing the reference field. This makes repeated failed cancellation attempts idempotent while leaving the first-cancel state transitions unchanged.

Details NVD

CVE-2026-99237HIGH(7.8)

EPSS 0.1%

In the Linux kernel, the following vulnerability has been resolved: tracing: Hold trace_types_lock when resetting last boot data from readers update_last_data_if_empty() is called from tracing_open() with O_TRUNC, tracing_read_pipe() and tracing_buffers_read() without trace_types_lock. Two readers can both pass the LAST_BOOT test and free module_delta twice, and a module notifier can update module_delta while it is being freed. Take trace_types_lock in those paths and keep the callers that already hold it on an unlocked variant.

Details NVD

CVE-2026-99238HIGH(7.8)

EPSS 0.1%

In the Linux kernel, the following vulnerability has been resolved: tracing: Hold trace_types_lock when updating modules in persistent instances trace_module_record() walks ftrace_trace_arrays from the module notifier without trace_types_lock. A concurrent rmdir of an instance removes it from the list and frees it under that lock, so a module load or unload can walk into a freed trace_array.

Details NVD

CVE-2026-99231HIGH(7.8)

EPSS 0.1%

In the Linux kernel, the following vulnerability has been resolved: io_uring/waitid: own the request before clearing ->head io_waitid_remove_wq() only takes the wait queue lock if ->head is set. io_waitid_wait() clears ->head first thing, before it tries to become the owner of the request by bumping ->refs. If somebody else owns the request at that point, nothing keeps it from completing the request while the wake up handler is still going to touch it: CPU0 (io_waitid_wait) CPU1 (io_waitid, holds a ref) list_del_init(&wait->entry) smp_store_release(&iw->head, NULL) __do_wait() finds another child io_waitid_remove_wq() // ->head == NULL, no locking io_waitid_finish(), IOU_COMPLETE // request freed and reused atomic_fetch_inc(&iw->refs) The same goes for __io_waitid_cancel() if it claims the request in that window. ->refs is part of the per opcode data of the request, so this increments whatever the next user of the request keeps there. If that happens to be zero, the handler concludes that it owns the request, and queues io_waitid_cb() for it. With the window held open by a delay, and the request reused for a receive that is waiting for data: BUG: KASAN: slab-use-after-free in __wake_up_common+0x1ca/0x1f0 __wake_up_sync_key+0x36/0x50 sock_def_readable+0xf1/0x420 unix_stream_sendmsg+0x60b/0x1110 Allocated by task 87: io_arm_apoll+0x1ed/0x940 Freed by task 87: __io_submit_flush_completions+0x118d/0x1a10 tctx_task_work_run+0x327/0x950 Only clear ->head once the handler owns the request. If it doesn't, the owner finds ->head set and has to wait for the lock, which is held by the caller of the handler. Deleting the already deleted entry again is harmless.

Details NVD

CVE-2026-99218HIGH(7.0)

EPSS 0.1%

In the Linux kernel, the following vulnerability has been resolved: coredump: hold RCU while releasing parked threads coredump_finish() releases the parked threads by clearing ->task in their core_thread entry and calling wake_up_process() on each of them. It does that without holding a reference on the task and without being inside rcu. But calling wake_up_process(task) without rcu here isn't safe. A parked thread doesn't need that wakeup to leave. A spurious wakeup or a preemption after the store is enough for the task to go away. So if the coredump client is preempted between the store and wake_up_process() the thread can exit and be freed in the meantime and try_to_wake_up() takes pi_lock in freed memory. Hold rcu across the loop.

Details NVD

CVE-2026-99224HIGH(7.0)

EPSS 0.1%

In the Linux kernel, the following vulnerability has been resolved: keys: Protect the type name while describing a key keyctl_describe_key() must keep the key type's name alive until kasprintf() has consumed it. The retained key reference keeps the key and its description alive, but does not pin the module providing its type. The name is passed to kasprintf() without holding key->sem. kvasprintf() uses the saved name pointer in two formatting passes, with a GFP_KERNEL allocation between them. With AF_RXRPC=m, a task that passes View permission before type retirement can overlap a privileged module unload in this order: 1. KEYCTL_DESCRIBE looks up the key, saves key->type->name in the kasprintf() arguments and completes the first formatting pass. 2. While the formatter is delayed before its second pass, af_rxrpc_exit() calls unregister_key_type(), which removes the type from the registry and waits for key_gc_keytype(). 3. The collector takes key->sem for writing, retypes the retained key to key_type_dead and completes retirement. Unregistration and module exit return, allowing free_module() to release the type and name. 4. The formatter resumes its second pass and reads the saved name from released module storage, which can fault in string(). Hold key->sem for reading across kasprintf(). The collector then cannot retype the key or complete retirement until both formatting passes have finished. If retirement wins the lock first, formatting uses the core key_type_dead name instead. Release the semaphore immediately after kasprintf(), including on allocation failure, before copying to userspace. Oops report as below: BUG: unable to handle page fault for address: fffffbfff8054794 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page RIP: 0010:string+0x23f/0x470 Call Trace: vsnprintf+0x330/0x1110

Details NVD