Database CVE

Nel kernel Linux, la seguente vulnerabilità è stata risolta: bpf: Controllare sk_state prima di sk_protocol in bpf_tcp_*_syncookie bpf_tcp_gen_syncookie e bpf_tcp_check_syncookie accettano un puntatore a socket 'sk' con tipo di argomento ARG_PTR_TO_BTF_ID_SOCK_COMMON. Tuttavia, accedono a sk->sk_protocol senza verificare se 'sk' rappresenta un full socket. Risolvere questo problema controllando sk->sk_state != TCP_LISTEN prima di esaminare sk->sk_protocol sia in bpf_tcp_gen_syncookie che in bpf_tcp_check_syncookie. Poiché i mini-socket non sono mai nello stato TCP_LISTEN, la condizione va in cortocircuito e impedisce la dereferenziazione dei campi specifici di fullsock.

Nel kernel Linux, la seguente vulnerabilità è stata risolta: serial: amba-pl011: sincronizzare il teardown del DMA dmaengine_terminate_all() non attende una callback in esecuzione, quindi la callback TX può ancora toccare il buffer TX dopo che è stato liberato. Il timer di poll RX legge i buffer RX senza il port lock. Passare a dmaengine_terminate_sync() ed eliminare il timer RX prima di liberare i buffer.

Nel kernel Linux, la seguente vulnerabilità è stata risolta: net: remove WARN_ON_ONCE() from sk_mc_loop() sk_mc_loop() può essere chiamata per socket che non sono né AF_INET né AF_INET6 (ad es. socket AF_PACKET durante l'invio di pacchetti tramite raw/packet socket su dispositivi virtuali come VRF o ipvlan). In tali casi, sk_family non è AF_INET/AF_INET6 e sk_mc_loop() supera l'istruzione switch e attiva WARN_ON_ONCE(1). I socket non-INET non supportano le opzioni IP_MULTICAST_LOOP o IPV6_MULTICAST_LOOP, quindi il loopback dovrebbe essere true per impostazione predefinita senza generare un warning.

Nel kernel Linux, è stata risolta la seguente vulnerabilità: ata: pata_sl82c105: correzione del problema di use-after-free nella revisione del bridge pci_get_slot() restituisce un dispositivo PCI referenziato. Il commit 44c10138fd4b ("PCI: Change all drivers to use pci_device->revision") ha sostituito una lettura dallo spazio di configurazione con l'accesso diretto al campo revisione memorizzato nella cache, ma ha lasciato tale accesso dopo pci_dev_put(). Il bridge può quindi essere liberato prima che venga letta la sua revisione. Leggere la revisione prima di rilasciare il riferimento.

Nel kernel Linux, è stata risolta la seguente vulnerabilità: net: rimozione del zero-padding CAP_SYS_RAWIO in dev_validate_header dev_validate_header() legge direttamente dev->hard_header_len quando esegue il zero-padding degli header di livello di collegamento corti per i possessori di CAP_SYS_RAWIO: if (capable(CAP_SYS_RAWIO)) { memset(ll_header + len, 0, dev->hard_header_len - len); return true; } I percorsi di invio dei pacchetti chiamano dev_validate_header() su skb il cui headroom è stato allocato da una precedente lettura di hard_header_len. Se il dispositivo viene riconfigurato in modo che dev->hard_header_len aumenti prima della validazione, la memset scrive oltre il buffer riservato, causando una scrittura out-of-bounds. Questa scrittura out-of-bounds è mascherata oggi in alcuni percorsi SOCK_RAW perché lo stesso aumento concorrente può prima far sì che skb_push() superi l'headroom riservato e attivi skb_under_panic(). Rimuovere il ramo di zero-padding prima di rendere coerenti quelle letture di hard_header_len, in modo che le correzioni snapshot non trasformino un panic rumoroso in una sovrascrittura silenziosa. Questo percorso viene raggiunto solo per protocolli L2 a lunghezza variabile, dove len < hard_header_len ma len >= min_header_len. Nessun protocollo L2 a lunghezza variabile rimasto nell'albero implementa header_ops->validate, e il bypass CAP_SYS_RAWIO che esegue il zero-padding e accetta header corti non ha alcun valore reale oltre a consentire il test di input intenzionalmente malformati. Eliminare il ramo CAP_SYS_RAWIO. Le restanti letture di dev->hard_header_len in dev_validate_header() sono solo confronti e non hanno impatto sulla sicurezza della memoria.

Nel kernel Linux è stata risolta la seguente vulnerabilità: ring-buffer: correzione del crash nel passaggio di ERR_PTR a kthread_stop() Nel ciclo di pulizia out_free di test_ringbuffer(), il controllo `!rb_threads[cpu]` intercetta solo le voci NULL e non quelle che contengono un ERR_PTR. rb_threads[] è statico, quindi gli slot non assegnati sono NULL. Ma quando kthread_run_on_cpu() fallisce per una cpu, memorizza ERR_PTR(-ENOMEM) (o -EINTR) in rb_threads[cpu] prima che il ciclo di creazione salti a out_free. Quella voce non è NULL, quindi il vecchio controllo `!ptr` non interrompe e la pulizia prosegue chiamando kthread_stop() sull'ERR_PTR. kthread_stop() quindi dereferenzia il puntatore non valido, mandando in crash il kernel durante il self-test di late_initcall. log del crash: 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

Nel kernel Linux, la seguente vulnerabilità è stata risolta: Revert "drm/amdgpu: fix aperture mapping leak" Il teardown di devres è LIFO. Il nodo devres dell'apertura è stato registrato dopo il nodo del dispositivo DRM, quindi devres_release_all() smappa l'apertura prima che il callback di rilascio del dispositivo DRM attivi amdgpu_device_fini_sw(). I callback sw_fini IP (es. vcn_v4_0_sw_fini) scrivono su fw_shared tramite un puntatore derivato da aper_base_kaddr, causando un kernel page fault in caso di fallimento del probe / 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 Questo esegue il revert del commit d871e99879cb5fd1fa798b006b4888887e63a17a. (prelevato tramite cherry pick dal commit 336e0cd576817ac64a4b394ca2b3680029f3e37f)

Nel kernel Linux, è stata risolta la seguente vulnerabilità: KVM: x86/mmu: emette un WARN e azzera role.invalid durante la creazione di una pagina shadow figlia Azzera esplicitamente role.invalid durante la derivazione del role di una pagina shadow figlia dal suo parent per proteggersi da bug presenti altrove in KVM, poiché violare l'invariante di KVM secondo cui le pagine non valide NON si trovano nell'elenco delle pagine MMU attive porta a un use-after-free dovuto al fatto che __kvm_mmu_prepare_zap_page() usa list_add() invece di list_move() durante l'elaborazione di una pagina shadow non valida, ovvero rende una situazione negativa molto peggiore. Segnala ad alta voce se il parent non è valido, poiché ciò significa che KVM ha mancato un controllo di validità, ovvero KVM sta tentando di mappare la memoria usando una root non valida/obsoleta, ma continua comunque poiché la child è altrimenti ancora una pagina shadow valida. ================================================================== 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

In precedenza, un canale registrato nella chanList del mux non è utilizzabile fino a quando non è established. Un peer malevolo era in grado di inondare gli incomingRequests del canale, causando il deadlock dell'intera connessione. Ora aggiungiamo uno stato established atomico, impostato quando un canale diventa utilizzabile. Fino a tale momento, handlePacket scarta ogni pacchetto diverso dalla conferma/fallimento di apertura, senza bloccarsi e senza interrompere la connessione.

Nuclio è un framework "Serverless" per eventi in tempo reale ed elaborazione dei dati. Prima della versione 1.17.4, la correzione per l'iniezione di comandi OS non autenticata nella dashboard di nuclio sulla piattaforma locale/Docker è incompleta. La correzione ha aggiunto validateFunctionName per i nomi delle funzioni e common.Quote() per il percorso del comando shell delle risorse denominate, ma il percorso per elencare tutte le risorse (attivato quando non viene fornito alcun nome di risorsa specifico) interpola ancora il parametro resourceNamespace senza virgolette in una stringa di comando /bin/sh -c. Un attaccante non autenticato può iniettare metacaratteri della shell tramite le intestazioni HTTP X-Nuclio-Function-Namespace, X-Nuclio-Project-Namespace o X-Nuclio-Function-Event-Namespace per ottenere l'esecuzione di comandi arbitrari all'interno del container della dashboard. Questo problema è stato corretto nella versione 1.17.4.

Molteplici vulnerabilità nella funzionalità di decrittazione Secure/Multipurpose Internet Mail Extensions (S/MIME) di Cisco Secure Email potrebbero consentire a un attaccante remoto non autenticato di recuperare testo in chiaro da messaggi email crittografati. Queste vulnerabilità sono dovute a una convalida insufficiente dell'integrità dei messaggi. Un attaccante potrebbe sfruttare queste vulnerabilità utilizzando una tecnica machine-in-the-middle per intercettare e modificare il traffico tra email gateway. Un exploit riuscito potrebbe consentire all'attaccante di ottenere contenuti in chiaro dalla comunicazione crittografata.

Vulnerabilità multiple nella funzionalità di decrittazione Secure/Multipurpose Internet Mail Extensions (S/MIME) di Cisco Secure Email potrebbero consentire a un attaccante remoto non autenticato di recuperare testo in chiaro da messaggi email crittografati. Queste vulnerabilità sono dovute a una convalida insufficiente dell'integrità dei messaggi. Un attaccante potrebbe sfruttare queste vulnerabilità utilizzando una tecnica machine-in-the-middle per intercettare e modificare il traffico tra i gateway email. Uno sfruttamento riuscito potrebbe consentire all'attaccante di ottenere il contenuto in chiaro dalla comunicazione crittografata.

Una vulnerabilità in Cisco Desk Phone 9800 Series, Cisco IP Phone 7800 and 8800 Series, e Cisco Video Phone 8875 che eseguono Cisco Session Initiation Protocol (SIP) Software potrebbe consentire a un attaccante remoto non autenticato di causare una condizione di denial of service (DoS) su un dispositivo interessato. Questa vulnerabilità è dovuta a una gestione impropria della memoria quando un dispositivo interessato elabora pacchetti HTTP. Un attaccante potrebbe sfruttare questa vulnerabilità inviando un flusso continuo di pacchetti HTTP creati ad arte al dispositivo. Uno sfruttamento riuscito potrebbe consentire all'attaccante di indurre il dispositivo interessato a consumare continuamente memoria, determinando una condizione DoS. Per ripristinare questa condizione è necessario un riavvio manuale del dispositivo. Nota: affinché questa vulnerabilità sia sfruttabile, il telefono deve essere registrato su Cisco Unified Communications Manager (Unified CM) e avere Web Access abilitato. Web Access è disabilitato per impostazione predefinita.

Come parte dell'impegno costante di Cisco per la sicurezza proattiva e la qualità dei prodotti, il team di ingegneria Cisco IOS XR Software ha condotto una revisione interna completa della sicurezza. Questa revisione ha portato a release di hardening del software che risolvono molteplici vulnerabilità scoperte internamente. Le vulnerabilità tracciate con CVE-2026-20280 sono relative a problemi di controllo o gestione impropria di condizioni eccezionali raggruppati sotto la Common Weakness Enumeration (CWE) CWE-703.

Come parte dell'impegno costante di Cisco per la sicurezza proattiva e la qualità del prodotto, il team di ingegneria di Cisco IOS XR Software ha condotto una revisione interna completa della sicurezza. Questa revisione ha portato a release di hardening del software che correggono molteplici vulnerabilità scoperte internamente. Le vulnerabilità tracciate come CVE-2026-20279 sono relative a problemi di controllo degli accessi improprio raggruppati sotto la Common Weakness Enumeration (CWE) CWE-284.

Come parte dell'impegno costante di Cisco per la sicurezza proattiva e la qualità dei prodotti, il team di ingegneria Cisco IOS XR Software ha condotto una revisione interna completa della sicurezza. Questa revisione ha prodotto release di hardening del software che risolvono molteplici vulnerabilità scoperte internamente. Le vulnerabilità tracciate da CVE-2026-20278 sono relative a problemi di neutralizzazione impropria raggruppati sotto la Common Weakness Enumeration (CWE) CWE-707.

Nell'ambito dell'impegno costante di Cisco per la sicurezza proattiva e la qualità dei prodotti, il team di ingegneria del Cisco IOS XR Software ha condotto una revisione interna completa della sicurezza. Questa revisione ha portato a release di hardening del software che risolvono molteplici vulnerabilità scoperte internamente. Le vulnerabilità tracciate come CVE-2026-20277 sono relative a problemi di protection mechanism failure raggruppati sotto la Common Weakness Enumeration (CWE) CWE-693.

Come parte dell'impegno continuo di Cisco per la sicurezza proattiva e la qualità del prodotto, il team di ingegneria Cisco IOS XR Software ha condotto una revisione interna completa della sicurezza. Questa revisione ha portato a release di hardening del software che risolvono molteplici vulnerabilità scoperte internamente. Le vulnerabilità tracciate da CVE-2026-20276 sono relative a problemi di insufficient control flow management raggruppati sotto la Common Weakness Enumeration (CWE) CWE-691.

Come parte dell'impegno continuo di Cisco per la sicurezza proattiva e la qualità dei prodotti, il team di ingegneria Cisco IOS XR Software ha condotto una revisione interna completa della sicurezza. Questa revisione ha portato a release di hardening del software che risolvono molteplici vulnerabilità scoperte internamente. Le vulnerabilità tracciate da CVE-2026-20275 sono relative a problemi di calcolo errato raggruppati sotto la Common Weakness Enumeration (CWE) CWE-682.

Come parte dell'impegno continuo di Cisco per la sicurezza proattiva e la qualità dei prodotti, il team di ingegneria Cisco IOS XR Software ha condotto una revisione completa della sicurezza interna. Questa revisione ha portato a release di hardening del software che risolvono molteplici vulnerabilità scoperte internamente. Le vulnerabilità tracciate da CVE-2026-20274 sono relative a problemi di controllo improprio delle risorse raggruppati sotto la Common Weakness Enumeration (CWE) CWE-664.