Diciamocelo subito: se riuscite a scassinare la porta blindata di un datacenter e il proprietario vi ringrazia con un assegno da un quarto di milione di dollari, avete ufficialmente vinto la partita della vita.

Questa settimana la sicurezza del kernel Linux ha ricevuto una bella scossa. Google ha deciso di svuotare il portafogli, versando ben 250.000 dollari a un ricercatore per segnalare una vulnerabilità di alto livello. Non stiamo parlando della solita fessura che permette di leggere un file di configurazione dimenticato in giro, ma di qualcosa di decisamente più cinematico: un «guest VM escape».

Per chi non mastica kernel e hypervisor ogni notte davanti a un caffè freddo, ecco il succo della questione. Immaginate di essere chiusi in una cella di massima sicurezza (la vostra macchina virtuale, o VM). Tutto intorno a voi ci sono muri di cemento armato, telecamere e guardie che controllano ogni vostro movimento. L’idea è che, anche se riusciste a scatenare l’inferno dentro la cella, non potreste in alcun modo toccare il resto del carcere. Ecco, questo bug permetteva di trovare un passaggio segreto nella tubatura, uscendo dalla cella e finendo direttamente nell’ufficio del direttore, con privilegi di root tutto vostro. Un vero e proprio salto fuori dal recinto.

Il problema non è solo la gravità tecnica, che è oggettivamente brutta, ma il potenziale impatto. Quando parliamo di cloud e infrastrutture condivise, l’illusione del confine è tutto ciò che ci separa dal caos. Se un utente non autorizzato può «evadere» dalla propria istanza per infettare l’host o altre macchine virtuali sullo stesso server, il concetto stesso di isolamento diventa una barzelletta senza senso.

Certo, leggendo la notizia dai soliti canali americani, sembra quasi una passeggiata di gloria. Ma restiamo con i piedi per terra: per noi che viviamo tra server in garage, Raspberry Pi e piccoli nodi self-hosted, queste beghe da grandi corporation spesso sembrano far parte di un ecosistema parallelo, quasi distaccato dalla realtà quotidiana. Però, c’è un lato positivo: il sistema di bug bounty funziona e il kernel Linux si è già mosso per patchare il buco.

Insomma, meno fumo negli occhi e più patch applicate. Se proprio dobbiamo preoccuparci, meglio che sia per un bug che ci ha portato un premio da 250k, piuttosto che per una nuova policy di qualche big tech che decide arbitrariamente cosa possiamo o non possiamo compilare sul nostro terminale.

Source: Google pays $250K for Linux vulnerability allowing guest VM escapes

C’è qualcosa di profondamente catartico nell’osservare un vecchio nemico che finalmente viene estirpato dal proprio ecosistema. Non parlo di un boss di fine livello di un RPG che non riesci mai a battere, ma di una funzione C che è stata per anni una brutta bestia capace di scatenare bug a tradimento: la mitica strncpy.

Con l’arrivo del kernel Linux 7.2, la strncpy è ufficialmente andata in pensione. E non parlo di quel pensionamento dignitoso con festa e torta, ma di una rimozione chirurgica dopo un lavoro titanico durato sei anni e che ha richiesto ben 362 commit. Se pensate che sia solo una formalità da manuale, vi sbagliate di grosso: è stata una pulizia profonda, un setaccio che ha rimosso ogni traccia rimasta di questa API nelle implementazioni per ogni singola architettura CPU.

Per chi non ha passato le notti insonni a debuggare buffer overflow, lasciate che vi spieghi perché strncpy era il tipo di collega che nessuno vuole in team. Questa funzione ha una semantica così controintuitiva che fa sembrare i regolamenti della privacy europei una lettura leggera per bambini. Il problema principale? La gestione del terminatore NUL. Strncpy può decidere di non aggiungerlo se non riesce a completare la copia, lasciandoti con una stringa che è una vera bomba a orologeria pronta a esplodere non appena qualcuno prova a leggerla.

In più, c’è il problema delle performance. strnccpy ha la cattiva abitudine di riempire inutilmente con zeri il resto della destinazione, sprecando cicli CPU che potrebbero essere usati per cose molto più interessanti, tipo far girare un container in più o compilare un kernel senza piangere. È quel tipo di inefficienza che ti fa venire voglia di lanciare il laptop dalla finestra.

Ora, la strada è spianata verso alternative molto più sane e trasparenti. Se devi copiare stringhe con terminatore, c’è strscpy. Se ti serve il padding, ci sono strscpy_pad o memcpy_and_pad. È un approccio molto più ‘explicit’ e meno ‘magia nera che sembra funzionare ma poi ti frega’.

Non è una notizia che cambierà la vita del sysadmin che gestisce un server in un datacenter in Lombardia, ma per noi che viviamo di codice e di tutto ciò che è open source, è un segnale di salute. Dimostra che il kernel Linux non è un museo polveroso dove si conserva tutto per paura di rompere qualcosa, ma un organismo vivo che ha il coraggio di fare manutenzione pesante per eliminare il debito tecnico. È l’approccio che vorremmo anche nella vita reale: se una cosa è strutturalmente sbagliata e genera solo problemi, non cercare di metterci un patch, eliminala e passa oltre.

Source: Linux eliminates the strncpy API after six years of work, 360 patches

Tutto può crollare per un semplice refuso, proprio come quando scrivi un punto e virgola dove non dovrebbe stare in un pezzo di C++ e il compilatore ti urla in faccia per mezz’ora.

Questa volta non parliamo del tuo codice scritto alle tre di notte dopo tre caffè, ma di qualcosa di molto più serio: il cuore pulsante di quasi tutto il mondo digitale. Una vulnerabilità ad alta severità è stata scoperta nel kernel Linux e, come suggerisce il titolo, la colpa è di un singolo carattere errato. Sì, avete letto bene. Un piccolo ‘glitch’ nel tessuto della realtà informatica che permette a un attaccante di bypassare le difese sandbox e ottenere i privilegi di root. Praticamente, un invito a cena non richiesto per chiunque voglia prendere il controllo totale della macchina.

Tecnicamente parliamo di un bug di tipo ‘use-after-free’. Per chi non mastica kernel development ogni mattina, significa che il sistema tenta di usare una porzione di memoria che è già stata liberata. È come cercare di ordinare una pizza su un numero di telefono che non esiste più, ma finendo per riuscire a entrare in cucina e cambiare tutti i menu del ristorante. Il risultato? Un’escalation di privilegi che trasforma un utente limitato nel padrone assolato del sistema.

Da smanettone, la cosa mi fa riflettere su quanto sia fragile l’infrastruttura su cui poggiamo tutto. Passiamo le giornate a ottimizzare script, a modellare oggetti in Blender o a configurare CNC per stampare pezzi in plastica riciclata, convinti che il sistema operativo sia una roccia indistruttibile. Invece, basta un carattere fuori posto per mandare tutto in vacca. È il classico paradosso dell’ingegneria: costruiamo cattedrali di codice sopra fondamenta che possono tremare per un errore di battitura.

Cosa significa per noi? Se gestite server, lab di automazione o semplicemente avete un setup Linux che fa girare i vostri progetti Godot o i vostri server domestici, fate il check degli aggiornamenti. Non fate i pigri: patchate il kernel. Non è il caso di aspettare che qualcuno decida di testare questa falla sul vostro cluster di Raspberry Pi.

In un mondo dove l’hype sull’IA e le super-app corporate ci promette sicurezza e semplicità, ricordiamoci che la vera vulnerabilità risiede nella complessità stessa. La prossima volta che vedete un errore di sintesi banale, non rideteci sopra: potrebbe essere la porta d’ingresso per il prossimo caos digitale.

Source: High-severity vulnerability in Linux caused by a single errant character

Chi l’avrebbe mai detto che il segreto per far girare i titoli AAA su Linux sarebbe stato, in pratica, fare un po’ di reverse engineering spudorato sulle API di Windows? Se pensate che il gaming su Linux sia rimasto bloccato al periodo in cui riuscivi a far girare solo i vecchi emulatori e qualche titolo indie in pixel art, preparatevi a rimettervi le cuffie perché la situazione sta cambiando drasticamente.

La notizia che sta girando su Hacker News è una vera bomba per chiunque abbia una GPU che non sia un reperto archeologico: le prestazioni stanno aumentando perché, invece di far fare tutto il lavoro pesante a strati di traduzione complicatissimi, si sta lavorando per portare le API di Windows direttamente dentro le feature del kernel Linux. In pratica, stiamo smontando il muro della compatibilità pezzo per pezzo, portando la logica di Windows dove la gestione è più bassa, più veloce e meno soggetta a quel lag che ti fa perdere la partita proprio quando stai per fare il boss finale.

Dal punto di vista tecnico, la cosa è geniale nella sua semplicità. Non stiamo parlando di ‘fuffa’ da marketing per convincere i gamer a mollare Windows, ma di un approccio da vero hacker: se un software si aspetta che il sistema faccia X, noi modifichiamo il sistema affinché X sia nativo e ultra-efficiente. È la stessa mentalità che usiamo quando modifichiamo il firmware di un vecchio router o quando ottimizziamo un G-code per una CNC fatta in casa: meno strati di astrazione ci sono, meno overhead abbiamo, più il risultato è preciso.

Certo, c’è chi storcerà il naso parlando di ‘inquinare’ la purezza del kernel con logiche nate per l’ecosistema Microsoft. Ma onestamente, chi se ne frega della purezza ideologica se poi i frame per secondo raddoppiano? La nostra priorità è far girare la roba, far girare bene e senza che il sistema crashi ogni volta che provi ad aprire un gioco moderno.

Per noi che passiamo le notti a compilare kernel custom o a ottimizzare workflow su Blender, questo significa che il desktop Linux sta diventando una piattaforma di gaming seria, non solo un posto dove far girare terminali e script Python. Se questo trend continua, l’idea di dover avere una partizione Windows solo per ‘quel gioco che non va su altro’ diventerà un ricordo sbiadito come i floppy disk. Il futuro è open, è veloce e, soprattutto, è decisamente meno controllato dai big del software proprietario.

Source: Linux gaming is faster because Windows APIs are becoming Linux kernel features

State ancora dormendo sonni tranquilli mentre aspettate che la vostra stampante 3D finisca l’estrusione di quel pezzo per il nuovo progetto CNC? Forse è il caso di rimettere in discussione la propria fiducia nel kernel.

È emersa una notizia che ha fatto saltare sulla sedia i soliti sospetti di Hacker News: una nuova vulnerabilità di tipo Local Privilege Escalation (LPE) battezzata «Dirtyfrag». Per chi non mastica l’inglese dei comunicati di sicurezza, significa che se qualcuno riesce a ottenere un accesso limitato al tuo sistema, ha le mani in pasta con una facilità quasi irritante. Non parliamo di una falla che richiede l’intervento di un team di hacker della NASA; parliamo di qualcosa che può permettere a un utente non privilegiato di elevare i propri permessi e diventare, con tutta la comodità del mondo, il root.

La cosa che mi fa storcere il naso non è tanto l’esistenza di un bug — perché, diciamocelo, il kernel Linux è un mostro di complessità e i bug sono parte del pacchetto, un po’ come il rumore di fondo di una vecchia ventola di un PC anni ’90 — ma la natura ‘universale’ che questa vulnerabilità sembra suggerire. Se la falla è davvero così pervasiva, l’idea di avere un sistema sicuro si scontra con la realtà di un codice che cresce in modo esponenziale, sempre più stratificato e difficile da pattumare.

Per noi che amiamo smanettare, che tiriamo su server per far girare bot di automazione, playground per IA o repository di codice, la questione è seria. Non siamo i classici utenti ‘corporate’ che cliccano ‘OK’ su ogni aggiornamento senza leggere. Noi vogliamo sapere cosa sta succedendo sotto il cofano. Una LPE è come trovare la porta della garanzia aperta sul tuo setup più prezioso: per un maker, il rischio non è solo il furto di dati, ma l’integrità stessa dei propri progetti e dei propri ambienti di sviluppo.

Cosa dovremmo fare? Niente panico da fine del mondo, ma è il momento di smettere di ignorare quegli alert di sicurezza che abbiamo configurato mesi fa. Se avete macchine Linux che girano da tempo senza aggiornamenti (perché sì, lo sappiamo tutti che ‘funziona, non toccarlo’), fate un check immediato. Verificate le patch disponibili e, se possibile, limitate l’esposizione dei servizi verso l’esterno.

In definitiva, Dirtyfrag ci ricorda che la sicurezza non è un prodotto che si compra una volta e si dimentica, ma un processo di manutenzione continua, proprio come lubrificare i motori passo-passo di una CNC o pulire i filtri di una stampante. Meno hype, più patch.

Source: Dirtyfrag: Universal Linux LPE

Chi l’avrebbe mai detto che il cuore pulsante di Internet sia gestito con lo stesso livello di coordinazione di un gruppo WhatsApp di genitori durante una gita scolastica?

È uscito un report piuttosto pepato su Openwall che mette in luce un problema strutturale che definire ‘disagio’ è un eufemissimo. In pratica, quando vengono scoperte delle vulnerabilità critiche nel kernel Linux, non c’è un sistema di allerta rapida o un ‘heads-up’ coordinato verso le principali distribuzioni. In breve: scoprono il bug, si parla del problema, e i maintainer delle distro si ritrovano a gestire l’emergenza quando ormai il codice è già pubblico e gli exploit sono pronti all’uso.

Per chi vive di automazione, server domestici o progetti di edge computing, la cosa è decisamente poco divertente. Immaginate di aver appena finito di configurare il vostro nuovo cluster Kubernetes o il vostro server NAS custom per lo streaming di vecchi titoli arcade, e svegliarvi con la notizia che il kernel che state usando ha un buco che permette l’escalation dei privilegi. E la cosa peggiore? Non c’è stata una fase di ‘pre-avviso’ per permettere alle distro di preparare le patch in silenzio.

Dal mio piccolo angolo di mondo, dove passo le notti a far girare script Python per ottimizzare il rendering di modelli Blender o a debuggare firmware di vecchi controller, trovo che questa mancanza di comunicazione sia un classico esempio di come l’ecosistema Open Source, pur essendo incredibilmente potente, soffra ancora di una frammentazione pericolosa sul fronte della sicurezza reattiva. Non è colpa dei singoli developer (che fanno un lavoro eroico), ma della mancanza di un protocollo di disclosure che protegga chi ‘subisce’ l’aggiornamento.

Cosa significa per noi smanettoni? Significa che non possiamo permetterci il lusso di ignorare gli update. Se usate Linux per compiti critici, la vostra unica difesa è l’iper-vigilanza. Non aspettate che la notizia finisca nel feed di qualche tech-influencer su X. Controllate i mailing list, seguite i repository ufficiali e, se potete, usate distribuzioni che hanno una policy di sicurezza più strutturata.

In un mondo dove l’hype per l’AI ci distrae costantemente da ciò che conta davvero (la stabilità del nostro stack software), ricordiamoci che la sicurezza non è un feature che si aggiunge con un plugin, ma un processo che richiede trasparenza. E finché non vedremo un sistema di allerta più serio, l’unica soluzione è restare con le dita sempre pronte sulla tastiera, pronti a compilare il prossimo kernel patchato prima che qualcuno decida di testare un exploit sul nostro server.

Source: For Linux kernel vulnerabilities, there is no heads-up to distributions

Mettete pure in pausa quel rendering di Blender o quel debug su Godot, perché c’è una notizia che fa tremare le fondamenta del vostro stack Linux.

Non è il solito bug che richiede un’exploit complicatissima o un accesso di rete pregresso. Parliamo di ‘Copy Fail’, una vulnerabilità che sta facendo discutere su Hacker News e che colpisce quasi tutto ciò che è mainstream. Se il vostro kernel è stato compilato tra il 2017 e l’ultimo patch, siete potenzialmente nel mirino. E la cosa peggiore? Non serve nemmeno avere i permessi di debugging o configurazioni particolari. Basta che il kernel abbia l’API crypto (AF_ALG) abilitata, il che, per dispetto della nostra tranquillità, è la configurazione standard su quasi tutte le distro che usiamo quotidianamente.

Per chi mastica Linux, la lista dei sospetti è lunga: Ubuntu, Amazon Linux, RHEL, SUSE… ma non fermiamoci qui. Se usate Arch, Debian, Fedora o anche i sistemi embedded che state smanettando per far funzionare qualche macchinario CNC fatto in casa, siete nello stesso baratro. Il problema è che un semplice utente locale, uno di quelli con i permessi minimi, può scalare i privilegi e diventare root senza troppi complimenti.

Analizziamo la cosa con la freddezza di chi ha visto troppi server esplodere. Se gestite macchine multi-tenant, server di build come GitHub Actions self-hosted o runner Jenkins, la situazione è da codice rosso. In un ambiente containerizzato (Kubernetes, Docker e compagnia bella), un attaccante potrebbe saltare da un pod all’altro, compromettendo l’intero nodo. È il classico scenario da incubo in cui l’isolamento dei tenant diventa una barriera di carta velina.

Per noi maker e smanettoni che usiamo Linux sul laptop personale, il rischio è leggermente più basso perché, beh, siete quasi sempre gli unici utenti. Tuttavia, se per caso vi capita di far girare script di terze parti o servizi web esposti, l’exploit potrebbe essere l’ultimo tassello per una compromissione totale.

Il mio consiglio? Niente panico da primo piano, ma niente nemmeno l’indifferenza di chi non ha mai letto un man page. Aggiornate i kernel. Subito. Non aspettate che la vostra workstation diventi un gateway per un ransomware o che il vostro server di automazione inizi a minare crypto per conto di sconosciuti. La patch è uscita, quindi non c’è scusa che tenga. Fate il lavoro sporco, patchate tutto e tornate pure a modellare i vostri asset 3D o a scrivere codice. Ma fatelo in sicurezza.

Source: Copy Fail

Lo sai qual è la sensazione quando trovi un bug che ti fa perdere ore di sonno? Bene, immagina di scoprire che esisteva già una soluzione, nascosta nel codice del kernel da anni. È quello che è successo agli sviluppatori di OpenJDK.

La storia inizia con una chiamata innocua: ThreadMXBean.getCurrentThreadUserTime(). Niente di straordinario, giusto? Eppure, dietro questo metodo apparentemente banale si nascondeva un problema da 400 volte più lento del necessario. La colpa? Un approccio obsoleto che leggeva file di stato del processo (/proc) come se fossimo ancora negli anni ’90.

Ecco dove entra in scena il nostro eroe: un sviluppatore ha scavato nel kernel Linux e ha scoperto che esisteva un modo molto più efficiente. Basta costruire manualmente un clock_id specifico, evitando l’inutile parsing di file di testo. Risultato? Un miglioramento da 400 volte in alcuni casi, senza aggiungere neanche una riga di nuovo codice.

Come smanettone, trovo questa storia affascinante per diversi motivi:

1. **Il potere del reverse engineering**: A volte la soluzione migliore non è scrivere nuovo codice, ma capire meglio quello che già esiste.

2. **L’importanza delle API**: Quello che sembra un dettaglio tecnico può avere impatti enormi sulle performance. Chi ha detto che le API sono solo per i puristi?

3. **La resistenza al cambiamento**: Perché aspettare 10 anni per risolvere un problema che poteva essere evitato? La risposta è nella burocrazia del software.

Certo, non tutto è perfetto. Costruire manualmente un clock_id significa fare ipotesi sul kernel Linux. E se domani cambia qualcosa? E se un altro sistema operativo ha un comportamento diverso? Sono domande legittime, ma il guadagno è così grande che vale la pena di correre il rischio.

Per noi appassionati di metterci le mani in pasta, la lezione è chiara: a volte la soluzione è già lì, nascosta tra le righe del kernel. Basta saperla trovare. E se anche tu hai un problema che sembra senza soluzione, magari vale la pena dare un’occhiata più da vicino.

PS: Se usi Java 26, questa ottimizzazione ti arriverà gratis. Ma se vuoi approfittarne prima, sappi che il codice è open source. Buon hacking!

Source: A 40-line fix eliminated a 400x performance gap