Database CVE

Verifica impropria della firma crittografica in Copilot Studio consente a un utente malintenzionato non autorizzato di elevare i privilegi in rete.

Autenticazione mancante per funzione critica in Azure AI Language consente a un utente malintenzionato non autorizzato di elevare i privilegi tramite rete.

Bypass dell'autorizzazione tramite chiave controllata dall'utente in Azure Cosmos DB consente a un attaccante autorizzato di eseguire spoofing in rete.

Type confusion in V8 in Google Chrome prima della versione 152.0.7977.82 ha permesso a un aggressore remoto di eseguire codice arbitrario all'interno della sandbox tramite una pagina HTML appositamente creata. (Gravità di sicurezza di Chromium: Alta)

GeoNetwork è un'applicazione di catalogo per gestire risorse georeferenziate. Prima delle versioni 4.4.12 e 4.2.17, l'API endpoint per la creazione di un nuovo formatter tramite file upload non è protetto e consente l'upload di file esterni non controllati. Un attaccante non autenticato può caricare file formatter `.xsl` o `.zip` arbitrari sul server. Un attaccante non autenticato può scrivere file arbitrari nella directory formatter di GeoNetwork. Di per sé ciò costituisce un accesso in scrittura non autorizzato allo storage del server. Il problema è stato corretto nelle versioni 4.4.12 e 4.2.17 di GeoNetwork.

GeoNetwork è un'applicazione di catalogo per gestire risorse spazialmente referenziate. Prima delle versioni 4.4.12 e 4.2.17, il processore XSLT Saxon utilizzato per eseguire il rendering dei formatter è configurato senza elaborazione sicura (`FEATURE_SECURE_PROCESSING`) e senza disabilitare le funzioni di estensione Java (`ALLOW_EXTERNAL_FUNCTIONS`). Qualsiasi stylesheet caricato da GeoNetwork può quindi invocare direttamente `java.lang.Runtime.exec()` o `java.lang.ProcessBuilder`, ottenendo l'esecuzione di comandi arbitrari come utente del processo GeoNetwork. Un utente con privilegi sufficienti per caricare un formatter può fornire un file `.xsl` contenente una chiamata di estensione Java che esegue comandi OS arbitrari con i privilegi del processo GeoNetwork. Il problema è stato corretto nelle versioni 4.4.12 e 4.2.17 di GeoNetwork.

Hermes Agent da 0.18.2 a 0.21.0, corretto nel commit f6234d0, contiene una vulnerabilità di remote code execution che consente agli attaccanti di eseguire comandi OS arbitrari fornendo un repository malevolo con un .git/config craftato che imposta core.fsmonitor su un comando controllato dall'attaccante. Quando un utente apre il repository malevolo e invia un qualsiasi messaggio, l'agent attiva un refresh dell'indice di git status che esegue il comando iniettato nel contesto del processo dell'utente, esponendo l'intero environment incluse le provider API key configurate.

Nel Linux kernel, la seguente vulnerabilità è stata risolta: selinux: rifiuta un conteggio di permessi di classe inferiore al common ereditato security_get_permissions() mappa i permessi di un common ereditato in un array dimensionato secondo permissions.nprim proprio della classe, ma class_read() prende quel nprim alla lettera dall'immagine della policy e non verifica mai che copra il common. Una classe che eredita un common di N permessi dichiarando al contempo un nprim più piccolo viene accettata, e al caricamento i permessi del common vengono scritti oltre l'array dimensionato per la classe -- un out-of-bounds heap write. Rifiuta una classe il cui conteggio di permessi è inferiore a quello del common ereditato. Le policy ben formate, in cui il conteggio della classe include già i permessi ereditati, non sono interessate.

Nel kernel Linux, la seguente vulnerabilità è stata risolta: drm/amdkfd: Aggiungi controllo dei limiti per la lunghezza del sottotipo CRAT Il parser CRAT convalida che l'header del sottotipo rientri nell'immagine, ma non verifica che la lunghezza dichiarata del sottotipo rientri. Una tabella CRAT malformata con un campo di lunghezza sovradimensionato causa letture out-of-bounds quando kfd_parse_subtype() esegue il cast dell'header a strutture di sottotipi specifiche. Aggiungi la convalida che sub_type_hdr + length non superi il limite dell'immagine prima di analizzare il contenuto del sottotipo. (cherry picked dal commit 48e1d1e6e8798aef0312e68d8e586021b5b3cf4d)

Nel kernel Linux, è stata risolta la seguente vulnerabilità: netfilter: nf_tables_offload: soppressione di WARN_ON_ONCE per ENOMEM nel percorso di abort In nft_flow_rule_offload_abort(), WARN_ON_ONCE(err) viene attivato a ogni errore durante il rollback, incluso -ENOMEM. I fallimenti di allocazione della memoria sono previsti in condizioni di memoria insufficiente e non indicano un bug del kernel. Traccia di esempio: 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() // fallisce con -ENOMEM L'avviso è stato riprodotto sul kernel stabile 5.10 sotto pressione di memoria tramite fault injection, ma il bug sottostante esiste anche nel ramo principale, come dimostrato dalla traccia ENOMEM sopra riportata. Il seguente splat è stato attivato durante l'elaborazione della transazione 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 Modificare la condizione in WARN_ON_ONCE(err && err != -ENOMEM), in modo che gli avvisi vengano emessi solo per errori imprevisti. Ciò è in linea con la prassi comune del kernel di non generare avvisi per -ENOMEM. Individuato dal Linux Verification Center (linuxtesting.org) con Syzkaller.

Nel kernel Linux, la seguente vulnerabilità è stata risolta: ASoC: xilinx: formatter_pcm: passa aud_drv_data agli irq handler Gli irq handler prendono un puntatore struct device e chiamano dev_get_drvdata() per ottenere i dati del driver. Tuttavia, i dati del driver sono impostati solo alla fine del probe, dopo devm_request_irq(), quindi un interrupt ricevuto nel frattempo fa sì che gli handler passino un puntatore NULL a readl() e si verifichi un crash. Passa i dati privati direttamente come argomento di devm_request_irq() invece del puntatore al device, come previsto dagli handler.

Nel Linux kernel, la seguente vulnerabilità è stata risolta: af_packet: Non inviare dati zero-byte in tpacket_snd(). syzbot ha segnalato un WARNING in __dev_queue_xmit() attivato tramite 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 Quando si inviano pacchetti da 0 byte tramite TPACKET ring buffer su dispositivi senza hard header (e.g. dev->hard_header_len == 0), tpacket_fill_skb() popola un skb con skb->len == 0 e restituisce 0. tpacket_snd() quindi inoltra questo skb vuoto a packet_xmit(), causando in __dev_queue_xmit() l'attivazione di skb_assert_len(skb). Controlli simili esistono in packet_snd() tramite il commit dc633700f00f ("net/af_packet: check len when min_header_len equals to 0") e in packet_sendmsg_spkt() tramite il commit 6a341729fb31 ("af_packet: Don't send zero-byte data in packet_sendmsg_spkt()."). Restituire -EINVAL in tpacket_fill_skb() quando skb->len è zero per rifiutare pacchetti di lunghezza zero in tpacket_snd().

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