Deepin 25.2 migliora Wayland, ricerca intelligente dei file, supporto multi-monitor, sicurezza e prestazioni con numerose correzioni e aggiornamenti.
L'articolo Deepin 25.2 migliora Wayland, ricerca dei file e supporto multi-monitor proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy...

🔗 Leggi il post completo

Notepadng è un editor di testo per Linux ispirato a Notepad++, con Scintilla, temi originali e pacchetti per Ubuntu, Flatpak e Snap
L'articolo Notepadng il fork di Notepadqq che porta l’esperienza di Notepad++ su Linux proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy viene ...

🔗 Leggi il post completo

Nettle è un'applicazione per sfondi animati su GNOME con supporto multi-monitor, drag-and-drop e integrazione con le patch della shell
L'articolo Nettle: Sfondi Animati per GNOME con Interfaccia Intuitiva proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy viene rilasciato con Licen...

🔗 Leggi il post completo

A ridosso della pausa estiva, i sostenitori del controllo delle chat al Parlamento Europeo tentano un colpo di mano procedurale per riattivare la scansione a tappeto e senza sospetto dei messaggi privati.
L'articolo Il Parlamento Europeo vota a favore di Chat Control con procedura d’urgenza proviene da Marco's Box.

🔗 Leggi il post completo

Il team di Linux Mint ha pubblicato il consueto aggiornamento mensile dedicato allo stato dello sviluppo della distribuzione, anticipando le principali novità che debutteranno con la prossima versione prevista per il periodo natalizio del 2026.
L'articolo Linux Mint: Wayland è ormai pronto, grandi miglioramenti in arrivo entro fine anno proviene da Marco's Box.

🔗 Leggi il post completo

Typesetter è un editor Rust/GTK per Typst con anteprima live, click-to-jump, supporto font variabili e gestione pacchetti integrata
L'articolo Typesetter: Editor Minimalista per Documenti con Typst proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy viene rilasciato con Licenza CC B...

🔗 Leggi il post completo

Una race condition di sei istruzioni che porta a root

Il 4 luglio 2026 è stata resa pubblica una nuova vulnerabilità di privilege escalation nel kernel Linux, battezzata Bad Epoll e catalogata come CVE-2026-46242. Il difetto permette a un utente locale non privilegiato di ottenere i permessi di root su qualsiasi sistema Linux con kernel 6.4 o successivo, incluse le distribuzioni server più diffuse e i dispositivi Android, dove epoll è un componente del kernel che non può essere disattivato senza rompere il funzionamento del sistema operativo e del browser.

Per chi gestisce infrastrutture Linux in produzione, questo è il tipo di bug che merita attenzione immediata: non richiede alcuna interazione dell’utente privilegiato, non richiede configurazioni particolari, e la finestra di race condition — appena sei istruzioni macchina — non è un ostacolo, perché l’exploit pubblicato la sfrutta con un’affidabilità di circa il 99%.

Cos’è epoll e dove si trova il bug

epoll è il meccanismo con cui il kernel Linux notifica in modo efficiente ai processi eventi di I/O su un gran numero di file descriptor, ed è alla base di praticamente ogni event loop moderno: da Nginx a Node.js, da systemd a Chrome. Proprio perché è così centrale, non è un modulo che si possa scaricare o disabilitare come contromisura temporanea.

Il ricercatore Jaeyoung Chung, dottorando al CompSec Lab della Seoul National University, ha individuato un use-after-free (UAF) nella funzione ep_remove(), quella che ripulisce un file descriptor epoll quando viene chiuso. In condizioni normali, ep_remove() azzera file->f_ep sotto file->f_lock, ma continua a utilizzare l’oggetto file all’interno della sezione critica durante le chiamate a hlist_del_rcu() e spin_unlock(). Se in quella finestra ristrettissima una chiamata concorrente a __fput() osserva un valore transitorio NULL, salta eventpoll_release_file() e procede direttamente a f_op->release, liberando una struttura eventpoll ancora in uso.

Il risultato è memoria del kernel corrotta. Poiché struct file è allocata con SLAB_TYPESAFE_BY_RCU, lo slot liberato può essere immediatamente riciclato da alloc_empty_file(), aprendo la strada a un cross-cache attack: l’attaccante fa in modo che il kernel richiami kmem_cache_free() sulla cache sbagliata, ottenendo il controllo su un oggetto di tipo diverso da quello originariamente allocato in quello slot.

La catena dell’exploit

L’exploit pubblicato da Chung costruisce quattro file descriptor epoll collegati tra loro, organizzati in due coppie: chiudendo una coppia si innesca ripetutamente la race condition, mentre l’altra coppia funge da “vittima”. In questo modo una scrittura UAF di soli 8 byte viene trasformata in un use-after-free completo su un oggetto file tramite cross-cache attack. Da lì, l’attaccante ottiene lettura arbitraria della memoria del kernel attraverso /proc/self/fdinfo e dirotta il flusso di esecuzione con una catena ROP (return-oriented programming) fino a ottenere una shell root.

# Schema semplificato della sequenza (pseudocodice concettuale)
fd1, fd2 = crea_coppia_epoll()   # coppia "trigger"
fd3, fd4 = crea_coppia_epoll()   # coppia "vittima"

thread_A: chiudi(fd1)   # innesca ep_remove() ripetutamente
thread_B: chiudi(fd3)   # __fput() concorrente osserva f_ep == NULL
# -> eventpoll_release_file() saltato
# -> free prematuro dell'oggetto eventpoll ancora referenziato
# -> alloc_empty_file() ricicla lo slot -> cross-cache attack

Perché nemmeno un modello AI lo ha trovato

La storia di questo bug ha un risvolto interessante per chi segue l’evoluzione degli strumenti di analisi automatica del codice. Entrambe le vulnerabilità nascono da un singolo commit del 2023 nello stesso percorso di codice di epoll, lungo circa 2.500 righe. La prima, oggi tracciata come CVE-2026-43074, era stata individuata dal modello AI di Anthropic, Mythos, e già corretta all’inizio del 2026. Bad Epoll è la seconda falla, gemella della prima ma molto più difficile da individuare, che Mythos non aveva notato.

Chung stesso indica due possibili ragioni: la finestra temporale è talmente stretta da rendere difficile “visualizzare” la sequenza esatta degli eventi anche leggendo il codice con attenzione, e l’errore di memoria raramente attiva KASAN, il principale rilevatore di bug del kernel, lasciando pochissime tracce a runtime. È un promemoria utile: gli strumenti di code review basati su AI stanno diventando sempre più capaci di individuare race condition nel kernel, ma i bug di concorrenza restano difficili da scovare a ogni livello, per una macchina come per una persona.

Patch e mitigazioni per i sistemisti

Non esiste un workaround praticabile, perché disabilitare epoll non è un’opzione realistica su un sistema Linux moderno. La correzione definitiva è arrivata con il commit upstream a6dc643c6931, dopo che un primo tentativo di patch non aveva risolto completamente il problema — la correzione corretta è arrivata a circa due mesi dalla divulgazione iniziale.

Le azioni concrete da intraprendere:

• Verificare la versione del kernel in uso: sono interessati i kernel basati su 6.4 e successivi; i kernel 6.1 più datati (compresi alcuni dispositivi Android come il Pixel 8) non sono vulnerabili perché il bug è stato introdotto solo con la 6.4.
• Applicare l’aggiornamento del kernel non appena la propria distribuzione rilascia il backport della patch (Debian, Ubuntu, RHEL e derivate stanno seguendo il processo standard di backport della sicurezza).
• Su flotte Android/embedded, verificare i cicli di aggiornamento del vendor per il patch level di sicurezza corrispondente.
• Non fare affidamento su mitigazioni lato SELinux/AppArmor come sostituto della patch: riducono la superficie d’attacco ma non chiudono la race condition nel kernel.

Vale la pena ricordare che Bad Epoll si inserisce in una serie di bug di privilege escalation del kernel Linux usati storicamente anche per il root di Android, come Bad Binder, Bad IO_uring e Bad Spin. A differenza di altri bug recenti più deterministici (come Copy Fail o Dirty Frag), Bad Epoll appartiene alla categoria più “classica” delle race condition da vincere, nello stile di Dirty Cow del 2016: meno affidabile in teoria, ma qui resa quasi deterministica da un exploit ben costruito.

Conclusione

Per chi amministra server Linux, workstation di sviluppo o flotte Android aziendali, Bad Epoll è un chiaro caso da trattare con priorità alta: patch del kernel disponibile, nessuna mitigazione alternativa valida, e un exploit pubblico con affidabilità prossima al 100%. La lezione più ampia è che, nonostante i progressi degli strumenti di analisi automatica basati su AI nel trovare bug di concorrenza nel kernel, la revisione umana e soprattutto la prontezza nell’applicare le patch di sicurezza restano parte essenziale della gestione del rischio su qualunque infrastruttura Linux.

Fonte: 4sysops.com, con approfondimenti da The Hacker News e Cyber Security News.

Manifest V2 è ufficialmente morto: cosa cambia da Chrome 150

Con il rilascio di Chrome 150 (fine giugno 2026), Google ha chiuso anche l’ultimo varco rimasto aperto sul Manifest V2: il flag sperimentale che permetteva, a chi lo attivava manualmente, di continuare a eseguire estensioni legacy. Il percorso di deprecazione era iniziato molto prima — le prime disattivazioni erano comparse già nei canali pre-stable di Chrome 127 a metà 2024, la rimozione del criterio enterprise che consentiva alle aziende di rimandare il cambio era arrivata con Chrome 139, e da Chrome 138 il Manifest V2 risultava già disabilitato su tutti i canali per gli utenti privati. Chrome 150 chiude il cerchio: da qui in avanti, chi mantiene un’estensione in Manifest V2 non ha più alcuna via di fuga lato utente, solo il downgrade manuale a una versione precedente del browser, un’operazione sconsigliata perché rinuncia a tutte le patch di sicurezza successive.

Per chi sviluppa o mantiene estensioni Chrome — plugin aziendali, ad blocker interni, tool di produttività distribuiti via policy — il messaggio è netto: la riscrittura in Manifest V3 non è più rimandabile. Vediamo cosa cambia concretamente e come affrontare la migrazione senza sorprese.

Perché Google ha fatto questa scelta

Manifest V3 nasce da un problema reale: il modello di background page persistente di V2 teneva in memoria un intero processo per ogni estensione installata, con un impatto misurabile su RAM e batteria. Inoltre l’API webRequest, che permetteva alle estensioni di intercettare e modificare ogni richiesta di rete in tempo reale con codice arbitrario, è da anni uno dei vettori più sfruttati per iniettare codice malevolo o dirottare il traffico dell’utente. Sostituendola con un sistema dichiarativo, Chrome elimina una classe intera di vulnerabilità, al costo di una minore flessibilità per gli sviluppatori legittimi (è il motivo per cui alcuni ad blocker complessi, come le versioni più sofisticate di uBlock Origin, hanno dovuto ripensare parte della loro logica di filtro).

Le tre modifiche strutturali che servono per migrare

1. Da background page a service worker

In Manifest V2 il background script veniva dichiarato così:

{
  "manifest_version": 2,
  "background": {
    "scripts": ["background.js"],
    "persistent": true
  }
}

{
  "manifest_version": 3,
  "background": {
    "service_worker": "background.js"
  }
}

• registrare tutti i listener di eventi (chrome.runtime.onMessage, chrome.alarms.onAlarm, ecc.) in modo sincrono, nella prima esecuzione dello script — se li registri dentro una callback asincrona rischi che il service worker si riattivi senza agganciare l’evento;
• spostare qualunque stato che deve sopravvivere ai riavvii su chrome.storage.local o chrome.storage.session, mai su variabili globali;
• sostituire i timer lunghi basati su setTimeout/setInterval con l’API chrome.alarms, l’unica garantita a sopravvivere alla terminazione del worker.

2. Da webRequest a declarativeNetRequest

Questo è il cambiamento che rompe più estensioni esistenti. In V2 potevi intercettare ogni richiesta e decidere via codice cosa farne:

chrome.webRequest.onBeforeRequest.addListener(
  (details) => ({ cancel: details.url.includes("ads") }),
  { urls: ["<all_urls>"] },
  ["blocking"]
);

{
  "permissions": ["declarativeNetRequest"],
  "declarative_net_request": {
    "rule_resources": [{
      "id": "ruleset_1",
      "enabled": true,
      "path": "rules.json"
    }]
  }
}

[
  {
    "id": 1,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {
      "urlFilter": "||ads.example.com",
      "resourceTypes": ["script", "image", "xmlhttprequest"]
    }
  }
]

chrome.declarativeNetRequest.updateDynamicRules({
  addRules: [ /* nuove regole */ ],
  removeRuleIds: [1, 2, 3]
});

3. Content Security Policy più rigida

Manifest V3 vieta il caricamento di codice remoto e l’uso di eval() o di stringhe passate a setTimeout. Ogni script deve essere incluso nel pacchetto dell’estensione al momento della submission. Se la tua estensione scarica script da un CDN esterno per aggiornare la logica senza ripassare dallo store, quella pratica va eliminata: è esattamente il tipo di comportamento che V3 vuole rendere impossibile.

Un percorso di migrazione pragmatico

Per un’estensione di media complessità, un ordine di lavoro che funziona bene nella pratica:

1. Aggiorna manifest_version a 3 e correggi gli errori di validazione più ovvi (campi rinominati, permessi da dichiarare esplicitamente in host_permissions invece che in permissions).
2. Converti il background script in service worker e verifica con i DevTools dell’estensione (chrome://extensions → “Ispeziona service worker”) che i tuoi eventi vengano ricevuti anche dopo un riavvio forzato del worker.
3. Mappa ogni regola di webRequest blocking in una regola dichiarativa equivalente; per i casi che non si lasciano esprimere in modo dichiarativo (analisi del body della richiesta, per esempio) valuta se il caso d’uso può spostarsi lato server o va accettato come limite architetturale.
4. Testa il ciclo di vita del service worker esplicitamente, non solo la logica funzionale: è la causa più comune di bug “intermittenti” post-migrazione.

Cosa fare se dipendi da un’estensione ancora in V2

Se in azienda usate ancora plugin legacy indispensabili, l’unica strada supportata da Google è il downgrade manuale a Chrome 148 (l’ultima build con supporto V2 completo), disabilitando i servizi “Google Updater” e “Google Updater Internal” da Windows per bloccare l’aggiornamento automatico, e aggiungendo flag da riga di comando al collegamento per bypassare la logica di deprecazione. È un compromesso rischioso, perché rinuncia a tutte le patch di sicurezza rilasciate da quel momento in poi, e va considerato solo come misura temporanea mentre si pianifica la migrazione o la sostituzione dell’estensione. Alcuni browser basati su Chromium, come Firefox (che usa un motore diverso ma supporta ancora API equivalenti a webRequest) o Opera, hanno dichiarato l’intenzione di mantenere più a lungo il supporto a funzionalità simili a V2: per estensioni interne aziendali può essere un’alternativa da valutare, con le dovute cautele su compatibilità e manutenzione nel lungo periodo.

Fonte: 4sysops.com

Si parla di:
Toggle

Per anni Scattered Spider ha costruito la propria reputazione criminale sulla capacità di restare invisibile, nascondendosi dietro VPN, servizi di anonimizzazione e infrastrutture usa e getta. Ora, atti giudiziari appena desecretati mostrano come gli investigatori statunitensi abbiano comunque ricostruito l’identità di un presunto membro del gruppo grazie a un ingrediente inatteso: un identificativo univoco che Windows assegna a ogni installazione e che Microsoft ha fornito all’FBI dietro ordine del tribunale.

Chi è Peter Stokes e cosa gli viene contestato

Al centro del caso c’è Peter Stokes, 19 anni, cittadino con doppio passaporto statunitense ed estone, arrestato in aprile in Finlandia mentre tentava di imbarcarsi su un volo diretto in Giappone, con la collaborazione della National Bureau of Investigation finlandese. È stato successivamente estradato negli Stati Uniti e ha affrontato la sua prima udienza davanti a un tribunale federale di Chicago il 30 giugno 2026. I procuratori lo accusano di aver fatto parte di Scattered Spider, il collettivo cybercriminale noto anche con gli alias Octo Tempest, UNC3944 e 0ktapus, e di aver partecipato a molteplici intrusioni informatiche, furti di dati e schemi di estorsione.

Secondo l’accusa, le autorità federali attribuiscono al gruppo oltre 100 intrusioni di rete e più di 100 milioni di dollari in pagamenti di riscatto dal 2022 a oggi, con un modus operandi che combina ingegneria sociale, furto di credenziali, SIM swapping e compromissione di ambienti cloud enterprise.

GDID: il “device fingerprint” che nessuno può disattivare

Il dettaglio tecnico più rilevante della vicenda riguarda il Global Device Identifier (GDID), un identificativo univoco assegnato da Microsoft a ogni installazione di Windows per finalità di telemetria a livello di dispositivo e per l’erogazione di alcuni servizi di piattaforma. Secondo l’affidavit dell’FBI reso pubblico, un account ngrok utilizzato durante una delle intrusioni contestate era stato creato attraverso una VPN — ma Microsoft, dopo aver ricevuto un ordine del tribunale, è stata in grado di associare quell’attività a uno specifico GDID.

Da lì, gli investigatori hanno incrociato il GDID con la telemetria storica di Microsoft, individuando ulteriori indirizzi IP riconducibili alla stessa installazione Windows in periodi diversi. Questi indirizzi sono stati poi correlati con i log di accesso ottenuti da Snapchat, Apple, Facebook, con i registri di viaggio e con altre fonti digitali, costruendo — secondo l’accusa — un pattern coerente che collega il dispositivo a Stokes. Microsoft, va precisato, non ha monitorato l’attività in tempo reale: ha fornito telemetria storica e informazioni sul dispositivo solo dopo un iter legale formale, e aveva già inoltrato segnalazioni penali su Stokes come possibile membro di Scattered Spider fin dal 2024.

Timeline del caso

• 2024 — Microsoft inoltra alle autorità le prime segnalazioni penali su Stokes come possibile membro di Scattered Spider
• Maggio 2025 — intrusione contro un rivenditore statunitense di gioielleria di lusso: l’help desk IT viene manipolato con ingegneria sociale per resettare le credenziali di un dipendente
• Maggio 2025 — esfiltrazione di circa 100 GB di dati e richiesta di riscatto da 8 milioni di dollari in criptovaluta; l’azienda rifiuta di pagare ma subisce perdite operative stimate in circa 2 milioni di dollari
• Aprile 2026 — Stokes viene arrestato a Helsinki mentre tenta di imbarcarsi su un volo per il Giappone
• 30 giugno 2026 — prima udienza federale a Chicago dopo l’estradizione

Non solo telemetria: un mosaico di prove digitali

Nonostante il dibattito online si sia concentrato quasi esclusivamente sul ruolo di Microsoft, l’affidavit chiarisce che gli investigatori si sono basati su molteplici fonti indipendenti: log dei provider cloud, infrastruttura sequestrata, comunicazioni intercettate e prove digitali raccolte nel corso di un’indagine più ampia. È un promemoria importante per chi si occupa di threat intelligence e incident response: l’attribuzione moderna raramente si basa su un singolo indicatore, ma su una correlazione incrociata tra fonti eterogenee — piattaforma, cloud provider, social network, dati di viaggio — che insieme riducono drasticamente lo spazio delle identità plausibili, anche quando l’attaccante ha fatto ampio uso di VPN e servizi di anonimizzazione.

Implicazioni per i difensori e per il settore

Il caso Stokes offre due lezioni parallele. La prima riguarda la resilienza dei processi organizzativi: l’attacco alla gioielleria di lusso è iniziato con un classico vishing/social engineering contro l’help desk IT, lo stesso schema che ha permesso a Scattered Spider di colpire catene alberghiere, compagnie aeree e assicurazioni negli ultimi anni. Rafforzare le procedure di verifica dell’identità per il reset delle credenziali — con callback verification, domande di sicurezza fuori banda o approvazione multi-step — resta la contromisura più efficace e meno costosa contro questo genere di intrusioni.

La seconda lezione riguarda l’attribuzione: la vicenda GDID dimostra che le piattaforme cloud e i sistemi operativi moderni generano una quantità di telemetria sufficiente a ricostruire pattern comportamentali anche a distanza di mesi, sollevando al contempo interrogativi legittimi sulla portata e sulla durata di conservazione di questi dati per finalità che vanno ben oltre il semplice funzionamento del prodotto. Per i team SOC, il takeaway operativo è monitorare con attenzione l’uso di strumenti di tunneling come ngrok all’interno del proprio perimetro: la loro presenza, specie se associata ad accessi VPN anomali, resta uno dei segnali più affidabili di attività Scattered Spider in corso.

Indicatori e TTP noti

Gruppo: Scattered Spider (alias Octo Tempest, UNC3944, 0ktapus)
Soggetto: Peter Stokes, 19 anni, cittadinanza USA/Estonia
Arresto: aprile 2026, Helsinki (Finlandia), tentata fuga verso il Giappone
Estradizione/udienza: 30 giugno 2026, tribunale federale di Chicago

TTP osservate:
  - Vishing / social engineering verso help desk IT per reset credenziali
  - SIM swapping
  - Furto di token/sessioni cloud (Azure, SaaS enterprise)
  - Tunneling via ngrok per infrastruttura C2 temporanea
  - Esfiltrazione dati seguita da estorsione in criptovaluta

Caso di riferimento: intrusione maggio 2025 contro rivenditore di gioielleria di lusso USA
  - ~100 GB di dati esfiltrati
  - Richiesta riscatto: $8.000.000 in criptovaluta (rifiutata)
  - Perdite operative stimate: ~$2.000.000

Fonte identificativa chiave: Microsoft Global Device Identifier (GDID)
  - Fornito all'FBI dietro ordine del tribunale
  - Correlato con IP storici, login Snapchat/Apple/Facebook, dati di viaggio

Perché systemd è ancora il cuore di ogni server Linux moderno

Chiunque amministri sistemi Linux ha digitato decine di volte comandi come systemctl start o systemctl enable senza fermarsi troppo a pensare a cosa succede realmente sotto il cofano. systemd è l’init system presente sulla stragrande maggioranza delle distribuzioni Linux in produzione, e gli unit file sono il meccanismo con cui gli si dice cosa eseguire, quando eseguirlo e come comportarsi in caso di errore.

Conoscere a fondo la sintassi degli unit file e le tecniche di troubleshooting non è un esercizio accademico: è ciò che fa la differenza tra risolvere un servizio bloccato in due minuti o passare mezza giornata a indovinare. Vediamo come scrivere service unit robusti, quali opzioni contano davvero e come diagnosticare i fallimenti più comuni.

Anatomia di un service unit file

Un unit file è un file di configurazione testuale che descrive una risorsa gestita da systemd: servizi (.service), timer (.timer), socket (.socket), mount point (.mount) e altro ancora. In questo articolo ci concentriamo sui service unit, che sono quelli con cui la maggior parte dei sistemisti ha a che fare quotidianamente.

Prima regola pratica: sapere dove vivono i file.

• /lib/systemd/system/ o /usr/lib/systemd/system/ — unit forniti dai pacchetti di sistema, da non modificare mai direttamente
• /etc/systemd/system/ — dove lavori tu: unit personalizzati e override
• /run/systemd/system/ — unit runtime, spariscono al reboot

I file in /etc/systemd/system/ hanno precedenza su quelli in /lib/systemd/system/: è così che funzionano gli override.

Un service unit tipico si compone di tre sezioni: [Unit], [Service] e [Install]. Ecco un esempio minimo ma realistico per un’app Python:

[Unit]
Description=My Python Web App
After=network.target

[Service]
Type=simple
User=webapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/venv/bin/python app.py
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

La sezione [Unit]: ordinamento, non dipendenza

After=network.target indica solo l’ordine di avvio, non una vera dipendenza: il servizio parte dopo che la rete di base è stata configurata, ma non è garantito che un’interfaccia sia effettivamente raggiungibile. Per servizi che devono fare connessioni in uscita all’avvio (database, agenti di sincronizzazione, chiamate verso internet) è preferibile usare network-online.target:

[Unit]
After=network-online.target
Wants=network-online.target

systemctl is-enabled NetworkManager-wait-online.service

La sezione [Service]: dove si gioca la partita

Il parametro Type= descrive come si comporta il processo all’avvio, e sbagliarlo è una delle cause più comuni di servizi che sembrano non funzionare mai correttamente:

• Type=simple (default) — systemd considera il servizio avviato non appena parte il processo ExecStart. Va bene per processi in foreground.
• Type=forking — per demoni “vecchio stile” che fanno fork in background. systemd attende che il processo padre termini; serve quasi sempre PIDFile=.
• Type=notify — il processo notifica la propria disponibilità via sd_notify(). Più affidabile di simple per applicazioni complesse.
• Type=oneshot — per script che eseguono e terminano. Aggiungi RemainAfterExit=yes se vuoi che risulti “active” anche dopo l’uscita.
• Type=exec (systemd 240+) — simile a simple, ma systemd attende l’effettiva execve() del binario prima di considerare il servizio avviato, intercettando i casi in cui ExecStart non riesce nemmeno a partire.

Un dettaglio spesso sottovalutato riguarda i wrapper shell in ExecStart. Se usi:

ExecStart=/bin/bash -c 'echo started >> /var/log/myapp.log && /opt/myapp/start.sh'

Sulla gestione dei riavvii automatici, Restart=on-failure è la scelta più sensata per la maggior parte dei servizi (riavvia su codici di uscita diversi da zero, segnali o timeout), mentre Restart=always va usato con cautela. RestartSec=5 aggiunge un ritardo prima del riavvio: senza, un servizio rotto martella il sistema in loop.

Override sicuri: mai toccare i file dei pacchetti

Non modificare mai i file in /lib/systemd/system/: gli aggiornamenti dei pacchetti sovrascrivono le modifiche. Il modo corretto è usare i drop-in override:

systemctl edit nginx

[Service]
LimitNOFILE=65536
Restart=on-failure

Hardening: sandboxing gratuito integrato in systemd

systemd offre funzionalità di sandboxing native che riducono la superficie d’attacco in caso di compromissione del servizio. Da aggiungere nella sezione [Service]:

# Impedisce l'acquisizione di nuovi privilegi
NoNewPrivileges=yes

# /tmp privato e isolato
PrivateTmp=yes

# Accesso in sola lettura a /usr, /boot, /etc
ProtectSystem=strict

# Impedisce la scrittura nelle home directory
ProtectHome=yes

# Restringe le famiglie di indirizzi utilizzabili
RestrictAddressFamilies=AF_INET AF_INET6

# Limita le syscall a un set sicuro
SystemCallFilter=@system-service

systemd timer: un sostituto moderno di cron

I timer di systemd sono un’alternativa spesso sottovalutata a cron, con logging integrato, gestione delle dipendenze ed esecuzione “catch-up” se il sistema era spento all’orario previsto. Servono due file: il timer e il service corrispondente.

/etc/systemd/system/backup.service:

[Unit]
Description=Nightly Backup

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/backup.sh

[Unit]
Description=Run backup nightly at 2am

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

systemctl enable --now backup.timer
systemctl list-timers

Troubleshooting sistematico dei servizi falliti

Quando un servizio fallisce, conviene seguire un percorso ripetibile invece di procedere per tentativi.

1. Controlla lo stato

systemctl status myapp

● myapp.service - My Python Web App
     Loaded: loaded (/etc/systemd/system/myapp.service; enabled)
     Active: failed (Result: exit-code) since Tue 2026-05-05 14:22:01 UTC
    Process: 1234 ExecStart=/opt/myapp/venv/bin/python app.py (code=exited, status=203/EXEC)

2. Leggi il journal

journalctl -u myapp -n 50      # ultime 50 righe
journalctl -u myapp -f         # segui in tempo reale
journalctl -u myapp -b         # dall'ultimo boot
journalctl -u myapp -b -1      # dal boot precedente

3. Verifica errori di sintassi

systemd-analyze verify /etc/systemd/system/myapp.service

4. Testa manualmente ExecStart

sudo -u webapp /opt/myapp/venv/bin/python app.py

Pattern di errore comuni

• status=203/EXEC: binario non trovato o non eseguibile
• status=217/USER: l’utente specificato in User= non esiste
• status=200/CHDIR: WorkingDirectory non esiste o non è accessibile
• Start request repeated too quickly: crash-loop; aggiungi RestartSec= e resetta il contatore con systemctl reset-failed myapp
• Timeout on start: il servizio non ha segnalato la propria disponibilità in tempo; verifica se Type= è corretto (un demone che fa fork con Type=simple va cambiato in Type=forking)

Un esempio production-ready

Ecco un unit file completo per un’API Node.js che riassume le best practice viste finora:

[Unit]
Description=Node.js API Server
Documentation=https://github.com/example/myapi
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=nodeapp
Group=nodeapp
WorkingDirectory=/opt/myapi
ExecStart=/usr/bin/node /opt/myapi/server.js
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=10
StartLimitBurst=3
StartLimitIntervalSec=60
EnvironmentFile=/etc/myapi/env
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapi

# Hardening
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ReadWritePaths=/var/lib/myapi /var/log/myapi

[Install]
WantedBy=multi-user.target

Comandi rapidi da tenere a portata di mano

# Start, stop, restart, reload
systemctl start myapp
systemctl stop myapp
systemctl restart myapp
systemctl reload myapp

# Abilitazione al boot
systemctl enable myapp
systemctl disable myapp

# Unit completo con override applicati
systemctl cat myapp

# Servizi falliti
systemctl --failed

# Performance di boot
systemd-analyze blame
systemd-analyze critical-chain

Conclusione

Scrivere un service unit non è complicato una volta capito cosa fa ciascuna sezione: [Unit] gestisce ordinamento e dipendenze, [Service] definisce come il processo gira e si riprende dai fallimenti, [Install] controlla il comportamento al boot. Le opzioni di hardening richiedono pochi minuti in più ma vanno inserite di default su ogni servizio esposto in rete. E se ancora lanci job da cron, vale la pena provare un timer systemd: l’integrazione con il journal da sola giustifica il passaggio.

Fonte: LinuxBlog.io – systemd Services: Writing, Managing, and Troubleshooting Unit Files on Linux

Il problema delle soglie statiche negli alert

Chiunque gestisca alert su log query in Azure Monitor conosce il dilemma delle soglie statiche: se il valore è troppo basso, si ricevono notifiche continue per fluttuazioni normali (l’autoscaling di un cluster AKS, il traffico più alto del lunedì mattina, i picchi stagionali di un e-commerce); se è troppo alto, si rischia di non accorgersi di un’anomalia reale finché non è troppo tardi. Il risultato tipico è affaticamento da alert, team che silenziano le notifiche, e problemi che passano inosservati.

Azure Monitor affronta questo problema con le soglie dinamiche (dynamic thresholds) per gli alert su ricerca di log, ora in disponibilità generale e senza costi aggiuntivi rispetto alla normale tariffa degli alert su log query. Vale la pena approfondire come funzionano e come configurarle correttamente, perché il vantaggio pratico per chi gestisce infrastrutture Azure è notevole.

Come funzionano le soglie dinamiche

Le soglie dinamiche applicano algoritmi di machine learning ai risultati delle query di log per apprenderne il comportamento storico. Il sistema analizza i dati nel tempo e identifica pattern ricorrenti — la cosiddetta seasonality, ovvero le fluttuazioni prevedibili che si ripetono a intervalli regolari (orari, giornalieri, settimanali). Quando i risultati della query si discostano in modo significativo dal pattern appreso, l’alert scatta.

In pratica, quando si crea una regola di alert, le soglie dinamiche utilizzano inizialmente 10 giorni di dati storici per calcolare i pattern stagionali orari e giornalieri. Dopo tre settimane, il sistema ha raccolto abbastanza dati da identificare anche i pattern settimanali e aggiusta il modello di conseguenza. Le soglie continuano ad apprendere dai nuovi dati, migliorando l’accuratezza nel tempo.

Configurare un alert su log search con soglia dinamica

La configurazione parte dalla procedura standard per creare una regola di alert su ricerca di log nel portale Azure: si definisce la query, la misurazione e le dimensioni esattamente come si farebbe con una soglia statica. La differenza sta nella sezione Alert logic:

• Per Threshold, selezionare Dynamic invece di Static.
• Per Operator, scegliere tra tre opzioni: Greater than the upper threshold or lower than the lower threshold (l’opzione predefinita, che considera entrambe le direzioni), Greater than the upper threshold, oppure Lower than the lower threshold. Le soglie dinamiche calcolano sia un limite superiore sia uno inferiore, quindi si può scegliere quale tipo di deviazione deve far scattare l’alert.
• Per Threshold sensitivity, selezionare High, Medium (predefinito) o Low. La sensibilità alta imposta soglie strette vicine al pattern misurato e scatta anche per deviazioni minime; quella bassa tollera scostamenti maggiori e si attiva solo per anomalie evidenti.

Dopo aver configurato la condizione, il pulsante Preview Chart mostra i risultati storici della query insieme all’intervallo di soglia calcolato: una linea blu per i valori misurati, un’area viola per l’intervallo di soglia consentito, punti rossi per le violazioni della soglia e barre rosa per gli alert effettivamente scattati. Dopo ogni modifica alla condizione, è necessario selezionare Refresh Chart per aggiornare l’anteprima.

// Esempio di query KQL usata come base per un alert con soglia dinamica
// (conteggio dei riavvii dei pod in un cluster AKS)
KubePodInventory
| where TimeGenerated > ago(1h)
| summarize RestartCount = sum(PodRestartCount) by ClusterName, Namespace, Name

Suddividere l’alert per dimensioni

Una delle funzionalità più utili per chi gestisce ambienti multi-risorsa è la possibilità di suddividere la valutazione dell’alert per dimensioni, ovvero colonne dei risultati della query che contengono dati aggiuntivi come nomi di risorse, namespace o ID di sottoscrizione. Quando si usano le dimensioni, la regola di alert valuta separatamente ogni combinazione di dimensioni e genera un alert indipendente per ciascun gruppo che soddisfa la condizione. È possibile applicare fino a sei dimensioni per regola.

Un caso pratico: monitorare i riavvii dei pod in un cluster AKS suddividendo per Namespace e Name, in modo che ogni namespace e ogni pod ottenga una propria baseline di soglia dinamica. Questo evita che un singolo alert generico “spari” per l’intero cluster quando in realtà è un solo namespace ad avere un comportamento anomalo, e permette al modello di adattarsi a fluttuazioni normali dovute all’autoscaling.

Limiti da conoscere prima di usarle in produzione

Alcune limitazioni sono importanti da tenere a mente per non avere aspettative sbagliate:

• La frequenza minima di valutazione è di 5 minuti.
• Le regole non scattano prima di aver raccolto almeno 3 giorni e 30 campioni di dati: risorse nuove o con dati mancanti non genereranno alert finché non ci sono dati sufficienti.
• Servono almeno 3 settimane di dati storici per rilevare la stagionalità settimanale; pattern come cicli bi-orari o semi-settimanali potrebbero non essere rilevati affatto.
• Le soglie dinamiche sono pensate per rilevare deviazioni significative e improvvise, non problemi che si sviluppano lentamente: un degrado graduale delle prestazioni probabilmente non farà scattare l’alert.
• Non è possibile usare soglie dinamiche in regole che monitorano più condizioni contemporaneamente.
• La configurazione è possibile tramite portale Azure o template ARM; PowerShell e Azure CLI non sono ancora supportati per le regole di alert su log search con soglie dinamiche.
• Il grafico di anteprima ha limiti sull’intervallo temporale in base alla frequenza della regola: con frequenza di 5 minuti si vedono fino a 6 ore di dati, con frequenza di un’ora o superiore fino a 2 giorni.

Come ridurre il rumore (o aumentare la sensibilità)

Se una regola scatta troppo spesso, ci sono diverse leve da regolare prima di abbandonare l’approccio: abbassare la sensibilità della soglia a Low per tollerare deviazioni maggiori, aumentare la granularità di aggregazione (la finestra temporale usata per raggruppare i punti dati) per ridurre la sensibilità a picchi transitori, oppure configurare nelle impostazioni avanzate il numero di violazioni richieste in un determinato periodo prima che l’alert scatti effettivamente.

Al contrario, se una regola non è abbastanza sensibile nemmeno con sensibilità alta, è probabile che la distribuzione dei dati sia molto irregolare. In questi casi Microsoft consiglia di verificare se nei 10 giorni precedenti si è verificato un cambiamento drastico nel comportamento dei dati — per esempio un’interruzione di servizio — che può aver alterato il calcolo delle soglie. Un’altra opzione è monitorare una metrica complementare o modificare la granularità di aggregazione.

Due casi d’uso concreti

Microsoft evidenzia due scenari tipici. Il primo riguarda il monitoraggio dei riavvii dei pod Kubernetes tramite la tabella KubePodInventory, riassumendo i conteggi per cluster, namespace e nome del pod: le soglie dinamiche si adattano alle fluttuazioni normali causate dall’autoscaling e generano alert solo per anomalie reali. Il secondo riguarda il rilevamento di drift nell’inventario delle risorse tramite query di Azure Resource Graph: contando le risorse per tipo e ID sottoscrizione, le soglie dinamiche possono identificare picchi improvvisi nella creazione o cancellazione di risorse che potrebbero indicare deployment fuori controllo, adattandosi ai pattern stagionali di deployment che una soglia statica non riuscirebbe a gestire.

Conclusione

Le soglie dinamiche per gli alert su log search sono una delle funzionalità più concretamente utili di Azure Monitor per chi gestisce ambienti con carichi variabili nel tempo: riducono il rumore degli alert senza richiedere di indovinare manualmente una soglia statica per ogni metrica, e si adattano automaticamente quando cambia la scala dell’infrastruttura. Detto questo, non sono una bacchetta magica: richiedono tempo per costruire una baseline affidabile (fino a tre settimane per la stagionalità settimanale) e non sono adatte a rilevare degradi lenti e progressivi. Per la maggior parte degli scenari di monitoraggio di infrastrutture Azure dinamiche — cluster Kubernetes, ambienti con autoscaling, fleet di risorse in continua evoluzione — rappresentano comunque un netto miglioramento rispetto alle soglie statiche tradizionali.

Fonte: 4sysops.com, con riferimenti alla documentazione ufficiale Microsoft Learn.

Perché ogni release di OpenSSH merita attenzione

OpenSSH non è un pacchetto qualunque nell’inventario di un sistemista: è il canale attraverso cui la stragrande maggioranza degli accessi remoti a server Linux e Unix passa ogni giorno, dai deployment automatizzati alle sessioni interattive degli amministratori. Quando il progetto rilascia una nuova versione con otto correzioni di sicurezza, non è il tipo di changelog da archiviare “per dopo”: va letto, capito e pianificato subito, anche se nessuna delle falle risulta sfruttata attivamente al momento del rilascio.

Il 6 luglio 2026 è uscita OpenSSH 10.4, e oltre alle correzioni porta con sé la prima implementazione sperimentale di una firma post-quantum ibrida e un cambiamento strutturale nel motore che interpreta i pattern con wildcard. Vediamo cosa cambia davvero per chi gestisce infrastrutture in produzione.

Le correzioni di sicurezza che contano di più

Due delle otto falle sono state individuate dallo Swival Security Scanner e riguardano il trasferimento file:

• sftp: un server malevolo poteva dirottare un download avviato da riga di comando (ad esempio sftp host:/percorso .) verso una destinazione diversa da quella attesa sul client.
• scp: durante le copie tra due host remoti, un server compromesso poteva scrivere file nella directory padre di quella di destinazione, uscendo dal perimetro previsto.

Sul lato server (sshd) sono stati corretti altri problemi rilevanti:

• l’implementazione internal-sftp troncava silenziosamente gli argomenti oltre il nono su righe di comando lunghe, con il rischio concreto di perdere un’opzione di sicurezza posizionata più avanti nella riga;
• DisableForwarding=yes non disattivava correttamente il tunneling quando combinato con PermitTunnel=yes, una regressione ora risolta per allinearsi al comportamento documentato;
• è stata chiusa una denial of service pre-autenticazione legata a GSSAPIAuthentication (funzione disattivata di default, ma diffusa in ambienti Active Directory);
• il ritardo minimo di autenticazione — la misura che rallenta i tentativi ripetuti di indovinare una password — in alcuni casi non veniva applicato: ora viene sempre imposto.

Sul client, ssh aveva un bug use-after-free innescabile quando un server cambiava la propria host key durante un re-exchange delle chiavi. Non è uno scenario comune, ma è esattamente il tipo di corner case che un attaccante con un server sotto il proprio controllo può orchestrare deliberatamente.

Checklist di aggiornamento pratica

1. Verifica la versione attuale con ssh -V e sshd -V su tutti i nodi.
2. Prima di riavviare il servizio, testa la nuova configurazione con sudo sshd -t.
3. Se hai script che analizzano l’output di sshd -T o sshd -G, verifica la sensibilità al maiuscolo/minuscolo (vedi sotto).
4. Pianifica la finestra di manutenzione su bastion host e jump server per primi, dato il loro ruolo critico.

La firma post-quantum sperimentale: ML-DSA-44 + Ed25519

La novità più discussa di questa release è il supporto sperimentale per uno schema di firma che combina ML-DSA-44 (l’algoritmo lattice-based standardizzato da NIST) con Ed25519, seguendo la bozza IETF draft-miller-sshm-mldsa44-ed25519-composite-sigs. Le due firme vengono unite in un’unica firma composita: per validare l’autenticazione entrambi gli algoritmi devono verificare correttamente, il che significa che un attaccante dovrebbe rompere sia la crittografia classica sia quella post-quantum per falsificare una chiave.

La funzione resta disattivata di default. Per provarla su un host di test:

# Generare una nuova coppia di chiavi ibride
ssh-keygen -t mldsa44-ed25519 -f ~/.ssh/id_mldsa44_ed25519

# Abilitare l'algoritmo lato client (~/.ssh/config)
Host bastion.esempio.it
    PubkeyAcceptedAlgorithms +mldsa44-ed25519

# Abilitare l'algoritmo per le host key lato server (sshd_config)
HostKeyAlgorithms +mldsa44-ed25519
HostKey /etc/ssh/ssh_host_mldsa44_ed25519_key

Un motore di pattern matching più robusto

La seconda novità tecnica è meno appariscente ma importante lato hardening: il matcher dei pattern con wildcard (usato ad esempio in AllowUsers, Match e nelle liste di host) è stato riscritto attorno a un automa a stati finiti non deterministico (NFA). Il vecchio codice poteva incorrere in un tempo di esecuzione esponenziale su pattern costruiti ad arte, un problema simile ai classici attacchi ReDoS sulle espressioni regolari. Con il nuovo matcher questo caso patologico scompare.

Modifiche che possono rompere configurazioni esistenti

Tre cambiamenti meritano un controllo esplicito prima dell’upgrade:

• L’output di sshd -G ora stampa le direttive in stile misto (es. PubkeyAuthentication) invece che tutto minuscolo: se hai script di parsing con grep case-sensitive, vanno aggiornati.
• Su Linux, se il sandbox seccomp non può essere attivato (o manca NO_NEW_PRIVS), l’avvio di sshd ora fallisce in modo fatale invece di degradare silenziosamente. Ambienti containerizzati con restrizioni sul syscall filtering (alcuni setup gVisor o kernel molto vecchi) vanno testati prima del rollout.
• Il layer di trasporto è diventato più severo: un peer che invia messaggi non pertinenti al key exchange durante un rekey post-autenticazione viene ora disconnesso, chiudendo un vettore di esaurimento memoria.

In sintesi

OpenSSH 10.4 è un aggiornamento da programmare a breve termine, non da rimandare: le correzioni su sftp/scp toccano un vettore di attacco realistico (server malevolo o compromesso), mentre il fix sul ritardo minimo di autenticazione rafforza la resistenza al brute-force. La firma post-quantum resta un esperimento da monitorare, ma è il segnale più chiaro finora che il mondo SSH si sta muovendo verso la crittografia resistente al quantum computing. Prima di eseguire il rollout su larga scala, testate configurazione, script di automazione e ambienti containerizzati: le tre modifiche “breaking” di questa release sono piccole ma possono bloccare un deployment automatizzato se non verificate in anticipo.

Fonte: Help Net Security – OpenSSH 10.4 arrives with security fixes and a post-quantum signature option

Sette nuove vulnerabilità in FatFs, la libreria FAT/exFAT più diffusa nel mondo embedded, mettono a rischio milioni di dispositivi IoT, controllori industriali, drone, telecamere di sicurezza e persino hardware wallet. A scoprirle è stato il team di ricerca runZero, che ha rispolverato un audit di sicurezza del 2017 usando un approccio decisamente più moderno: Visual Studio Code e GitHub Copilot in modalità “auto”, con prompt semplici e nessun tooling custom. Il risultato è stato sorprendente: bug che il fuzzing manuale non aveva mai individuato sono emersi con relativa facilità.

Per chi lavora su sistemi embedded, firmware o dispositivi IoT, questa vicenda merita attenzione non solo per i dettagli tecnici delle CVE, ma anche per quello che rivela sulla fragilità della supply chain del software embedded.

Cos’è FatFs e perché è ovunque

FatFs è una libreria open source compatta, scritta in C, che permette a dispositivi con risorse limitate di leggere e scrivere volumi formattati FAT e exFAT — gli stessi filesystem usati da chiavette USB e schede SD. Proprio per la sua leggerezza è stata integrata, spesso tramite vendoring (copia diretta del codice sorgente nel proprio progetto), in un numero enorme di piattaforme embedded:

• Espressif ESP-IDF
• STMicroelectronics STM32Cube
• Zephyr RTOS
• MicroPython
• ArduPilot
• RT-Thread
• Mbed
• Samsung TizenRT
• SWUpdate

A valle di questi framework troviamo dispositivi IoT di consumo, controllori industriali, drone, hardware crypto wallet, telecamere con slot SD, chioschi pubblici, ATM e persino macchine per il voto elettronico con lettori USB. La maggior parte di questi dispositivi non dispone delle protezioni di memoria che diamo per scontate su desktop e smartphone, a partire dall’ASLR (Address Space Layout Randomization).

Le sette vulnerabilità

Tutte le CVE condividono lo stesso schema di innesco: il dispositivo legge un volume di storage o un’immagine firmware malformata, FatFs gestisce male i dati corrotti, e da lì partono corruzioni di memoria, crash o fughe di informazioni. Due delle sette CVE, la 6682 e la 6683, sono implicate anche nei processi di aggiornamento firmware over-the-air, il che estende la superficie di attacco ben oltre il semplice accesso fisico al dispositivo.

Le tre vulnerabilità più severe (CVSS 7.6, High)

CVE-2026-6682 - Integer overflow in mount_volume() (FAT32)
Un overflow intero può produrre metadati di dimensione file
controllati dall'attaccante. Se questo valore viene usato come
lunghezza di lettura da codice a valle, si arriva a corruzione
di heap/stack e potenziale esecuzione di codice arbitrario.

CVE-2026-6687 - Stack overflow in f_getlabel() (exFAT)
La gestione della label exFAT non limita correttamente la
lunghezza del campo, permettendo scritture oversize nel buffer
della label. Corruzione di memoria diretta nel firmware.

CVE-2026-6688 - Overflow nei filename lunghi
Quando fno.fname supera le dimensioni del buffer fisso nel
codice chiamante, il problema si manifesta tipicamente in
wrapper che usano strcpy o sprintf senza controlli di bound.

Le quattro vulnerabilità di severità media (CVSS 4.6–6.1)

CVE-2026-6685 (CVSS 6.1) - Wraparound in sottrazione unsigned
nella gestione della dirty-cache su volumi frammentati: può
corrompere memoria o causare corruzione silente dei dati,
particolarmente pericolosa in sistemi di logging e controllo.

CVE-2026-6683 (CVSS 4.6) - Divide-by-zero in exFAT nei percorsi
di sync/write, innescabile con media malformati: crash affidabili
e possibile "brick" del dispositivo durante update firmware.

CVE-2026-6686 (CVSS 4.6) - Esposizione di cluster non
inizializzati quando si estende un file oltre EOF: può rivelare
dati residui di file precedentemente cancellati (data leak).

CVE-2026-6684 (CVSS 4.6) - Loop di scansione GPT nelle versioni
precedenti a R0.16: può causare scansioni illimitate e denial
of service al boot. Corretta in R0.16, ma resta presente in
gran parte dei deployment embedded esistenti.

Il vero problema: chi la corregge?

FatFs è mantenuta da un solo sviluppatore. runZero ha tentato ripetutamente di contattarlo e ha coinvolto JPCERT/CC nel processo di coordinamento, senza ottenere risposta. Il risultato è che, delle sette CVE, solo quella relativa alla scansione GPT (CVE-2026-6684) ha una patch upstream disponibile, nella versione R0.16.

Ma anche questa correzione non risolve automaticamente nulla: praticamente tutti i produttori che integrano FatFs lavorano su copie vendorizzate e modificate localmente. Ogni patch upstream deve quindi essere validata con cura prima di essere incorporata nel proprio codice, un processo che — come insegna il precedente di PixieFail (le nove vulnerabilità in EDK II divulgate nel 2024) — può richiedere anni, non settimane.

Cosa fare se sviluppi o gestisci dispositivi con FatFs

Se sei tra chi costruisce firmware che interagisce con storage FAT o exFAT, le priorità immediate sono chiare:

• Individua la copia vendorizzata di FatFs nel tuo codice e verificane la versione
• Fai il audit del wrapper code che circonda le chiamate a FatFs, in particolare come vengono gestiti nomi file e dimensioni
• Presta particolare attenzione a qualsiasi punto in cui fno.fname viene copiato in un buffer di dimensione fissa
• Pianifica la validazione e il rilascio di patch per la tua base di codice specifica

Se invece gestisci dispositivi che integrano FatFs senza averli sviluppati (telecamere, NAS embedded, sistemi industriali), tratta le porte fisiche e i canali di aggiornamento firmware come superficie di attacco: limita chi può inserire fisicamente supporti removibili, monitora gli advisory di sicurezza dei vendor e applica gli aggiornamenti firmware non appena disponibili.

runZero ha pubblicato immagini disco proof-of-concept, un test harness e una dimostrazione di exploit basata su QEMU in un repository di accompagnamento. Alla data di divulgazione (1 luglio 2026) non risultavano attacchi noti che sfruttassero attivamente queste vulnerabilità — ma la disponibilità pubblica di PoC e tooling di fuzzing basato su AI riduce drasticamente il tempo necessario perché qualcuno le sfrutti.

Conclusione

Il caso FatFs è un promemoria di quanto sia fragile la catena di fornitura del software embedded: componenti piccoli, utili e copiati ovunque, che diventano difficili da correggere proprio per la loro diffusione capillare e la mancanza di un processo di manutenzione strutturato. È anche un caso di studio interessante sull’uso di strumenti AI-assisted (Copilot in modalità agente) per il security auditing: un processo che nel 2017 richiedeva settimane di fuzzing manuale, nel 2026 è stato in parte automatizzato con risultati migliori. Per i team che gestiscono flotte di dispositivi embedded, il messaggio pratico è di trattare ogni libreria di terze parti vendorizzata come debito tecnico da monitorare attivamente, non come un componente “impostato e dimenticato”.

Fonte: Security Affairs e 4sysops, basato sulla ricerca originale di runZero.

Un aggiornamento ad Android 17 potrebbe portare con sé un netto miglioramento delle prestazioni di rete su smartphone, almeno stando ad alcune segnalazioni che stanno circolando online. Un utente Reddit ha documentato un incremento di velocità di download vicino al 50% su un Google Pixel 9, riaccendendo la curiosità su cosa si nasconda davvero dietro il nuovo sistema operativo di Google.

Il test: oltre 2 Gbps sul Pixel 9

Tutto nasce da uno screenshot di Speedtest condiviso su Reddit: dopo l’aggiornamento ad Android 17, il Pixel 9 dell’utente ha registrato una velocità di download di circa 2.050 Mbps, contro i circa 1.350 Mbps misurati prima dell’update, sulla stessa rete Wi-Fi. Un salto di circa il 50% che, se confermato su larga scala, farebbe pensare a un’ottimizzazione della gestione della connettività integrata nella nuova versione di Android.

Un caso isolato, per ora

Va detto che si tratta al momento di un singolo riscontro, e Google non ha annunciato ufficialmente alcun miglioramento delle prestazioni di rete legato ad Android 17. Lo stesso utente aveva in passato registrato valori più bassi sullo stesso dispositivo e sulla stessa rete, quindi non si può escludere che le condizioni dell’ambiente di test abbiano influito sul risultato. Curiosamente, nello stesso test anche un OnePlus 11 ha superato i 2 Gbps di download, segno che l’infrastruttura di rete utilizzata era già di per sé molto performante: il collegamento sfruttava un router Wi-Fi 7 di fascia alta con banda dei 6 GHz e una linea capace di raggiungere i 2 Gbps.

Ottimizzazioni di sistema più che nuove funzioni

Android 17 non include, almeno ufficialmente, funzioni dedicate al miglioramento della velocità di rete. Tuttavia ogni nuova versione del sistema operativo porta con sé ottimizzazioni interne ai processi di sistema e alla gestione dei task in background, che possono riflettersi positivamente anche sulle prestazioni di Wi-Fi e rete mobile.

Cosa aspettarsi ora

Se segnalazioni simili dovessero arrivare anche da altri produttori, come Samsung, OnePlus e Xiaomi, si potrebbe iniziare a parlare di un reale miglioramento strutturale introdotto da Android 17. Il beneficio più interessante si vedrebbe soprattutto sui modelli di fascia media e entry level, storicamente più limitati sul fronte della connettività.

Nuove immagini render svelano il design del prossimo Galaxy A18, l’entry level di Samsung atteso nei prossimi mesi. Basate su dati CAD per la produzione di cover, le immagini mostrano una continuità stilistica con l’attuale Galaxy A17, con alcune modifiche mirate al comparto fotografico e alle dimensioni del corpo.

Stile confermato, fotocamere leggermente riviste

Le render, realizzate dal noto leaker OnLeaks a partire da dati CAD destinati ai produttori di accessori, mostrano un design molto simile a quello del Galaxy A17. Il modulo fotografico posteriore a tripla fotocamera viene mantenuto, ma la cornice che lo circonda diventa più piatta, per un effetto complessivo più pulito sul retro del dispositivo. Sul fronte, invece, si conferma il display da 6,7 pollici con notch a goccia Infinity-U per la fotocamera anteriore.

Dimensioni quasi invariate, spessore in leggero aumento

Secondo i dati CAD, le dimensioni del Galaxy A18 sarebbero di 164,4 × 77,8 × 7,84 mm, contro i 164,4 × 77,9 × 7,5 mm del Galaxy A17. L’altezza resta quindi invariata, la larghezza si riduce di appena 0,1 mm, mentre lo spessore aumenta di circa 0,34 mm. Non è ancora chiaro se questo lieve aumento sia legato a una batteria più capiente: al momento si parla di una capacità intorno ai 5.000 mAh, ma la cifra resta da confermare ufficialmente.

Verso Snapdragon al posto di Exynos

Il dato forse più interessante riguarda il chipset: secondo le indiscrezioni, la variante 5G del Galaxy A18 potrebbe abbandonare gli Exynos Samsung a favore di un processore Qualcomm Snapdragon, probabilmente un Snapdragon 6s Gen 3. Il modello 4G, invece, dovrebbe continuare a puntare su un chip MediaTek.

Le altre specifiche circolate finora

• Display Super AMOLED da 6,7 pollici
• Refresh rate a 90 Hz
• Batteria da circa 5.000 mAh
• Supporto alla ricarica rapida

Anche il comparto fotografico dovrebbe restare in gran parte invariato rispetto al modello precedente, con sensore principale da 50 MP, ultra-grandangolare da 5 MP e macro da 2 MP. Per il prezzo, alcune fonti britanniche indicano un posizionamento in linea con quello del Galaxy A17. La data di lancio non è ancora nota, ma tutto lascia pensare a un’evoluzione misurata, concentrata più sull’aggiornamento del chipset che su un cambio radicale di design: un aggiornamento tipico da fascia entry, per una delle serie Samsung più vendute al mondo.

Google ha avviato il rilascio dell’aggiornamento software di luglio 2026 per la famiglia Pixel, il primo intervento di manutenzione mensile dopo il debutto della versione definitiva di Android 17. L’update non introduce nuove funzioni, ma corregge cinque problemi che stavano creando disagi concreti agli utenti, dai riavvii improvvisi ai crash delle app.

Corretto il fastidioso bootloop

La correzione più significativa riguarda i casi in cui il dispositivo non riusciva più ad avviarsi correttamente, restando bloccato in un ciclo di riavvii continui. Alcuni utenti Pixel avevano segnalato schermate bloccate al caricamento del sistema: un problema serio, ora risolto con questo aggiornamento.

Risolti anche crash delle app e problemi grafici

L’update interviene anche su un bug che causava la chiusura improvvisa di alcune applicazioni o ne impediva il corretto avvio, un fastidio capace di toccare l’utilizzo quotidiano di moltissimi utenti. Sono stati sistemati inoltre due problemi grafici: un’anomalia nei colori e nel contrasto dei widget di sistema, e un effetto di forma applicato agli sfondi che in alcuni casi copriva il soggetto principale della foto invece di valorizzarlo.

Una correzione dedicata al Pixel 10 Pro Fold

Per il pieghevole Pixel 10 Pro Fold è prevista una correzione specifica: veniva risolto lo spostamento della posizione dei pulsanti di navigazione subito dopo l’apertura o la chiusura del dispositivo, un difetto tipico dei device con schermo flessibile.

Chi riceve l’aggiornamento e come verificarlo

L’update è destinato ai modelli Pixel 6 e successivi, inclusi Pixel 10, Pixel Tablet e i pieghevoli, e viene distribuito via OTA in modo progressivo nell’arco di circa una settimana. Chi non volesse attendere la notifica può controllare la disponibilità andando su Impostazioni, poi Sistema e infine Aggiornamento software; in alternativa, immagini factory e file OTA sono già disponibili sul sito sviluppatori di Google.

Dopo un rilascio di Android 17 ricco di novità, questo primo aggiornamento mensile punta tutto sulla stabilità: per chi possiede un Pixel, si tratta di un tassello importante per un’esperienza d’uso più solida con la nuova versione del sistema operativo.

Il futuro top di gamma fotografico di Xiaomi potrebbe non vedere mai la luce. Secondo nuove indiscrezioni, lo sviluppo di Xiaomi 18 Ultra sarebbe stato sospeso o addirittura cancellato, un colpo di scena che rimetterebbe in discussione la strategia dell’azienda cinese sul segmento più estremo del mercato smartphone.

Una fotocamera ambiziosissima, forse mai realizzata

Le indiscrezioni raccolte finora descrivevano un comparto fotografico senza compromessi: sensore teleobiettivo LOFIC da 1/1,28 pollici e 200 megapixel, zoom ottico continuo e messa a fuoco macro fino a 15 centimetri. Sarebbe stata la configurazione più ambiziosa mai vista su un modello Ultra, frutto della collaborazione con Leica che ha caratterizzato l’intera serie.

Costi e domanda di mercato dietro lo stop

Secondo fonti del settore, dietro la possibile cancellazione ci sarebbero soprattutto ragioni industriali ed economiche.

• Costi di produzione elevati per moduli fotocamera e sensori LOFIC
• Difficoltà tecniche nello sviluppo del meccanismo di zoom ottico continuo
• Criticità nell’approvvigionamento di alcuni componenti avanzati
• Una domanda di mercato sempre più orientata a flagship bilanciati piuttosto che a modelli fotografici estremi

Xiaomi starebbe quindi valutando di dirottare le risorse verso un modello capace di raggiungere un pubblico più ampio, piuttosto che concentrarsi su un dispositivo di nicchia dal prezzo molto elevato.

Xiaomi 18 Pro Max come possibile erede

Al posto dell’Ultra, secondo le stesse fonti, Xiaomi punterebbe su un “Xiaomi 18 Pro Max” con display generoso e Snapdragon 8 Elite Gen 6 Pro, che potrebbe ereditare parte delle tecnologie fotografiche pensate per l’Ultra. Un cambio di strategia che concentrerebbe l’innovazione nel Pro Max invece di mantenere un brand Ultra a sé stante.

Le voci contrastanti dei leaker

Non tutti concordano su questo scenario: il noto leaker Digital Chat Station aveva in precedenza condiviso dettagli sulla fotocamera dell’Ultra, lasciando intendere che lo sviluppo fosse ancora attivo. Se la cancellazione fosse reale, si tratterebbe quindi di una decisione presa in tempi recenti.

Cosa significherebbe per la serie Ultra

Qualora Xiaomi 18 Ultra non arrivasse mai sul mercato, si tratterebbe di una svolta importante per la strategia flagship dell’azienda, che finora ha usato la serie Ultra come vetrina fotografica. Secondo le stesse fonti, la serie potrebbe comunque tornare con Xiaomi 19 Ultra nella seconda metà del 2027, segno che l’addio al segmento più estremo potrebbe essere solo temporaneo. Al momento non c’è alcuna conferma ufficiale da parte dell’azienda, e la vicenda resta quindi da verificare nelle prossime settimane.

Un post pubblicato dall’account ufficiale giapponese di Qualcomm ha scatenato le proteste degli appassionati Xperia: nella descrizione dello Xperia 1 VIII, Snapdragon Japan ha indicato un display con rapporto 21:9, caratteristica che però lo smartphone Sony non possiede più da due generazioni.

L’errore nel post di Snapdragon Japan

Il 6 luglio, l’account X ufficiale di Snapdragon Japan ha pubblicato un contenuto promozionale dedicato allo Xperia 1 VIII, equipaggiato con Snapdragon 8 Elite Gen 5, descrivendone il display come un pannello “21:9 ad alta definizione” capace di offrire, insieme agli altoparlanti migliorati, un’esperienza immersiva paragonabile a quella del cinema. Il problema è che questa descrizione non corrisponde più alle caratteristiche reali del dispositivo.

Dallo Xperia 1 VI in poi il rapporto è 19,5:9

Sony ha mantenuto il rapporto d’aspetto 21:9, ispirato ai grandi schermi cinematografici, dal primo Xperia 1 fino allo Xperia 1 V. Con lo Xperia 1 VI, lanciato nel 2024, l’azienda ha però cambiato rotta, passando a un display 19,5:9, formato confermato anche su Xperia 1 VII e sull’attuale Xperia 1 VIII. Il rapporto 21:9 resta quindi una caratteristica dei soli modelli precedenti allo Xperia 1 VI.

Le reazioni della community Xperia

A far notare l’errore è stata la community “SonyXperia” su Reddit, dove diversi utenti hanno segnalato l’imprecisione nel post di Snapdragon Japan, chiedendo una correzione o la rimozione del contenuto. La preoccupazione principale riguarda chi non segue da vicino l’evoluzione della serie Xperia e potrebbe farsi un’idea sbagliata delle caratteristiche del nuovo modello, magari basandosi sui ricordi di uno Xperia 1 III, IV o V, ancora oggi diffusi tra gli utenti.

Un dettaglio che pesa nella scelta d’acquisto

Per chi valuta l’acquisto di uno Xperia 1 VIII, il rapporto d’aspetto dello schermo non è un dettaglio secondario: il formato allungato 21:9 è stato per anni un tratto distintivo della serie, apprezzato da una parte consistente degli utenti Xperia. Un’informazione errata proprio su questo aspetto, diffusa da un canale ufficiale legato al produttore del chip, rischia quindi di generare confusione in un momento delicato per il lancio del nuovo top di gamma Sony.

Xiaomi potrebbe rilasciare già la prossima settimana la beta di HyperOS 3.3, un aggiornamento pensato principalmente per preparare il terreno all’adozione di Android 17 sui dispositivi dell’azienda, in attesa dell’arrivo della release più corposa, HyperOS 4.

Un aggiornamento ponte basato su HyperOS 3.1

Secondo le informazioni circolate finora, HyperOS 3.3 sarà un aggiornamento minore costruito sull’attuale HyperOS 3.1, con la novità principale rappresentata dall’integrazione delle API di Android 17. L’obiettivo è migliorare la compatibilità delle app e la stabilità generale del sistema, senza introdurre un restyling dell’interfaccia o funzioni particolarmente vistose.

I modelli coinvolti nella beta

La beta di HyperOS 3.3 dovrebbe interessare inizialmente un numero limitato di dispositivi:

• Xiaomi 17
• Xiaomi 17 Ultra
• Xiaomi 15T Pro

Il rollout riguarderebbe non solo la Cina, ma anche le versioni globale, europea, indiana e russa, con un numero di build indicato come “OS3.0.331.0.X”, in aggiornamento rispetto all’attuale serie OS3.0.301.

Il vero salto sarà con HyperOS 4

HyperOS 3.3 resta comunque un passaggio intermedio: le novità più rilevanti sono attese con HyperOS 4, che secondo le indiscrezioni introdurrà un nuovo linguaggio grafico ispirato al “Liquid Glass”, un netto potenziamento delle funzioni basate su intelligenza artificiale e una revisione dell’architettura di sistema.

Debutto di HyperOS 4 sempre più vicino

Il leaker cinese Digital Chat Station ha di recente indicato agosto come possibile mese di presentazione per HyperOS 4, sviluppato anch’esso su base Android 17 e con un utilizzo più ampio di Rust e Flutter per migliorare fluidità ed efficienza nella gestione della memoria. In questo scenario, HyperOS 3.3 assumerebbe soprattutto il ruolo di preparare in anticipo la base tecnica su cui costruire il passaggio a HyperOS 4, rendendo la transizione più fluida per gli utenti Xiaomi.

Mancano poco più di quattro settimane alla presentazione ufficiale della serie Pixel 11, e nelle ultime ore si sono accumulate diverse informazioni che iniziano a comporre un quadro piuttosto completo: data dell’evento, primo sguardo al design del Pixel 11 Pro, finestra di lancio e persino i prezzi europei attesi per i quattro nuovi modelli.

L’evento è ufficiale: 11 agosto a New York

Google ha inviato gli inviti alla stampa per l’evento di presentazione, in programma l’11 agosto alle 18 (ora della costa est USA) a New York. L’invito promette di “presentare la prossima generazione di Pixel”, e si attende il debutto di Pixel 11, Pixel 11 Pro, Pixel 11 Pro XL, Pixel 11 Pro Fold e del nuovo smartwatch Pixel Watch 5.

Il design del Pixel 11 Pro si mostra nel teaser

Nell’immagine teaser diffusa da Google compare per la prima volta anche il presunto Pixel 11 Pro, con un design che ricalca da vicino quanto già emerso dai render trapelati nelle scorse settimane: cornice piatta in metallo e caratteristica barra fotocamere che attraversa il retro del dispositivo, oltre a una nuova colorazione dorata. Non si nota invece, almeno in questa immagine, la funzione di illuminazione posteriore “Pixel Glow” di cui si vocifera da tempo, anche se potrebbe essere integrata nella parte in vetro nero della barra fotocamere.

Vendite al via il 20 agosto

Secondo il leaker francese billbil-kun, che pubblica abitualmente su Dealabs, la commercializzazione dei quattro modelli inizierebbe il 20 agosto, circa una settimana dopo la presentazione ufficiale, in linea con lo schema ormai consolidato negli ultimi anni: annuncio, apertura dei preordini e lancio sul mercato a distanza di circa otto giorni.

Addio al taglio da 128 GB, prezzi in aumento

Le indiscrezioni più recenti indicano anche un cambio nella gamma degli storage: il taglio base da 128 GB verrebbe eliminato, con tutti i modelli che partirebbero da 256 GB. Una novità che si accompagnerebbe però a un aumento di prezzo di circa 100 euro per ciascun modello in Europa.

• Pixel 11 (256 GB): 999 euro
• Pixel 11 Pro (256 GB): 1.199 euro
• Pixel 11 Pro XL (256 GB): 1.399 euro
• Pixel 11 Pro Fold (256 GB): 1.999 euro

Considerando il raddoppio dello storage minimo, l’aumento reale sarebbe meno marcato di quanto sembri a prima vista; l’incremento dei prezzi della memoria RAM sul mercato globale viene indicato come una delle possibili cause. Applicando le stesse percentuali di rincaro ai prezzi giapponesi dell’attuale gamma Pixel 10, il Pixel 11 potrebbe attestarsi attorno ai 143.000 yen, ma si tratta per ora solo di stime basate sulle percentuali europee, che potrebbero non riflettersi allo stesso modo sui listini degli altri mercati, Italia compresa.

Cosa resta da scoprire

Nessuna di queste informazioni è stata confermata ufficialmente da Google, che finora ha reso pubblica solo la data dell’evento del prossimo 11 agosto. Mancano ancora dettagli certi su specifiche tecniche, funzioni AI e colorazioni definitive, ma il quadro generale della nuova serie Pixel comincia finalmente a delinearsi con chiarezza.

Un dispositivo che sembra corrispondere al futuro Redmi Note 17 Pro è comparso sul database di Geekbench, rivelando alcune informazioni su chipset, memoria e sistema operativo del prossimo smartphone di fascia media firmato Xiaomi.

Il modello con codice 2607DRA18C

Il dispositivo, identificato dal codice 2607DRA18C, è stato registrato sulla piattaforma di benchmark con un processore Qualcomm siglato QTI SM6435, che secondo la configurazione riscontrata corrisponderebbe a uno Snapdragon 6s Gen 4.

Configurazione a 8 core e 12 GB di RAM

La scheda tecnica emersa da Geekbench indica una CPU octa-core, con quattro core fino a 2,4 GHz e altri quattro core fino a 1,8 GHz, accompagnata da 12 GB di RAM e sistema operativo Android 16. Sul fronte prestazionale, il dispositivo ha ottenuto 1.027 punti in single-core e 3.002 punti in multi-core, un risultato nella norma per un chip di fascia media, adatto sia all’uso quotidiano sia al gaming meno esigente.

Un chip diverso da quanto ipotizzato in precedenza

Le indiscrezioni circolate finora indicavano per Redmi Note 17 Pro l’adozione di uno Snapdragon 6 Gen 5, ma il nuovo riscontro su Geekbench, riferito a quello che sembra un’unità di test più vicina al prodotto finale, suggerisce che il chip effettivamente montato sarà lo Snapdragon 6s Gen 4. Lo stesso codice modello era già comparso in precedenza in un database di certificazione, dove era stato confermato il supporto alla ricarica rapida da 67W.

Una gamma Note 17 in tre varianti

La nuova serie Redmi Note 17 dovrebbe articolarsi in tre modelli: Note 17, Note 17 Pro e Note 17 Pro Max. Per ora sono note solo alcune specifiche del modello Pro, mentre restano ancora da confermare display, fotocamere e capacità della batteria. La serie Redmi Note continua comunque a rappresentare un punto di riferimento per chi cerca prestazioni solide e un buon rapporto qualità-prezzo, e anche questa nuova generazione sembra destinata a muoversi nella stessa direzione.

Nuove indiscrezioni delineano le caratteristiche di Redmi Turbo 6 Max, il prossimo smartphone ad alte prestazioni del marchio controllato da Xiaomi. Display generoso, batteria enorme e un design orientato alla resistenza: se le voci saranno confermate, il debutto è previsto per l’inizio del 2027.

Display da 7 pollici e chip Dimensity di nuova generazione

A diffondere le informazioni è stato il leaker cinese Digital Chat Station, tra le fonti più affidabili quando si parla di smartphone non ancora annunciati, tramite un post pubblicato sul social cinese Weibo. Secondo il leaker, Redmi lancerebbe un nuovo modello ad alte prestazioni attorno a gennaio 2027: pur senza confermare il nome commerciale, le informazioni raccolte finora fanno pensare proprio a Redmi Turbo 6 Max. Il dispositivo dovrebbe montare un ampio display piatto da circa 7 pollici con risoluzione 2K, abbinato a un chip Dimensity di nuova generazione ancora non annunciato, probabilmente prodotto con processo a 3 nanometri.

Batteria da 10.000 mAh e grande resistenza

Il punto di forza del nuovo Redmi Turbo dovrebbe essere l’autonomia: si parla di una batteria da circa 10.000 mAh, una capacità fuori dal comune per uno smartphone ad alte prestazioni, capace di garantire un’autonomia particolarmente lunga rispetto alla media di categoria.

• Sensore di impronte digitali in-display a ultrasuoni
• Telaio centrale in metallo
• Certificazione di resistenza IP68/IP69 attesa

Un pacchetto che punta su prestazioni elevate senza rinunciare a robustezza e praticità d’uso quotidiano.

Possibile debutto globale come POCO X9 Pro Max

Sul mercato cinese, Redmi Turbo 6 Max si troverebbe a competere direttamente con i prossimi modelli ad alte prestazioni di OnePlus. A livello internazionale, invece, il dispositivo potrebbe arrivare con un nome diverso, come “POCO X9 Pro Max”, seguendo una strategia già vista in passato per altri modelli della serie Turbo.

Un’attesa che punta sul rapporto qualità-prezzo

La serie Redmi Turbo si è costruita negli anni una solida reputazione puntando su chip potenti e batterie generose a un prezzo relativamente contenuto, e Turbo 6 Max sembra destinato a proseguire su questa linea. Mancano ancora diversi mesi alla presentazione ufficiale, ma è probabile che nelle prossime settimane emergano ulteriori dettagli sulle specifiche complete del dispositivo.

Xiaomi sembra avvicinarsi sempre di più alla presentazione di HyperOS 4, la nuova versione della propria interfaccia personalizzata basata su Android 17. Secondo un noto leaker cinese, l’annuncio ufficiale potrebbe arrivare già ad agosto, con un design rinnovato e un netto potenziamento delle funzioni di intelligenza artificiale.

Test interni già avviati con HyperOS 3.3

Stando alle indiscrezioni, Xiaomi avrebbe già avviato test interni di “HyperOS 3.3”, versione basata su Android 17 ma non destinata alla distribuzione pubblica: si tratterebbe piuttosto di una build di transizione, funzionale allo sviluppo del più corposo HyperOS 4.

Annuncio ad agosto, si parte dalla Cina

Il leaker Digital Chat Station indica agosto 2026 come possibile mese per la presentazione ufficiale di HyperOS 4. Come da tradizione, il rilascio dovrebbe partire dal mercato cinese con una fase beta e una distribuzione iniziale, per poi estendersi gradualmente ai mercati internazionali, non escludendo l’avvio di un programma di beta pubblica nelle settimane successive.

Riscrittura del sistema e design “Liquid Glass”

Le informazioni circolate finora parlano di una revisione profonda del codice di base, sviluppato sempre più con Rust e Flutter, con l’obiettivo di eliminare il codice ereditato dai tempi di MIUI in un’ottica di “design a zero eredità”. Le voci parlano di un miglioramento della fluidità di circa il 40% e dell’efficienza della memoria fino al 30%, oltre a un minor calo delle prestazioni nel tempo. Sul fronte estetico, si vocifera anche dell’adozione di uno stile ispirato al “Liquid Glass”, lo stesso linguaggio grafico che ha fatto discutere anche nel mondo Apple.

Intelligenza artificiale protagonista

HyperOS 4 dovrebbe puntare molto anche sulle funzioni di intelligenza artificiale, con il potenziamento delle funzioni già esistenti e l’introduzione di nuove capacità pensate per semplificare l’uso quotidiano dello smartphone.

Versione stabile in arrivo con Xiaomi 18

Se la beta potrebbe partire già ad agosto, la versione stabile di HyperOS 4 dovrebbe invece debuttare insieme alla serie Xiaomi 18, attesa più avanti nell’anno. Tra i primi dispositivi a ricevere l’aggiornamento dovrebbero esserci gli attuali top di gamma Xiaomi 17, oltre potenzialmente alla serie Redmi K90. Con HyperOS 4, Xiaomi punta quindi a un salto generativo sia in termini di leggerezza del sistema sia di funzioni intelligenti, e nelle prossime settimane sono attesi ulteriori dettagli su calendario e dispositivi compatibili.

Nothing ha presentato ufficialmente Nothing Phone (4b), il nuovo smartphone di fascia media che punta tutto sull’autonomia: si tratta del modello con la batteria più capiente mai realizzato dall’azienda, abbinato allo Snapdragon 6 Gen 4 e alla nuova Glyph Bar, il tutto a un prezzo relativamente contenuto.

Autonomia da record per la serie

Il Nothing Phone (4b) monta una batteria da 5.200 mAh nella versione globale, con un’autonomia dichiarata fino a 22 ore di riproduzione video continua. Per il mercato indiano è prevista anche una variante con batteria da 6.000 mAh. Sul fronte ricarica, il dispositivo supporta la ricarica rapida cablata da 33W e la ricarica inversa cablata da 7,5W, mentre manca il supporto alla ricarica wireless.

Snapdragon 6 Gen 4 per un posizionamento intermedio

Il nuovo modello si colloca nel listino Nothing tra Phone (3a) Lite e Phone (4a), con prestazioni superiori al Dimensity 7300 Pro del primo ma leggermente inferiori allo Snapdragon 7s Gen 4 del secondo. La memoria segue schemi diversi a seconda del mercato: 8 GB di RAM LPDDR4X con 128 GB di storage UFS 2.2 nella versione globale, con opzione a 256 GB per l’India. A differenza del Phone (3a) Lite, non è previsto lo slot per microSD.

Display AMOLED a 120 Hz e fotocamera da 50 MP

Il pannello è un OLED da 6,77 pollici FHD+ con refresh rate a 120 Hz, luminosità massima all’aperto di 1.200 nit e picco di 2.000 nit, protetto da vetro Dragontrail Pro. Sul retro trova posto una doppia fotocamera con sensore principale da 50 megapixel con stabilizzazione ottica e un ultra-grandangolare da 8 megapixel con campo visivo di 120 gradi, capace di registrare video fino al 4K a 30fps. La fotocamera anteriore è invece da 16 megapixel.

Glyph Bar, AI ed Essential Key

Il dispositivo eredita dal Phone (4a) la Glyph Bar, la striscia luminosa posteriore con quattro LED bianchi e uno rosso personalizzabile da Nothing OS, utile per notifiche, timer e indicatore di registrazione. Sul fianco è presente l’Essential Key, tasto dedicato per richiamare rapidamente funzioni AI come Essential Voice ed Essential Search.

• Sistema operativo: Nothing OS 4.1 su base Android 16
• Aggiornamenti Android garantiti per 3 anni
• Patch di sicurezza garantite per 6 anni
• Certificazione IP64, testato fino a 25 cm di profondità per 20 minuti
• Wi-Fi 6, Bluetooth 6.0, NFC e dual SIM (con eSIM in Giappone)

Prezzo e disponibilità

Nothing Phone (4b) viene proposto in Europa a 330 euro, nelle colorazioni bianca, nera e blu, con i preordini già aperti. Vista l’attenzione che Nothing ha sempre riservato al mercato italiano con i suoi Phone, non è escluso un arrivo anche da noi nelle prossime settimane.

Google ha introdotto una nuova impostazione che consente di utilizzare foto, video e file audio caricati dagli utenti per migliorare i propri modelli di intelligenza artificiale. La funzione è attiva di default, ma può essere disattivata facilmente dalle impostazioni sulla privacy dell’account Google.

I contenuti multimediali usati per addestrare l’AI

Il colosso di Mountain View ha recentemente riorganizzato una parte delle impostazioni relative ai dati di attività, introducendo un meccanismo che permette di conservare immagini, audio e video caricati sui servizi Google per migliorarne il funzionamento, incluso l’addestramento dei modelli di intelligenza artificiale. Non si tratta solo di Google Search: la novità coinvolge anche servizi come Google Maps, Google Traduttore, Google Shopping, Google Voli e Google Hotel.

Come disattivare l’utilizzo dei propri contenuti

Chi non desidera che le proprie foto e i propri video vengano utilizzati per l’addestramento dell’intelligenza artificiale può intervenire facilmente sulle impostazioni dell’account.

• Aprire le impostazioni della “Cronologia dei servizi di ricerca” nell’account Google
• Disattivare la voce relativa al salvataggio dei contenuti multimediali
• In alternativa, disattivare completamente la cronologia dei servizi di ricerca
• Impostare un periodo di conservazione con cancellazione automatica dei dati

Un’impostazione nata da una riorganizzazione più ampia

La novità nasce da una suddivisione più granulare dei dati che in precedenza rientravano nella voce “Attività web e app”: i dati legati alla ricerca sono stati isolati in una categoria a sé stante, di cui questa nuova opzione sui contenuti multimediali fa ora parte.

Perché conviene controllare le impostazioni periodicamente

Google aggiorna con una certa frequenza le proprie impostazioni sulla privacy, spostando voci esistenti o introducendone di nuove, e non è raro che gli utenti perdano traccia di dove si trovino determinate opzioni. Con lo sviluppo sempre più rapido dell’intelligenza artificiale, l’ambito di utilizzo dei dati personali è destinato ad ampliarsi ulteriormente: per chi utilizza quotidianamente i servizi Google, un controllo periodico delle impostazioni sulla privacy resta il modo più sicuro per mantenere il controllo su come vengono trattati i propri contenuti.