CVE-Datenbank

Im Linux-Kernel wurde die folgende Schwachstelle behoben: bpf: sk_state vor sk_protocol in bpf_tcp_*_syncookie prüfen bpf_tcp_gen_syncookie und bpf_tcp_check_syncookie akzeptieren einen Socket-Zeiger 'sk' mit dem Argumenttyp ARG_PTR_TO_BTF_ID_SOCK_COMMON. Sie greifen jedoch auf sk->sk_protocol zu, ohne zu prüfen, ob 'sk' einen vollständigen Socket darstellt. Dieses Problem beheben, indem sk->sk_state != TCP_LISTEN geprüft wird, bevor sk->sk_protocol sowohl in bpf_tcp_gen_syncookie als auch in bpf_tcp_check_syncookie untersucht wird. Da sich Mini-Sockets niemals im Zustand TCP_LISTEN befinden, wird die Bedingung kurzgeschlossen und verhindert die Dereferenzierung Fullsock-spezifischer Felder.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: serial: amba-pl011: DMA-Teardown synchronisieren dmaengine_terminate_all() wartet nicht auf einen laufenden Callback, sodass der TX-Callback den TX-Buffer nach dessen Freigabe noch berühren kann. Der RX-Poll-Timer liest die RX-Buffer ohne den Port-Lock. Zu dmaengine_terminate_sync() wechseln und den RX-Timer vor der Freigabe der Buffer löschen.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: net: WARN_ON_ONCE() aus sk_mc_loop() entfernen sk_mc_loop() kann für Sockets aufgerufen werden, die weder AF_INET noch AF_INET6 sind (z. B. AF_PACKET-Sockets beim Senden von Paketen über raw/packet-Socket über virtuelle Geräte wie VRF oder ipvlan). In solchen Fällen ist sk_family nicht AF_INET/AF_INET6 und sk_mc_loop() fällt durch die switch-Anweisung und löst WARN_ON_ONCE(1) aus. Nicht-INET-Sockets unterstützen die Optionen IP_MULTICAST_LOOP oder IPV6_MULTICAST_LOOP nicht, daher sollte loopback standardmäßig auf true stehen, ohne eine Warnung zu erzeugen.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: ata: pata_sl82c105: fix bridge revision use-after-free pci_get_slot() gibt ein referenziertes PCI-Gerät zurück. Commit 44c10138fd4b ("PCI: Change all drivers to use pci_device->revision") ersetzte ein Auslesen des Konfigurationsbereichs durch direkten Zugriff auf das zwischengespeicherte Revisionsfeld, beließ diesen Zugriff jedoch nach pci_dev_put(). Die Bridge kann daher freigegeben werden, bevor ihre Revision gelesen wird. Die Revision vor der Freigabe der Referenz lesen.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: net: CAP_SYS_RAWIO-Zero-Padding in dev_validate_header entfernen dev_validate_header() liest dev->hard_header_len direkt beim Zero-Padding kurzer Link-Layer-Header für Inhaber von CAP_SYS_RAWIO: if (capable(CAP_SYS_RAWIO)) { memset(ll_header + len, 0, dev->hard_header_len - len); return true; } Paketsendepfade rufen dev_validate_header() für skbs auf, deren Headroom aus einem früheren hard_header_len-Lesevorgang allokiert wurde. Wenn das Gerät so rekonfiguriert wird, dass dev->hard_header_len vor der Validierung steigt, schreibt das memset über den reservierten Puffer hinaus, ein out-of-bounds write. Dieser out-of-bounds write ist heute in einigen SOCK_RAW-Pfaden verdeckt, weil dieselbe gleichzeitige Erhöhung zuerst dazu führen kann, dass skb_push() den reservierten Headroom überschreitet und skb_under_panic() auslöst. Den Zero-Padding-Zweig entfernen, bevor diese hard_header_len-Lesevorgänge konsistent gemacht werden, damit die Snapshot-Fixes keinen lauten Panic in ein stilles Überschreiben verwandeln. Dieser Pfad wird nur für L2-Protokolle variabler Länge erreicht, bei denen len < hard_header_len, aber len >= min_header_len gilt. Kein verbleibendes In-Tree-L2-Protokoll variabler Länge implementiert header_ops->validate, und der CAP_SYS_RAWIO-Bypass, der kurze Header mit Zero-Padding auffüllt und akzeptiert, hat keinen realen Wert über das Ermöglichen des Testens absichtlich fehlerhafter Eingaben hinaus. Den CAP_SYS_RAWIO-Zweig entfernen. Die verbleibenden Lesevorgänge von dev->hard_header_len in dev_validate_header() sind nur Vergleiche und haben keine Auswirkungen auf die Speichersicherheit.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: ring-buffer: Absturz bei Übergabe von ERR_PTR an kthread_stop() beheben In der out_free-Bereinigungsschleife von test_ringbuffer() erkennt die Prüfung `!rb_threads[cpu]` nur NULL-Einträge und übersieht Einträge, die einen ERR_PTR enthalten. rb_threads[] ist static, daher sind nicht zugewiesene Slots NULL. Aber wenn kthread_run_on_cpu() für eine CPU fehlschlägt, speichert es ERR_PTR(-ENOMEM) (oder -EINTR) in rb_threads[cpu], bevor die Erstellungsschleife zu out_free springt. Dieser Eintrag ist nicht NULL, sodass die alte `!ptr`-Prüfung nicht abbricht und die Bereinigung fortfährt, kthread_stop() mit dem ERR_PTR aufzurufen. kthread_stop() dereferenziert dann den ungültigen Zeiger, wodurch der Kernel während des late_initcall-Selbsttests abstürzt. Absturzprotokolle: BUG: kernel NULL pointer dereference, address: 000000000000001c Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 1 Comm: swapper/0 Not tainted 7.2.0-rc6-dirty #7 PREEMPT(lazy) RIP: 0010:kthread_stop+0x2e/0x220 RBX: fffffffffffffff4 CR2: 000000000000001c Call Trace: <TASK> test_ringbuffer+0x1ec/0x650 do_one_initcall+0x6c/0x2c0 kernel_init_freeable+0x21d/0x420 kernel_init+0x15/0x1c0 ret_from_fork+0x21b/0x320 </TASK> Kernel panic - not syncing: Fatal exception

Im Linux-Kernel wurde die folgende Schwachstelle behoben: Revert "drm/amdgpu: fix aperture mapping leak" devres-Teardown ist LIFO. Der aperture-devres-Node wurde nach dem DRM-Device-Node registriert, sodass devres_release_all() das Mapping der Aperture aufhebt, bevor der DRM-Device-Release-Callback amdgpu_device_fini_sw() auslöst. IP- sw_fini-Callbacks (z. B. vcn_v4_0_sw_fini) schreiben über einen von aper_base_kaddr abgeleiteten Zeiger nach fw_shared, was bei Probe-Fehler / Rollback einen Kernel-Page-Fault verursacht: BUG: unable to handle page fault ... PMD 0 RIP: vcn_v4_0_sw_fini+0x7b/0x170 [amdgpu] Call Trace: amdgpu_device_fini_sw amdgpu_driver_release_kms devm_drm_dev_init_release devres_release_all Dies setzt den Commit d871e99879cb5fd1fa798b006b4888887e63a17a zurück. (cherry picked from commit 336e0cd576817ac64a4b394ca2b3680029f3e37f)

Im Linux-Kernel wurde die folgende Schwachstelle behoben: KVM: x86/mmu: WARN ausgeben und role.invalid beim Erstellen einer untergeordneten Shadow Page löschen role.invalid beim Ableiten der Rolle einer untergeordneten Shadow Page aus ihrer übergeordneten Seite explizit löschen, um gegen Fehler an anderer Stelle in KVM abzusichern, da die Verletzung von KVMs Invariante, dass ungültige Seiten NICHT auf der Liste aktiver MMU-Seiten stehen, zu einem Use-after-free führt, weil __kvm_mmu_prepare_zap_page() beim Verarbeiten einer ungültigen Shadow Page list_add() statt list_move() verwendet, d. h. eine bereits schlechte Situation noch deutlich verschlimmert. Eine deutliche Warnung ausgeben, wenn der Parent ungültig ist, da dies bedeutet, dass KVM eine Gültigkeitsprüfung übersehen hat, d. h. KVM versucht, Speicher mithilfe einer ungültigen/veralteten Root zu mappen, aber fortfahren, da das Kind ansonsten weiterhin eine gültige Shadow Page ist. ================================================================== BUG: KASAN: slab-use-after-free in __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm] Write of size 8 at addr ff11000153dd1368 by task repro/853 CPU: 1 UID: 1000 PID: 853 Comm: repro Not tainted 7.2.0-rc2-3aec122bdcaf-next-vm #5 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x4b/0x70 print_report+0x153/0x49c kasan_report+0xbc/0xf0 __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm] mmu_alloc_root+0x141/0x320 [kvm] kvm_mmu_load+0x612/0x20f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3dd5/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> Allocated by task 853: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x5f/0x70 kmem_cache_alloc_noprof+0xfe/0x2e0 __kvm_mmu_topup_memory_cache+0x135/0x530 [kvm] paging64_page_fault+0x318/0x1e30 [kvm] kvm_mmu_do_page_fault+0x21d/0x630 [kvm] kvm_mmu_page_fault+0x18c/0x17b0 [kvm] kvm_arch_vcpu_ioctl_run+0x1f35/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 853: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free+0xe2/0x400 kvm_mmu_commit_zap_page.part.0+0x1e2/0x310 [kvm] kvm_mmu_free_roots+0x283/0x560 [kvm] kvm_arch_vcpu_ioctl_run+0x33c8/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Zuvor war ein in der chanList des Mux registrierter Channel bis zu seiner Etablierung nicht nutzbar. Ein böswilliger Peer konnte die incomingRequests des Channels fluten und dadurch die gesamte Connection in einen Deadlock versetzen. Jetzt fügen wir einen atomaren established-State hinzu, der gesetzt wird, wenn ein Channel nutzbar wird. Bis zu diesem Zeitpunkt verwirft handlePacket jedes Paket außer der Open-Bestätigung/-Ablehnung, ohne zu blockieren und ohne die Connection abzubauen.

Mehrere Schwachstellen in der Secure/Multipurpose Internet Mail Extensions (S/MIME)-Entschlüsselungsfunktionalität von Cisco Secure Email könnten es einem nicht authentifizierten, Remote-Angreifer ermöglichen, Klartext aus verschlüsselten E-Mail-Nachrichten wiederherzustellen. Diese Schwachstellen sind auf eine unzureichende Validierung der Nachrichtenintegrität zurückzuführen. Ein Angreifer könnte diese Schwachstellen ausnutzen, indem er eine Machine-in-the-Middle-Technik verwendet, um den Datenverkehr zwischen E-Mail-Gateways abzufangen und zu modifizieren. Ein erfolgreicher Exploit könnte es dem Angreifer ermöglichen, Klartextinhalte aus der verschlüsselten Kommunikation zu erhalten.

Mehrere Schwachstellen in der Secure/Multipurpose Internet Mail Extensions (S/MIME)-Entschlüsselungsfunktionalität von Cisco Secure Email könnten es einem nicht authentifizierten Remote-Angreifer ermöglichen, Klartext aus verschlüsselten E-Mail-Nachrichten wiederherzustellen. Diese Schwachstellen sind auf eine unzureichende Validierung der Nachrichtenintegrität zurückzuführen. Ein Angreifer könnte diese Schwachstellen ausnutzen, indem er mit einer Machine-in-the-Middle-Technik den Datenverkehr zwischen E-Mail-Gateways abfängt und modifiziert. Ein erfolgreicher Exploit könnte es dem Angreifer ermöglichen, Klartextinhalte aus der verschlüsselten Kommunikation zu erhalten.

Eine Schwachstelle in Cisco Desk Phone 9800 Series, Cisco IP Phone 7800 and 8800 Series, and Cisco Video Phone 8875, auf denen Cisco Session Initiation Protocol (SIP) Software ausgeführt wird, könnte es einem nicht authentifizierten Remote-Angreifer ermöglichen, einen Denial-of-Service (DoS)-Zustand auf einem betroffenen Gerät zu verursachen. Diese Schwachstelle beruht auf unsachgemäßer Speicherverwaltung, wenn ein betroffenes Gerät HTTP-Pakete verarbeitet. Ein Angreifer könnte diese Schwachstelle ausnutzen, indem er einen kontinuierlichen Strom speziell gestalteter HTTP-Pakete an das Gerät sendet. Eine erfolgreiche Ausnutzung könnte es dem Angreifer ermöglichen, das betroffene Gerät dazu zu bringen, kontinuierlich Speicher zu verbrauchen, was zu einem DoS-Zustand führt. Zur Behebung dieses Zustands ist ein manueller Neustart des Geräts erforderlich. Hinweis: Damit diese Schwachstelle ausnutzbar ist, muss das Telefon bei Cisco Unified Communications Manager (Unified CM) registriert sein und Web Access aktiviert haben. Web Access ist standardmäßig deaktiviert.

Als Teil von Ciscos fortlaufendem Engagement für proaktive Sicherheit und Produktqualität hat das Cisco IOS XR Software Engineering-Team eine umfassende interne Sicherheitsüberprüfung durchgeführt. Diese Überprüfung führte zu Software-Hardening-Releases, die mehrere intern entdeckte Schwachstellen beheben. Die unter CVE-2026-20280 verfolgten Schwachstellen beziehen sich auf Probleme bei der unsachgemäßen Prüfung oder Behandlung von Ausnahmebedingungen, die unter der Common Weakness Enumeration (CWE) CWE-703 gruppiert sind.

Im Rahmen des fortlaufenden Engagements von Cisco für proaktive Sicherheit und Produktqualität hat das Cisco IOS XR Software-Engineering-Team eine umfassende interne Sicherheitsüberprüfung durchgeführt. Diese Überprüfung führte zu Software-Hardening-Releases, die mehrere intern entdeckte Schwachstellen beheben. Die unter CVE-2026-20279 erfassten Schwachstellen betreffen Probleme mit unsachgemäßer Zugriffskontrolle, die unter der Common Weakness Enumeration (CWE) CWE-284 zusammengefasst sind.

Im Rahmen des fortlaufenden Engagements von Cisco für proaktive Sicherheit und Produktqualität hat das Engineering-Team für Cisco IOS XR Software eine umfassende interne Sicherheitsprüfung durchgeführt. Diese Prüfung hat zu Software-Hardening-Releases geführt, die mehrere intern entdeckte Schwachstellen beheben. Die unter CVE-2026-20278 erfassten Schwachstellen stehen im Zusammenhang mit Improper Neutralization-Problemen, die unter der Common Weakness Enumeration (CWE) CWE-707 zusammengefasst sind.

Im Rahmen des fortlaufenden Engagements von Cisco für proaktive Sicherheit und Produktqualität hat das Cisco IOS XR Software-Engineering-Team eine umfassende interne Sicherheitsüberprüfung durchgeführt. Diese Überprüfung führte zu Software-Hardening-Releases, die mehrere intern entdeckte Schwachstellen beheben. Die unter CVE-2026-20277 verfolgten Schwachstellen stehen im Zusammenhang mit Problemen durch Versagen des Schutzmechanismus, die unter der Common Weakness Enumeration (CWE) CWE-693 zusammengefasst sind.

Im Rahmen des fortlaufenden Engagements von Cisco für proaktive Sicherheit und Produktqualität hat das Cisco IOS XR Software-Engineering-Team eine umfassende interne Sicherheitsüberprüfung durchgeführt. Diese Überprüfung führte zu Software-Hardening-Releases, die mehrere intern entdeckte Schwachstellen beheben. Die unter CVE-2026-20276 erfassten Schwachstellen betreffen Probleme mit unzureichendem Control Flow Management, die unter der Common Weakness Enumeration (CWE) CWE-691 zusammengefasst sind.

Im Rahmen des fortlaufenden Engagements von Cisco für proaktive Sicherheit und Produktqualität hat das Engineering-Team der Cisco IOS XR Software eine umfassende interne Sicherheitsüberprüfung durchgeführt. Diese Überprüfung führte zu Software-Hardening-Releases, die mehrere intern entdeckte Schwachstellen beheben. Die unter CVE-2026-20275 erfassten Schwachstellen betreffen Probleme durch fehlerhafte Berechnung, die unter der Common Weakness Enumeration (CWE) CWE-682 zusammengefasst sind.

Im Rahmen des fortlaufenden Engagements von Cisco für proaktive Sicherheit und Produktqualität hat das Cisco IOS XR Software-Engineering-Team eine umfassende interne Sicherheitsüberprüfung durchgeführt. Diese Überprüfung hat zu Software-Hardening-Releases geführt, die mehrere intern entdeckte Schwachstellen beheben. Die unter CVE-2026-20274 erfassten Schwachstellen beziehen sich auf Probleme mit unsachgemäßer Ressourcenkontrolle, die unter der Common Weakness Enumeration (CWE) CWE-664 zusammengefasst sind.

Eine Schwachstelle in der Silicon One-Integration für Cisco Nexus 9000 Series Switches könnte einem nicht authentifizierten, entfernten Angreifer das Ausführen von Code mit Root-Rechten ermöglichen. Diese Schwachstelle besteht, weil die TCP-Ports 43210 und 43211 im standardmäßigen Layer-3 (L3) Virtual Routing and Forwarding (VRF) erreichbar sind. Ein erfolgreicher Exploit könnte es dem Angreifer ermöglichen, eine Verbindung zu einem betroffenen Gerät herzustellen und manipulierte Eingaben zu senden, die als Code mit Root-Rechten ausgeführt werden könnten. Die Ausnutzung dieser Schwachstelle könnte außerdem dazu führen, dass der S1HAL-Prozess abstürzt, was einen Neustart des Geräts verursachen könnte.