Dirtycow gira (da lib-c a root) bene ma si blocca al riavvio

TL; DR si è verificata una condizione di competizione che ha portato il bit di writeback a essere impostato su una pagina immediatamente dopo aver atteso che il bit venisse disattivato, inciampando in un controllo di integrità che ha bloccato il kernel.

Sfortunatamente, non posso rispondere alle tue due domande, dal momento che richiedono molto più debugging, ma posso fare chiarezza sul perché questo si sta verificando, il che può essere d'aiuto. Sembra probabile che questo venga attivato quando il kernel sincronizza i filesystem giusto prima del riavvio. Puoi testare questo eseguendo sync te stesso (o facendo una sincronizzazione di emergenza, cioè sysrq-s) per vedere se questo attiva questo comportamento, o riavviando senza prima la sincronizzazione, cioè con reboot -n e vedendo se non si verifica alcun arresto anomalo.

Il problema stesso

Sembra che provenga da un BUG() in fs/ext4/inode.c:mpage_prepare_extent_to_map . La macro BUG() è usata per oops intenzionalmente il kernel generando un'eccezione di istruzione illegale. È inteso per essere utilizzato come controllo di integrità runtime. La macro BUG() solleva incondizionatamente un'eccezione, mentre BUG_ON() prende un singolo argomento e solleva l'eccezione se l'argomento valuta true.

Nel log che hai pubblicato, viene attivato BUG_ON(PageWriteback(page)) , il cui argomento è valutato su true. Ciò significa che, a questo punto del codice, PageWriteback(page) dovrebbe sempre restituire false. Questo è usato per prevenire un writeout simultaneo della stessa pagina. Le righe pertinenti sono:

wait_on_page_writeback(page);
BUG_ON(PageWriteback(page));

La prima riga è una funzione definita in include/linux/pagemap.h :

/*
 * Wait for a page to complete writeback
 */
static inline void wait_on_page_writeback(struct page *page)
{
    if (PageWriteback(page))
        wait_on_page_bit(page, PG_writeback);
}

La seconda riga proviene da include/linux/page-flags.h :

#define TESTPAGEFLAG(uname, lname, policy)                             \
    static __always_inline int Page##uname(struct page *page)          \
    { return test_bit(PG_##lname, &policy(page, 0)->flags); }

La radice del problema

Sfortunatamente, la ragione esatta per cui ciò si sta verificando non mi è chiara. A giudicare da come funziona l'exploit di DirtyCow, ha senso, poiché sembra ovvio che questo sia il risultato di una condizione di competizione (altrimenti la pagina non dovrebbe riguadagnare improvvisamente il bit di writeback dopo aver atteso che venisse rimossa se non esplicitamente detto a). Vorresti eseguire un debug più approfondito per comprendere completamente il problema. Poiché è probabile che sia una condizione di gara, non avrai molta fortuna con questo solo registro di oops. Dovrai esaminare il codice (non-faulting, così silenzioso) che viene eseguito su un'altra CPU che lo sta attivando.

Posso dire che ha provocato uno dei tre possibili eventi che hanno attivato questo risultato:

• La pagina di destinazione non ha impostato il bit di writeback. Di conseguenza, wait_on_page_writeback() ha funzionato come no-op. In qualche modo, il bit è stato impostato poco dopo la funzione restituita.
• La pagina di destinazione ha impostato il bit di riscrittura. Il wait_on_page_writeback() ha aspettato fino a quando il bit è stato rimosso prima di tornare. In qualche modo, dopo che il bit è stato rimosso, è stato nuovamente impostato.
• La pagina di destinazione ha impostato il bit di riscrittura e si suppone che wait_on_page_writeback() venga restituito solo quando il bit non è stato impostato. In qualche modo, è tornato anche se il bit era ancora impostato.

Indipendentemente da quale di questi è il caso, è stata restituita la funzione wait_on_page_writeback() , ma la pagina ha ancora o rapidamente recuperato il bit di writeback. Questo è stato rilevato da un controllo di integrità di BUG_ON() perché non dovrebbe mai accadere.

Come il registro di oops rivela questo

Invece di dire semplicemente "questo è quello che è", ti spiegherò come l'ho raccolto dal log che hai postato.

[  388.077362] kernel BUG at /build/linux-03BQvT/linux-3.13.0/fs/ext4/inode.c:2420!
[  388.077497] invalid opcode: 0000 [#1] SMP 

Questo mi dice che il problema era un controllo di integrità relativo a BUG() . La prima riga lo chiama esplicitamente, e indica anche la riga esatta e il file sorgente di interesse. Anche la seconda riga lo rafforza implicitamente, poiché BUG() e le funzioni correlate eseguono l'istruzione ud2 , che genera un errore opcode (istruzioni) non valido.

[  388.078878] RIP: 0010:[<ffffffff81241298>]  [<ffffffff81241298>] mpage_prepare_extent_to_map+0x2b8/0x2c0

Il RIP è il puntatore dell'istruzione (chiamato EIP e IP su processori a 32 e 16 bit, rispettivamente). Punterà alla posizione dell'istruzione attualmente in esecuzione, che sarà all'interno della funzione corrente. Poiché ho una versione del kernel diversa e non volevo cercare la tua versione esatta, sono stato in grado di passare alla funzione mpage_prepare_extent_to_map() in fs/ext4/inode.c e cercare qualcosa come BUG() o BUG_ON() , così come qualsiasi linea appena sopra di essa. Cercando i file in cui sono state definite le due funzioni wait_on_page_writeback() e PageWriteback() hanno rivelato il loro scopo. Nello specifico, queste garanzie fornite dalle due righe del codice sorgente si sono rivelate errate:

• Dopo il ritorno di wait_on_page_writeback(page) , page non avrà il bit di writeback impostato.
• PageWriteback(page) restituirà false, poiché page non avrà il bit di writeback impostato.
• Pertanto, BUG_ON(PageWriteback(page)) non verrà attivato.

Poiché il BUG_ON() è stato attivato, il problema diventa ovvio.

what do the crashes depend on? Is it the hardware? The kernel version? The exploit?

Per ottenere informazioni sull'arresto del kernel dovresti usare kdump-tools , un tuto completo può essere trovato qui

How can I fix the kernel crash on reboot while I'm using the lib-c to root exploit?

Dovresti avviare da un live cd / usb di linux, creare l'ambiente chroot e quindi reinstallare l'immagine di linux .