CVE-Datenbank

Eine stackbasierte Buffer-Overflow-Schwachstelle besteht im EasyMesh-Modul von TP-Link Archer AX55 v4. Wenn der Mesh-Modus aktiviert ist, kann ein LAN-Angreifer manipulierte Eingaben übermitteln, die zum Absturz des easymesh-Daemons führen und potenziell die Ausführung von Remote-Code auf dem Gerät ermöglichen. Eine erfolgreiche Ausnutzung kann zum Absturz des EasyMesh-Daemons führen und bei aktiviertem Mesh-Modus potenziell die Ausführung von Remote-Code ermöglichen. Dies kann erhebliche Auswirkungen auf die Vertraulichkeit, Integrität und Verfügbarkeit des betroffenen Geräts haben.

MapLibre GL JS ist eine interaktive Vektorkachelkartenbibliothek für Webbrowser. Vor 6.4.1 iteriert DOM.sanitize() in src/util/dom.ts über elem.attributes als live NamedNodeMap, während removeAttributes() Attribute aus derselben Sammlung entfernt, wodurch sich die Indizes verschieben und ein benachbartes gefährliches Attribut übersprungen wird. Ein Angreifer, der nicht vertrauenswürdige Attributionszeichenfolgen von Drittanbietern oder vom Benutzer bereitgestellte benutzerdefinierte Attributionen kontrolliert, kann aufeinanderfolgende gefährliche Attribute einschleusen, wodurch ein Attribut wie onload oder ontoggle die Bereinigung übersteht und ausgeführt wird, wenn das Attributionssteuerelement den Inhalt in innerHTML einfügt. Ein Opfer muss den betroffenen Karteninhalt rendern, damit das Skript ausgeführt wird. Dieses Problem ist in Version 6.4.1 behoben.

Typenverwechslung in V8 in Google Chrome vor 152.0.7977.82 ermöglichte es einem entfernten Angreifer, über eine speziell gestaltete HTML-Seite beliebigen Code innerhalb der Sandbox auszuführen. (Chromium-Sicherheitsschweregrad: Hoch)

GeoNetwork ist eine Kataloganwendung zur Verwaltung raumbezogener Ressourcen. Vor den Versionen 4.4.12 und 4.2.17 ist der API-Endpunkt zur Erstellung eines neuen Formatters per Datei-Upload ungeschützt und ermöglicht den Upload externer unkontrollierter Dateien. Ein nicht authentifizierter Angreifer kann beliebige `.xsl`- oder `.zip`-Formatter-Dateien auf den Server hochladen. Ein nicht authentifizierter Angreifer kann beliebige Dateien in das GeoNetwork-Formatter-Verzeichnis schreiben. Für sich genommen stellt dies einen unbefugten Schreibzugriff auf den Serverspeicher dar. Das Problem ist in den GeoNetwork-Versionen 4.4.12 und 4.2.17 behoben.

GeoNetwork ist eine Kataloganwendung zur Verwaltung raumbezogener Ressourcen. Vor den Versionen 4.4.12 und 4.2.17 ist der zum Rendern von Formatierern verwendete Saxon XSLT-Prozessor ohne Secure Processing (`FEATURE_SECURE_PROCESSING`) und ohne Deaktivierung der Java-Erweiterungsfunktionen (`ALLOW_EXTERNAL_FUNCTIONS`) konfiguriert. Jedes von GeoNetwork geladene Stylesheet kann daher `java.lang.Runtime.exec()` oder `java.lang.ProcessBuilder` direkt aufrufen und so beliebige Befehlsausführung als GeoNetwork-Prozessbenutzer erreichen. Ein Benutzer mit ausreichenden Berechtigungen zum Hochladen eines Formatierers kann eine `.xsl`-Datei mit einem Java-Erweiterungsaufruf bereitstellen, der beliebige OS-Befehle mit den Berechtigungen des GeoNetwork-Prozesses ausführt. Das Problem ist in den GeoNetwork-Versionen 4.4.12 und 4.2.17 behoben.

Hermes Agent 0.18.2 bis 0.21.0, behoben in Commit f6234d0, enthält eine Remote-Code-Execution-Schwachstelle, die es Angreifern ermöglicht, beliebige OS-Befehle auszuführen, indem sie ein bösartiges Repository mit einer präparierten .git/config bereitstellen, die core.fsmonitor auf einen angreiferkontrollierten Befehl setzt. Wenn ein Benutzer das bösartige Repository öffnet und eine beliebige Nachricht sendet, löst der Agent eine Aktualisierung des git-status-Index aus, die den injizierten Befehl im Prozesskontext des Benutzers ausführt und die gesamte Umgebung einschließlich konfigurierter Provider-API-Schlüssel offenlegt.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: drm/amdkfd: Bounds-Check für CRAT-Subtype-Länge hinzufügen Der CRAT-Parser validiert, dass der Subtype-Header innerhalb des Images liegt, aber verifiziert nicht, dass die angegebene Subtype-Länge passt. Eine fehlerhafte CRAT-Tabelle mit einem übergroßen Längenfeld verursacht Out-of-Bounds-Reads, wenn kfd_parse_subtype() den Header in bestimmte Subtype-Strukturen castet. Validierung hinzufügen, dass sub_type_hdr + length die Image-Grenze nicht überschreitet, bevor die Subtype-Inhalte geparst werden. (cherry-picked aus Commit 48e1d1e6e8798aef0312e68d8e586021b5b3cf4d)

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: 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: selinux: eine Klassen-Berechtigungsanzahl unterhalb des geerbten Common ablehnen security_get_permissions() bildet die Berechtigungen eines geerbten Common in ein Array ab, das mit permissions.nprim der Klasse dimensioniert ist, aber class_read() übernimmt dieses nprim unverändert aus dem Policy-Image und prüft nie, ob es das Common abdeckt. Eine Klasse, die ein Common mit N Berechtigungen erbt und dabei ein kleineres nprim deklariert, wird akzeptiert, und beim Laden werden die Berechtigungen des Common über das klassengroße Array hinaus geschrieben -- ein out-of-bounds heap write. Eine Klasse ablehnen, deren Berechtigungsanzahl unter der ihres geerbten Common liegt. Wohlgeformte Policies, bei denen die Klassenzahl bereits die geerbten Berechtigungen einschließt, sind nicht betroffen.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: netfilter: nf_tables_offload: WARN_ON_ONCE für ENOMEM im Abbruch-Pfad unterdrücken In nft_flow_rule_offload_abort() wird WARN_ON_ONCE(err) bei jedem Fehler während des Rollbacks ausgelöst, einschließlich -ENOMEM. Speicherzuweisungsfehler werden unter Bedingungen mit wenig Speicher erwartet und weisen nicht auf einen Kernel-Bug hin. Trace zum Beispiel: nft_flow_offload_chain() // FLOW_BLOCK_BIND nft_flow_block_chain() nft_chain_offload_cmd() nft_block_offload_cmd() ->ndo_setup_tc() nsim_setup_tc() flow_block_cb_setup_simple() flow_block_cb_alloc() // fails to -ENOMEM Die Warnung wurde auf dem 5.10 stable-Kernel unter Speicherdruck mittels Fault Injection reproduziert, aber der zugrundeliegende Bug existiert auch im Mainline, wie der obige ENOMEM-Trace zeigt. Der folgende Splat wurde während der nf_tables-Transaktionsverarbeitung ausgelöst: WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] WARNING: CPU: 0 PID: 8567 at net/netfilter/nf_tables_offload.c:532 nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Modules linked in: CPU: 0 PID: 8567 Comm: syz-executor.0 Not tainted 5.10.260-syzkaller #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:nft_flow_rule_offload_abort net/netfilter/nf_tables_offload.c:532 [inline] RIP: 0010:nft_flow_rule_offload_commit+0x971/0xcd0 net/netfilter/nf_tables_offload.c:591 Call Trace: nf_tables_commit+0x3bd/0x4bd0 net/netfilter/nf_tables_api.c:8604 nfnetlink_rcv_batch+0xb1e/0x1f20 net/netfilter/nfnetlink.c:509 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:579 [inline] nfnetlink_rcv+0x3b3/0x420 net/netfilter/nfnetlink.c:597 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x6cd/0xa00 net/netfilter/af_netlink.c:1340 netlink_sendmsg+0x906/0xe10 net/netfilter/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x155/0x190 net/socket.c:663 ____sys_sendmsg+0x705/0x870 net/socket.c:2379 ___sys_sendmsg+0x100/0x170 net/socket.c:2433 __sys_sendmsg+0xe9/0x1c0 net/socket.c:2462 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Ändern Sie die Bedingung zu WARN_ON_ONCE(err && err != -ENOMEM), sodass Warnungen nur für unerwartete Fehler ausgegeben werden. Dies entspricht der gängigen Kernel-Praxis, bei -ENOMEM keine Warnung auszugeben. Gefunden von Linux Verification Center (linuxtesting.org) mit Syzkaller.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: ASoC: xilinx: formatter_pcm: aud_drv_data an die irq-Handler übergeben Die irq-Handler übernehmen einen struct device-Zeiger und rufen dev_get_drvdata() auf, um die Treiberdaten zu erhalten. Die Treiberdaten werden jedoch erst am Ende von probe, nach devm_request_irq(), gesetzt, sodass ein dazwischen auftretender Interrupt dazu führt, dass die Handler einen NULL-Zeiger an readl() übergeben und abstürzen. Die privaten Daten direkt als devm_request_irq()-Argument anstelle des Gerätezeigers übergeben, entsprechend dem, was die Handler erwarten.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: af_packet: Keine Daten mit null Bytes in tpacket_snd() senden. syzbot meldete eine WARNING in __dev_queue_xmit(), ausgelöst über tpacket_snd(): skb_assert_len WARNING: at include/linux/skbuff.h:2753 skb_assert_len WARNING: at __dev_queue_xmit+0x21bc/0x4970 net/core/dev.c:4781 Call Trace: <TASK> dev_queue_xmit include/linux/netdevice.h:3448 [inline] packet_xmit+0x243/0x310 net/packet/af_packet.c:276 tpacket_snd net/packet/af_packet.c:2907 [inline] packet_sendmsg+0x28d6/0x4eb0 net/packet/af_packet.c:3134 Beim Senden von Paketen mit 0 Bytes über den TPACKET-Ringpuffer auf Geräten ohne Hard Header (z. B. dev->hard_header_len == 0) befüllt tpacket_fill_skb() ein skb mit skb->len == 0 und gibt 0 zurück. tpacket_snd() leitet dieses leere skb dann an packet_xmit() weiter, wodurch __dev_queue_xmit() auf skb_assert_len(skb) trifft. Ähnliche Prüfungen existieren in packet_snd() über Commit dc633700f00f ("net/af_packet: check len when min_header_len equals to 0") und in packet_sendmsg_spkt() über Commit 6a341729fb31 ("af_packet: Don't send zero-byte data in packet_sendmsg_spkt()."). In tpacket_fill_skb() -EINVAL zurückgeben, wenn skb->len null ist, um Pakete mit einer Länge von null in tpacket_snd() abzulehnen.

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: 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.