CVE-Datenbank

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: magicmouse: verhindere unbeschränkte Rekursion in magicmouse_raw_event() magicmouse_raw_event() verarbeitet DOUBLE_REPORT_ID (0xf7)-Pakete, die zwei Touch-Reports in einen packen, indem das Paket aufgeteilt und für jede Hälfte die Funktion selbst aufgerufen wird. Die einzige Schutzmaßnahme gegen eine unkontrollierte Rekursion ist eine "size < 1"-Überprüfung, die Aufrufe der Größe Null stoppt, aber die Rekursionstiefe nicht begrenzt. Ein bösartiges HID-Gerät, das zu diesem Treiber passt, kann einen Report senden, der mit DOUBLE_REPORT_ID beginnt und mit der Sequenz [0xf7, 0x00] gefüllt ist. Jede Ebene verbraucht zwei Bytes und ruft mit dem Rest rekursiv auf, sodass ein eingehender Report von bis zu HID_MAX_BUFFER_SIZE (16 KiB) etwa 8000 verschachtelte Aufrufe verursacht. Dies erschöpft leicht den 16 KiB großen Kernel-Stack, was zu einem Stack Overflow führt: einem Panic mit CONFIG_VMAP_STACK oder Speicherkorruption ohne dieses. Ein Doppelbericht umhüllt immer nur zwei normale Reports; er ist nie legitim verschachtelt. Verweigere den erneuten Eintritt in den DOUBLE_REPORT_ID-Fall aus einem rekursiven Aufruf, sodass die Rekursionstiefe auf zwei begrenzt ist, während alle gültigen Pakete weiterhin genau wie zuvor geparst werden.

Im Linux-Kernel wurde die folgende Sicherheitslücke behoben: HID: pidff: OOB-Schreibzugriff, wenn hid->inputs leer ist hid_pidff_init_with_quirks() leitet sein input_dev aus list_entry(hid->inputs.next, struct hid_input, list) ab, ohne zuvor zu prüfen, ob hid->inputs nicht leer ist. Das Listenelement von struct hid_input befindet sich an Offset 0, daher liefert list_entry() bei einer leeren Liste &hid->inputs selbst, und der folgende Ladevorgang von hidinput->input liest ein unabhängiges Member von struct hid_device. dev ist dann ein typverfälschter Pointer, und die Force-Feedback-Initialisierung schreibt über ihn: Jedes set_bit(FF_*, dev->ffbit) speichert 8 Bytes bei dev + 192, hinter dem Ende des Objekts, auf das dev tatsächlich verweist, und input_ff_create() fügt weitere Schreibvorgänge eines Heap-Pointers und zweier Funktions-Pointer hinzu. Bis zu hid-universal-pidff war der einzige Aufrufer hid_pidff_init() aus usbhid, das unter HID_CLAIMED_INPUT ausgeführt wird und daher immer mindestens ein hid_input besitzt. universal_pidff_probe() startet das Gerät mit HID_CONNECT_DEFAULT & ~HID_CONNECT_FF und ruft anschließend hid_pidff_init_with_quirks() direkt auf, sobald der Deskriptor eine PID-Usage Page enthält, wodurch diese Prüfung umgangen wird. Ein Report-Deskriptor, dessen einzige Application Collection sich auf HID_UP_PID befindet, lässt hid->inputs leer, während hid_connect() über den hidraw-Claim weiterhin erfolgreich ist, sodass die Ausführung den nicht abgesicherten list_entry() erreicht. Der Schreibvorgang findet im USB-Probe-Pfad auf der Hotplug-Workqueue statt, sodass das Anschließen eines bösartigen Geräts ausreicht, um ihn auszulösen; weder Angreifer-Software noch ein angemeldeter Benutzer sind erforderlich. KASAN meldet einen 8-Byte-Out-of-Bounds-Schreibzugriff in hid_pidff_init_with_quirks(), der von universal_pidff_probe() aus erreicht wird. Vor dem Ableiten von dev auf eine leere Liste prüfen und -ENODEV zurückgeben, wie es die anderen HID-Force-Feedback-Treiber bereits tun. universal_pidff_probe() gibt den Fehler weiter und wickelt die Ausführung zurück ab. Entdeckt von XBOW, analysiert von Baul Lee <[email protected]>

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: nintendo: Out-of-Bounds-Read in joycon_ctlr_read_handler() behoben joycon_ctlr_read_handler() castet einen eingehenden HID-Eingabebericht auf struct joycon_input_report und parst ihn, wobei der Cast nur durch eine 12-Byte-Längenprüfung abgesichert ist: if (size >= 12) /* make sure it contains the input report */ joycon_parse_report(ctlr, (struct joycon_input_report *)data); struct joycon_input_report ist 49 Bytes groß: ein 13-Byte-Header gefolgt von einer Union, deren IMU-Arm 36 Bytes groß ist. Für einen IMU-Bericht durchläuft joycon_parse_report() -> joycon_parse_imu_report() diese Union (Struktur-Offsets 13..48), sodass ein Bericht von genau 12 Bytes mit data[0] == JC_INPUT_IMU_DATA die Prüfung besteht, aber bis zu 37 Bytes über seine deklarierte Länge hinaus gelesen wird. Die überlesenen Bytes werden in Beschleunigungs-/Gyroskopwerte dekodiert und über das Eingabegerät „(IMU)“ an den Userspace weitergegeben, wodurch treiberinterner Speicher offengelegt wird. data[0] und size werden vollständig von einem bösartigen oder gefälschten Joy-Con/Pro Controller kontrolliert. Empfangspuffer werden auf die maximale Berichtslänge dimensioniert, daher handelt es sich um ein Überlesen innerhalb der Zuweisung und nicht um ein Slab-OOB, aber die dekodierten Bytes erreichen weiterhin den Userspace. Der verwandte Subcmd-Pfad in joycon_ctlr_handle_event() begrenzt denselben Cast bereits korrekt: if (size < sizeof(struct joycon_input_report) || data[0] != JC_INPUT_SUBCMD_REPLY) break; Verwende hier dieselbe Begrenzung mit sizeof(struct joycon_input_report).

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: nintendo: Eingabegerät erst nach dem Setzen der Capabilities registrieren input_register_device() macht das Gerät sofort für den Userspace sichtbar. In joycon_input_create() wurde sie aufgerufen, bevor joycon_config_rumble() die FF_RUMBLE-Capability und das memless Force-Feedback-Device konfiguriert, sodass ein gleichzeitiges EVIOCSFF ein NULL dev->ff dereferenzieren könnte. Eine frühe Registrierung bedeutet außerdem, dass dem initialen udev-Event Tasten- und Achseninformationen fehlen, wodurch Input-Manager das Gerät ignorieren können. input_register_device() an das Ende von joycon_input_create() verschieben, nachdem alle Capabilities, das IMU-Eingabegerät und die Force-Feedback-Callbacks konfiguriert wurden.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: nintendo: Geräte-IO vor hid_hw_stop bei Probefehler stoppen nintendo_hid_probe() ruft hid_device_io_start() vor joycon_init() und joycon_leds_create() auf. Wenn eine der beiden fehlschlägt, springt der Fehlerpfad zu err_close, das hid_hw_close()/hid_hw_stop() aufruft, ohne zuerst hid_device_io_stop() aufzurufen. hid_hw_stop() stoppt die Geräte-IO nicht, sodass hid_input_report() weiterhin laufen und auf Treiberdaten zugreifen kann, die gerade abgebaut werden, was zu einem use-after-free führt. Füge ein err_io_stop-Label hinzu, das hid_device_io_stop() vor hid_hw_close() aufruft, und verweise die beiden Fehlerpfade nach io_start darauf.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: ft260: Behebung eines stack-use-after-return-Schreibzugriffs in I2C-Lese-Race ft260_i2c_read() lässt dev->read_buf auf einen vom Aufrufer übergebenen Puffer zeigen (oft eine Variable auf dem Stack), aktiviert eine Completion und wartet bis zu fünf Sekunden darauf, dass das Gerät die Daten zurückgibt. Der HID-Eingabe-Callback ft260_raw_event() läuft im Input-/IRQ-Pfad, unabhängig vom durch den Lesepfad gehaltenen dev->lock-Mutex, und kopiert die vom Gerät gelieferte Payload nach einer einfachen NULL-Prüfung nach dev->read_buf. Diese beiden Pfade teilen sich read_buf, read_idx und read_len ohne Serialisierung. Verzögert das Gerät seine Antwort, bis die Leseoperation in einen Timeout läuft, setzt ft260_i2c_read() den Controller zurück, löscht read_buf und kehrt zurück, wobei der Stack-Frame, in dem sich der Puffer befand, abgebaut wird. Eine Antwort, die in diesem Moment eintrifft, lässt ft260_raw_event() die NULL-Prüfung bestehen und dann mittels memcpy() die vom Gerät kontrollierte Payload in die nun freigegebene Stack-Stelle schreiben, ein begrenzter, aber vom Angreifer beeinflusster stack-use-after-return-Schreibzugriff, auslösbar durch bösartige oder fehlerhafte Hardware. Füge einen dedizierten Spinlock hinzu, der jeden Zugriff auf read_buf, read_idx und read_len serialisiert. ft260_raw_event() hält ihn nun über die NULL-Prüfung, das memcpy und die Indexaktualisierung hinweg, während der Lesepfad ihn beim Aktivieren und beim Löschen des Puffers nimmt, sodass die Bereinigung nicht mehr zwischen Prüfung und Kopie fallen kann.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: sensor: custom: Use-after-free in enable_sensor behoben enable_sensor_store() kann set_power_report_state() aufrufen, das sensor_inst->power_state und sensor_inst->report_state dereferenziert. Diese Zeiger verweisen auf Einträge in sensor_inst->fields. Die Feldattribute werden erstellt, bevor das enable_sensor-sysfs-Attribut bereitgestellt wird, sodass auf enable_sensor nicht zugegriffen werden kann, bevor der Zustand, von dem es abhängt, initialisiert wurde. Beim Entfernen wird enable_sensor gelöscht, bevor die Feldattribute freigegeben werden, sodass ein gleichzeitiges sysfs-Schreiben keinen freigegebenen Speicher über power_state oder report_state dereferenzieren kann.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: uclogic: Use-after-free von inrange_timer beim Entfernen beheben uclogic_remove() bricht den Pen-In-Range-Timer ab und stoppt dann das Gerät: timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); timer_delete_sync() garantiert nur, dass der Timer in diesem Moment inaktiv ist. uclogic_raw_event_pen() liefert weiterhin Pen-Reports, bis hid_hw_stop() den Transport einige Zeilen später stoppt, und jeder Report mit pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE startet den Timer neu: mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); Ein Report, der zwischen dem timer_delete_sync()-Aufruf und dem Transport-Teardown in hid_hw_stop() ankommt, startet den inrange_timer neu, nachdem er abgebrochen wurde. uclogic_remove() kehrt dann zurück und die devm drvdata wird freigegeben, während hid_hw_stop() das Eingabegerät, auf das drvdata->pen_input zeigt, bereits freigegeben hat. Wenn der Timer also ~100 ms später feuert, dereferenziert uclogic_inrange_timeout() freigegebenen Speicher -- ein Use-after-free im Timer-Softirq-Kontext. Das Vertauschen der beiden Aufrufe ist keine Lösung: Das vorherige Stoppen des Geräts gibt drvdata->pen_input über hidinput_disconnect() frei, während der Timer noch ausstehen könnte. Ein vor dem Entfernen bereits aktivierter Timer feuert also auf dem freigegebenen Eingabegerät in dem Zeitfenster, bevor timer_delete_sync() ausgeführt wird. Verwenden Sie stattdessen timer_shutdown_sync() vor hid_hw_stop(). Es bricht den Timer ab, wartet auf einen laufenden Callback, während pen_input noch gültig ist, und verhindert ein erneutes Aktivieren -- ein späteres mod_timer() aus einem in-flight Report wird stillschweigend ignoriert --, sodass der Timer nachweislich tot ist, bevor hid_hw_stop() die Eingaben freigibt. Dies ist die Reihenfolge, die der Timer-Core für diesen Teardown-Fall „Timer von einem anderen Pfad aus neu aktiviert“ dokumentiert.

Unsachgemäße Überprüfung der kryptografischen Signatur in Copilot Studio ermöglicht es einem nicht autorisierten Angreifer, Berechtigungen über ein Netzwerk zu erhöhen.

Fehlende Authentifizierung für kritische Funktion in Azure AI Language ermöglicht es einem nicht autorisierten Angreifer, über ein Netzwerk Berechtigungen zu erweitern.

Autorisierungsumgehung durch benutzergesteuerten Schlüssel in Azure Cosmos DB ermöglicht es einem autorisierten Angreifer, Spoofing über ein Netzwerk durchzuführen.

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