Base de données CVE

Dans le noyau Linux, la vulnérabilité suivante a été corrigée : HID: ft260: correction d'une écriture stack-use-after-return lors d'une condition de concurrence dans la lecture I2C ft260_i2c_read() fait pointer dev->read_buf vers un tampon fourni par l'appelant (souvent une variable sur la pile), active une completion et attend jusqu'à cinq secondes que le périphérique renvoie les données. Le callback d'entrée HID ft260_raw_event() s'exécute dans le chemin d'entrée/IRQ, indépendamment du mutex dev->lock détenu par le chemin de lecture, et copie la charge utile fournie par le périphérique dans dev->read_buf après une simple vérification NULL. Ces deux chemins partagent read_buf, read_idx et read_len sans aucune sérialisation. Si le périphérique retarde sa réponse jusqu'à l'expiration du délai de lecture, ft260_i2c_read() réinitialise le contrôleur, efface read_buf et retourne, ce qui déroule la frame de pile où se trouvait le tampon. Une réponse qui arrive à ce moment permet à ft260_raw_event() de passer la vérification NULL, puis memcpy() écrit la charge utile contrôlée par le périphérique à l'emplacement désormais libéré sur la pile, déclenchant un write stack-use-after-return limité, mais influencé par un attaquant, provoqué par un matériel malveillant ou défaillant. Ajout d'un spinlock dédié qui sérialise chaque accès à read_buf, read_idx et read_len. ft260_raw_event() le détient désormais pendant la vérification NULL, le memcpy et la mise à jour de l'index, tandis que le chemin de lecture l'acquiert lors de l'activation et de l'effacement du tampon, de sorte que le teardown ne puisse plus s'intercaler entre la vérification et la copie.

Dans le noyau Linux, la vulnérabilité suivante a été résolue : HID: sensor: custom: Correction du use-after-free dans enable_sensor enable_sensor_store() peut appeler set_power_report_state(), qui déréférence sensor_inst->power_state et sensor_inst->report_state. Ces pointeurs font référence à des entrées dans sensor_inst->fields. Créer les attributs de champ avant d'exposer l'attribut sysfs enable_sensor, afin qu'enable_sensor ne soit pas accessible avant que l'état dont il dépend ait été initialisé. Lors de la suppression, supprimer enable_sensor avant de libérer les attributs de champ, afin qu'une écriture sysfs concurrente ne puisse pas déréférencer de la mémoire libérée via power_state ou report_state.

Dans le noyau Linux, la vulnérabilité suivante a été corrigée : HID: uclogic: corriger le use-after-free de inrange_timer lors de la suppression uclogic_remove() annule le timer d’entrée en zone du stylet, puis arrête le périphérique : timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); timer_delete_sync() garantit seulement que le timer est inactif à cet instant. uclogic_raw_event_pen() continue à transmettre les rapports du stylet jusqu’à ce que hid_hw_stop() arrête le transport plusieurs lignes plus loin, et chaque rapport avec pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE réarme le timer : mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); Un rapport arrivant entre l’appel à timer_delete_sync() et le démontage du transport dans hid_hw_stop() réarme inrange_timer après son annulation. uclogic_remove() retourne alors et le drvdata géré par devm est libéré, tandis que hid_hw_stop() a déjà libéré le drvdata du périphérique d’entrée vers lequel pen_input pointe ; ainsi, lorsque le timer se déclenche environ 100 ms plus tard, uclogic_inrange_timeout() déréférence une mémoire libérée — un use-after-free dans le contexte softirq du timer. Inverser les deux appels ne constitue pas une correction : arrêter le périphérique en premier libère drvdata->pen_input via hidinput_disconnect() alors que le timer peut encore être en attente, si bien qu’un timer déjà armé avant la suppression se déclenche sur le périphérique d’entrée libéré dans la fenêtre précédant l’exécution de timer_delete_sync(). Utiliser plutôt timer_shutdown_sync() avant hid_hw_stop(). Il annule le timer, attend un callback en cours d’exécution alors que pen_input est encore valide, et empêche tout réarmement ultérieur — un mod_timer() ultérieur provenant d’un rapport en cours est silencieusement ignoré — de sorte que le timer est assurément arrêté avant que hid_hw_stop() ne libère les entrées. C’est l’ordre documenté par le cœur des timers pour ce cas de démontage « timer réarmé depuis un autre chemin ».

Absence d’authentification pour une fonction critique, falsification de requête côté serveur (SSRF) et utilisation d’identifiants codés en dur dans ASUS Control Center permettent à un utilisateur non autorisé d’obtenir la clé de chiffrement via une requête HTTP, ce qui amène un service local à activer SSH sur le port 2222. L’attaquant peut ensuite se connecter avec les identifiants codés en dur pour obtenir un shell root, permettant la lecture, l’écriture et la suppression directes de données sur ASUS Control Center, ainsi que le contrôle à distance de tous les serveurs, PC et postes de travail de l’entreprise. Pour plus d’informations, consultez la section « Security Update for ASUS Control Center » de l’avis de sécurité ASUS.

Vérification incorrecte de la signature cryptographique dans Copilot Studio permet à un attaquant non autorisé d’élever ses privilèges via le réseau.

Absence d'authentification pour une fonction critique dans Azure AI Language permet à un attaquant non autorisé d'élever ses privilèges sur le réseau.

Contournement d'autorisation via une clé contrôlée par l'utilisateur dans Azure Cosmos DB permet à un attaquant autorisé de réaliser une usurpation sur un réseau.

Une vulnérabilité liée à une clé cryptographique codée en dur existe dans le module web de TP-Link Archer AX55 v4. Un attaquant sur le réseau local qui capture une session de connexion HTTP peut utiliser la clé privée RSA partagée connue pour déchiffrer le mot de passe administrateur ; la clé de session AES affaiblie réduit encore l'effort nécessaire pour compromettre la confidentialité de la session. Une exploitation réussie peut divulguer le mot de passe administrateur capturé lors d'une session de connexion HTTP et compromettre la confidentialité de la session.

Une vulnérabilité de débordement de tampon basé sur la pile existe dans le module EasyMesh de TP-Link Archer AX55 v4. Lorsque le mode Mesh est activé, un attaquant sur le réseau local peut soumettre une entrée spécialement conçue qui provoque le plantage du démon easymesh et pourrait potentiellement permettre l'exécution de code à distance sur l'appareil. Une exploitation réussie peut provoquer le plantage du démon EasyMesh et pourrait potentiellement permettre l'exécution de code à distance lorsque le mode Mesh est activé. Cela peut avoir un impact élevé sur la confidentialité, l'intégrité et la disponibilité de l'appareil affecté.

MapLibre GL JS est une bibliothèque de cartes interactives utilisant des tuiles vectorielles pour les navigateurs web. Avant la version 6.4.1, DOM.sanitize() dans src/util/dom.ts parcourt elem.attributes en tant que NamedNodeMap dynamique, tandis que removeAttributes() supprime des attributs de la même collection, décalant les index et ignorant un attribut dangereux adjacent. Un attaquant qui contrôle des chaînes d’attribution de style tierces non fiables ou des attributions personnalisées fournies par l’utilisateur peut fournir des attributs dangereux consécutifs, permettant à un attribut tel que onload ou ontoggle de survivre à la désinfection et de s’exécuter lorsque le contrôle d’attribution insère le contenu dans innerHTML. Une victime doit afficher le contenu cartographique affecté pour que le script s’exécute. Ce problème est corrigé dans la version 6.4.1.

Confusion de type dans V8 dans Google Chrome avant 152.0.7977.82 a permis à un attaquant distant d'exécuter du code arbitraire à l'intérieur du bac à sable via une page HTML spécialement conçue. (Gravité de sécurité Chromium : Haute)

GeoNetwork est une application catalogue pour gérer des ressources à référence spatiale. Avant les versions 4.4.12 et 4.2.17, l'endpoint API pour la création d'un nouveau formatter via file upload n'est pas protégé et permet l'upload de fichiers externes non contrôlés. Un attaquant non authentifié peut uploader des fichiers formatter `.xsl` ou `.zip` arbitraires sur le serveur. Un attaquant non authentifié peut écrire des fichiers arbitraires dans le répertoire formatter de GeoNetwork. En soi, cela constitue un accès en écriture non autorisé au stockage du serveur. Le problème est corrigé dans les versions 4.4.12 et 4.2.17 de GeoNetwork.

GeoNetwork est une application catalogue destinée à gérer les ressources à référence spatiale. Avant les versions 4.4.12 et 4.2.17, le processeur XSLT Saxon utilisé pour restituer les formatters est configuré sans traitement sécurisé (`FEATURE_SECURE_PROCESSING`) et sans désactivation des fonctions d'extension Java (`ALLOW_EXTERNAL_FUNCTIONS`). Toute feuille de style chargée par GeoNetwork peut donc invoquer directement `java.lang.Runtime.exec()` ou `java.lang.ProcessBuilder`, obtenant une exécution de commandes arbitraires en tant qu'utilisateur du processus GeoNetwork. Un utilisateur disposant de privilèges suffisants pour téléverser un formatter peut fournir un fichier `.xsl` contenant un appel d'extension Java qui exécute des commandes OS arbitraires avec les privilèges du processus GeoNetwork. Le problème est corrigé dans les versions 4.4.12 et 4.2.17 de GeoNetwork.

Hermes Agent 0.18.2 à 0.21.0, corrigé dans le commit f6234d0, contient une vulnérabilité d'exécution de code à distance qui permet à des attaquants d'exécuter des commandes OS arbitraires en fournissant un dépôt malveillant avec un .git/config forgé définissant core.fsmonitor sur une commande contrôlée par l'attaquant. Lorsqu'un utilisateur ouvre le dépôt malveillant et envoie un message quelconque, l'agent déclenche une actualisation de l'index git status qui exécute la commande injectée dans le contexte du processus de l'utilisateur, exposant l'environnement complet y compris les clés API des fournisseurs configurés.

Dans le noyau Linux, la vulnérabilité suivante a été résolue : selinux: rejeter un nombre de permissions de classe inférieur à son common hérité security_get_permissions() mappe les permissions d'un common hérité dans un tableau dimensionné par permissions.nprim propre à la classe, mais class_read() reprend ce nprim tel quel depuis l'image de politique et ne vérifie jamais qu'il couvre le common. Une classe qui hérite d'un common de N permissions tout en déclarant un nprim plus petit est acceptée, et au chargement les permissions du common sont écrites au-delà du tableau dimensionné pour la classe -- une écriture heap hors limites. Rejeter une classe dont le nombre de permissions est inférieur à celui de son common hérité. Les politiques bien formées, où le nombre de la classe inclut déjà les permissions héritées, ne sont pas affectées.

Dans le noyau Linux, la vulnérabilité suivante a été résolue : drm/amdkfd : Ajout d'une vérification des limites pour la longueur de sous-type CRAT L'analyseur CRAT vérifie que l'en-tête de sous-type tient dans l'image, mais ne vérifie pas que la longueur de sous-type annoncée tient. Une table CRAT malformée avec un champ de longueur surdimensionné provoque des lectures hors limites lorsque kfd_parse_subtype() convertit l'en-tête en structures de sous-type spécifiques. Ajouter une validation que sub_type_hdr + length ne dépasse pas la limite de l'image avant d'analyser le contenu du sous-type. (sélectionné depuis le commit 48e1d1e6e8798aef0312e68d8e586021b5b3cf4d)

Dans le noyau Linux, la vulnérabilité suivante a été corrigée : netfilter: nf_tables_offload: supprimer WARN_ON_ONCE pour ENOMEM dans le chemin d'abandon Dans nft_flow_rule_offload_abort(), WARN_ON_ONCE(err) est déclenché pour chaque erreur lors de la restauration, y compris -ENOMEM. Les échecs d'allocation de mémoire sont attendus lorsque la mémoire est insuffisante et n'indiquent pas un bogue du noyau. Trace par exemple : 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() // échoue avec -ENOMEM L'avertissement a été reproduit sur le noyau stable 5.10 sous pression mémoire via l'injection de fautes, mais le bogue sous-jacent existe également dans la branche principale, comme le montre la trace ENOMEM ci-dessus. Le message suivant a été déclenché lors du traitement d'une transaction nf_tables : 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 Modifier la condition en WARN_ON_ONCE(err && err != -ENOMEM) afin que les avertissements ne soient émis que pour les erreurs inattendues. Cela s'aligne sur la pratique courante du noyau consistant à ne pas générer d'avertissement pour -ENOMEM. Trouvé par le Linux Verification Center (linuxtesting.org) avec Syzkaller.

Dans le noyau Linux, la vulnérabilité suivante a été résolue : ASoC: xilinx: formatter_pcm: pass aud_drv_data to irq handlers Les gestionnaires irq prennent un pointeur struct device et appellent dev_get_drvdata() pour obtenir les données du pilote. Cependant, les données du pilote sont définies uniquement à la fin de probe, après devm_request_irq(), donc une interruption survenant entre-temps amène les gestionnaires à passer un pointeur NULL à readl() et à planter. Passer les données privées directement comme argument de devm_request_irq() au lieu du pointeur de périphérique, conformément à ce qu'attendent les gestionnaires.

Dans le noyau Linux, la vulnérabilité suivante a été résolue : af_packet: Ne pas envoyer de données de zéro octet dans tpacket_snd(). syzbot a signalé un WARNING dans __dev_queue_xmit() déclenché via 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 Lors de l'envoi de paquets de 0 octet via le tampon circulaire TPACKET sur des périphériques sans en-tête matériel (par ex. dev->hard_header_len == 0), tpacket_fill_skb() remplit un skb avec skb->len == 0 et renvoie 0. tpacket_snd() transmet ensuite ce skb vide à packet_xmit(), ce qui amène __dev_queue_xmit() à rencontrer skb_assert_len(skb). Des vérifications similaires existent dans packet_snd() via le commit dc633700f00f ("net/af_packet: check len when min_header_len equals to 0") et dans packet_sendmsg_spkt() via le commit 6a341729fb31 ("af_packet: Don't send zero-byte data in packet_sendmsg_spkt()."). Renvoyer -EINVAL dans tpacket_fill_skb() lorsque skb->len est nul afin de rejeter les paquets de longueur nulle dans tpacket_snd().

Dans le noyau Linux, la vulnérabilité suivante a été résolue : bpf : Vérifier sk_state avant sk_protocol dans bpf_tcp_*_syncookie bpf_tcp_gen_syncookie et bpf_tcp_check_syncookie acceptent un pointeur de socket 'sk' avec le type d'argument ARG_PTR_TO_BTF_ID_SOCK_COMMON. Cependant, ils accèdent à sk->sk_protocol sans valider si 'sk' représente une socket complète. Corrigez ce problème en vérifiant sk->sk_state != TCP_LISTEN avant d'inspecter sk->sk_protocol à la fois dans bpf_tcp_gen_syncookie et bpf_tcp_check_syncookie. Puisque les mini-sockets ne sont jamais dans l'état TCP_LISTEN, la condition court-circuite et empêche le déréférencement des champs spécifiques au fullsock.