Base de données CVE

Dans le noyau Linux, la vulnérabilité suivante a été résolue : serial: amba-pl011: synchroniser l'arrêt du DMA dmaengine_terminate_all() n'attend pas un callback en cours d'exécution, donc le callback TX peut encore toucher le buffer TX après sa libération. Le timer de poll RX lit les buffers RX sans le verrou du port. Passer à dmaengine_terminate_sync() et supprimer le timer RX avant de libérer les buffers.

Dans le noyau Linux, la vulnérabilité suivante a été corrigée : net : suppression de WARN_ON_ONCE() dans sk_mc_loop() sk_mc_loop() peut être appelée pour des sockets qui ne sont ni AF_INET ni AF_INET6 (par exemple des sockets AF_PACKET lors de l'envoi de paquets via une socket raw/packet sur des périphériques virtuels tels que VRF ou ipvlan). Dans de tels cas, sk_family n'est pas AF_INET/AF_INET6 et sk_mc_loop() traverse l'instruction switch et déclenche WARN_ON_ONCE(1). Les sockets non INET ne prennent pas en charge les options IP_MULTICAST_LOOP ou IPV6_MULTICAST_LOOP, donc la loopback devrait valoir true par défaut sans générer d'avertissement.

Dans le noyau Linux, la vulnérabilité suivante a été résolue : ata: pata_sl82c105: correction du use-after-free de la révision du pont pci_get_slot() renvoie un périphérique PCI référencé. Le commit 44c10138fd4b ("PCI: Change all drivers to use pci_device->revision") a remplacé une lecture de l'espace de configuration par un accès direct au champ de révision mis en cache, mais a laissé cet accès après pci_dev_put(). Le pont peut donc être libéré avant que sa révision soit lue. Lire la révision avant d'abandonner la référence.

Dans le noyau Linux, la vulnérabilité suivante a été résolue : net : supprimer le zero-padding CAP_SYS_RAWIO dans dev_validate_header dev_validate_header() lit directement dev->hard_header_len lorsqu'elle effectue un zero-padding des en-têtes courts de couche liaison pour les détenteurs de CAP_SYS_RAWIO : if (capable(CAP_SYS_RAWIO)) { memset(ll_header + len, 0, dev->hard_header_len - len); return true; } Les chemins d'envoi de paquets appellent dev_validate_header() sur des skbs dont le headroom a été alloué à partir d'une lecture antérieure de hard_header_len. Si le périphérique est reconfiguré de sorte que dev->hard_header_len augmente avant la validation, le memset écrit au-delà du tampon réservé, ce qui constitue une écriture hors limites. Cette écriture hors limites est aujourd'hui masquée dans certains chemins SOCK_RAW, car la même augmentation concurrente peut d'abord faire en sorte que skb_push() dépasse le headroom réservé et déclenche skb_under_panic(). Supprimez la branche de zero-padding avant de rendre cohérentes ces lectures de hard_header_len, afin que les correctifs de snapshot ne transforment pas une panique bruyante en un écrasement silencieux. Ce chemin n'est atteint que pour les protocoles de couche 2 à longueur variable, où len < hard_header_len mais len >= min_header_len. Aucun protocole de couche 2 à longueur variable restant dans l'arbre n'implémente header_ops->validate, et le contournement CAP_SYS_RAWIO qui effectue un zero-padding et accepte des en-têtes courts n'a aucune valeur réelle au-delà de permettre le test d'entrées intentionnellement malformées. Supprimez la branche CAP_SYS_RAWIO. Les lectures restantes de dev->hard_header_len dans dev_validate_header() sont uniquement des comparaisons et n'ont aucun impact sur la sécurité mémoire.

Dans le Linux kernel, la vulnérabilité suivante a été résolue : ring-buffer: Fix crash passing ERR_PTR to kthread_stop() Dans la boucle de nettoyage out_free de test_ringbuffer(), le contrôle `!rb_threads[cpu]` ne détecte que les entrées NULL et manque les entrées qui contiennent un ERR_PTR. rb_threads[] est static, donc les slots non assignés sont NULL. Mais lorsque kthread_run_on_cpu() échoue pour un cpu, il stocke ERR_PTR(-ENOMEM) (ou -EINTR) dans rb_threads[cpu] avant que la boucle de création ne saute vers out_free. Cette entrée est non-NULL, donc l'ancien contrôle `!ptr` ne provoque pas de sortie, et le nettoyage poursuit avec l'appel à kthread_stop() sur le ERR_PTR. kthread_stop() déréférence ensuite le pointeur invalide, provoquant le crash du kernel pendant le self-test late_initcall. crash logs: 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

Dans le noyau Linux, la vulnérabilité suivante a été résolue : Revert "drm/amdgpu: fix aperture mapping leak" Le teardown de devres est de type LIFO. Le nœud devres de l'aperture a été enregistré après le nœud du périphérique DRM, de sorte que devres_release_all() désenregistre l'aperture avant que le callback de libération du périphérique DRM n'exécute amdgpu_device_fini_sw(). Les callbacks IP sw_fini (par exemple vcn_v4_0_sw_fini) écrivent dans fw_shared via un pointeur dérivé de aper_base_kaddr, ce qui provoque une erreur de page du noyau lors de l'échec de la sonde / du rollback : 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 Cela rétablit le commit d871e99879cb5fd1fa798b006b4888887e63a17a. (cherry picked from commit 336e0cd576817ac64a4b394ca2b3680029f3e37f)

Dans le noyau Linux, la vulnérabilité suivante a été corrigée : KVM: x86/mmu: émettre un WARN et effacer role.invalid lors de la création d'une page shadow enfant Effacer explicitement role.invalid lors de la dérivation du rôle d'une page shadow enfant à partir de son parent afin de se prémunir contre des bogues ailleurs dans KVM, car la violation de l'invariant de KVM selon lequel les pages invalides ne se trouvent PAS dans la liste des pages MMU actives entraîne une use-after-free en raison de l'utilisation de list_add() au lieu de list_move() par __kvm_mmu_prepare_zap_page() lors du traitement d'une page shadow invalide, c'est-à-dire qu'elle aggrave fortement une situation déjà mauvaise. Signaler bruyamment si le parent est invalide, car cela signifie que KVM a manqué une vérification de validité, c'est-à-dire que KVM tente de mapper de la mémoire à l'aide d'une racine invalide/obsolète, mais continuer malgré tout puisque l'enfant reste par ailleurs une page shadow valide. ================================================================== 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

Auparavant, un canal enregistré dans le chanList du mux n'est pas utilisable tant qu'il n'est pas établi. Un pair malveillant pouvait inonder les incomingRequests du canal, provoquant un interblocage de l'ensemble de la connexion. Désormais, nous ajoutons un état établi atomique, défini lorsqu'un canal devient utilisable. Jusqu'à ce moment, handlePacket abandonne chaque paquet autre que la confirmation/l'échec d'ouverture, sans blocage et sans interrompre la connexion.

Nuclio est un framework « Serverless » pour les événements en temps réel et le traitement des données. Avant la version 1.17.4, le correctif contre l'injection de commandes OS non authentifiée dans le dashboard nuclio sur la plateforme locale/Docker est incomplet. Le correctif a ajouté validateFunctionName pour les noms de fonction et common.Quote() pour le chemin de commande shell des ressources nommées, mais le chemin de list-all des ressources (déclenché lorsqu'aucun nom de ressource spécifique n'est fourni) interpole toujours le paramètre resourceNamespace sans guillemets dans une chaîne de commande /bin/sh -c. Un attaquant non authentifié peut injecter des métacaractères shell via les en-têtes HTTP X-Nuclio-Function-Namespace, X-Nuclio-Project-Namespace ou X-Nuclio-Function-Event-Namespace afin d'obtenir l'exécution de commandes arbitraires à l'intérieur du conteneur du dashboard. Ce problème a été corrigé dans la version 1.17.4.

De multiples vulnérabilités dans la fonctionnalité de déchiffrement Secure/Multipurpose Internet Mail Extensions (S/MIME) de Cisco Secure Email pourraient permettre à un attaquant distant non authentifié de récupérer le texte en clair de messages électroniques chiffrés. Ces vulnérabilités sont dues à une validation insuffisante de l'intégrité des messages. Un attaquant pourrait exploiter ces vulnérabilités en utilisant une technique machine-in-the-middle pour intercepter et modifier le trafic entre les passerelles de messagerie. Une exploitation réussie pourrait permettre à l'attaquant d'obtenir le contenu en clair de la communication chiffrée.

Plusieurs vulnérabilités dans la fonctionnalité de déchiffrement Secure/Multipurpose Internet Mail Extensions (S/MIME) de Cisco Secure Email pourraient permettre à un attaquant distant non authentifié de récupérer le texte en clair de messages électroniques chiffrés. Ces vulnérabilités sont dues à une validation insuffisante de l'intégrité des messages. Un attaquant pourrait exploiter ces vulnérabilités en utilisant une technique machine-in-the-middle pour intercepter et modifier le trafic entre les passerelles de messagerie. Une exploitation réussie pourrait permettre à l'attaquant d'obtenir le contenu en texte clair de la communication chiffrée.

Une vulnérabilité dans Cisco Desk Phone 9800 Series, Cisco IP Phone 7800 and 8800 Series, and Cisco Video Phone 8875 exécutant Cisco Session Initiation Protocol (SIP) Software pourrait permettre à un attaquant distant non authentifié de provoquer une condition de déni de service (DoS) sur un appareil affecté. Cette vulnérabilité est due à une gestion incorrecte de la mémoire lorsqu'un appareil affecté traite des paquets HTTP. Un attaquant pourrait exploiter cette vulnérabilité en envoyant un flux continu de paquets HTTP spécialement conçus vers l'appareil. Une exploitation réussie pourrait permettre à l'attaquant d'amener l'appareil affecté à consommer de la mémoire en continu, entraînant une condition DoS. Un redémarrage manuel de l'appareil est nécessaire pour se rétablir de cette condition. Remarque : Pour que cette vulnérabilité soit exploitable, le téléphone doit être enregistré auprès de Cisco Unified Communications Manager (Unified CM) et avoir Web Access activé. Web Access est désactivé par défaut.

Dans le cadre de l'engagement continu de Cisco en faveur de la sécurité proactive et de la qualité des produits, l'équipe d'ingénierie Cisco IOS XR Software a mené un examen de sécurité interne complet. Cet examen a donné lieu à des versions de durcissement logiciel qui corrigent de multiples vulnérabilités découvertes en interne. Les vulnérabilités suivies par CVE-2026-20280 sont liées à des problèmes de vérification ou de gestion incorrecte de conditions exceptionnelles regroupés sous la Common Weakness Enumeration (CWE) CWE-703.

Dans le cadre de l'engagement continu de Cisco en faveur de la sécurité proactive et de la qualité des produits, l'équipe d'ingénierie Cisco IOS XR Software a mené un examen de sécurité interne approfondi. Cet examen a donné lieu à des versions de durcissement logiciel qui corrigent de multiples vulnérabilités découvertes en interne. Les vulnérabilités suivies par CVE-2026-20279 sont liées à des problèmes de contrôle d'accès incorrect regroupés sous la Common Weakness Enumeration (CWE) CWE-284.

Dans le cadre de l'engagement continu de Cisco en faveur de la sécurité proactive et de la qualité des produits, l'équipe d'ingénierie Cisco IOS XR Software a mené un examen de sécurité interne complet. Cet examen a donné lieu à des versions de durcissement logiciel qui corrigent de multiples vulnérabilités découvertes en interne. Les vulnérabilités suivies sous CVE-2026-20278 sont liées à des problèmes de neutralisation incorrecte regroupés sous la Common Weakness Enumeration (CWE) CWE-707.

Dans le cadre de l'engagement continu de Cisco en faveur de la sécurité proactive et de la qualité des produits, l'équipe d'ingénierie Cisco IOS XR Software a mené un examen de sécurité interne approfondi. Cet examen a donné lieu à des versions de durcissement logiciel qui corrigent de multiples vulnérabilités découvertes en interne. Les vulnérabilités suivies par CVE-2026-20277 sont liées à des problèmes de défaillance du mécanisme de protection regroupés sous la Common Weakness Enumeration (CWE) CWE-693.

Dans le cadre de l'engagement continu de Cisco en matière de sécurité proactive et de qualité des produits, l'équipe d'ingénierie Cisco IOS XR Software a mené un examen de sécurité interne complet. Cet examen a donné lieu à des versions de durcissement logiciel qui corrigent de multiples vulnérabilités découvertes en interne. Les vulnérabilités suivies par CVE-2026-20276 sont liées à des problèmes de gestion insuffisante du flux de contrôle regroupés sous la Common Weakness Enumeration (CWE) CWE-691.

Dans le cadre de l'engagement continu de Cisco en faveur de la sécurité proactive et de la qualité des produits, l'équipe d'ingénierie Cisco IOS XR Software a mené un examen de sécurité interne complet. Cet examen a donné lieu à des versions de durcissement logiciel qui corrigent de multiples vulnérabilités découvertes en interne. Les vulnérabilités suivies par CVE-2026-20275 sont liées à des problèmes de calcul incorrect regroupés sous la Common Weakness Enumeration (CWE) CWE-682.

Dans le cadre de l'engagement continu de Cisco en faveur de la sécurité proactive et de la qualité des produits, l'équipe d'ingénierie Cisco IOS XR Software a mené un examen de sécurité interne complet. Cet examen a donné lieu à des versions de durcissement logiciel qui corrigent de multiples vulnérabilités découvertes en interne. Les vulnérabilités suivies sous CVE-2026-20274 sont liées à des problèmes de contrôle inapproprié des ressources regroupés sous la Common Weakness Enumeration (CWE) CWE-664.

Une vulnérabilité dans l'intégration Silicon One des commutateurs Cisco Nexus 9000 Series pourrait permettre à un attaquant distant non authentifié d'exécuter du code avec des privilèges root. Cette vulnérabilité existe car les ports TCP 43210 et 43211 sont accessibles dans le VRF (Virtual Routing and Forwarding) de couche 3 (L3) par défaut. Une exploitation réussie pourrait permettre à l'attaquant de se connecter à un appareil affecté et d'envoyer une entrée spécialement conçue qui pourrait être exécutée en tant que code avec des privilèges root. L'exploitation de cette vulnérabilité pourrait également provoquer le plantage du processus S1HAL, ce qui pourrait entraîner le rechargement de l'appareil.