Dirtycow ejecuta (lib-c a root) bien pero se bloquea al reiniciar

TL; DR se produjo una condición de carrera que hizo que el bit de reescritura se estableciera en una página inmediatamente después de esperar a que se desarmara el bit, tropezando con una comprobación de validez que bloqueó el kernel.

Desafortunadamente, no puedo responder a sus dos preguntas, ya que requieren mucha más depuración, pero puedo aclarar por qué ocurre esto, lo que puede ayudar. Parece probable que esto se active cuando el kernel sincroniza los sistemas de archivos justo antes de reiniciar. Puede probar esto ejecutando sync usted mismo (o realizando una sincronización de emergencia, es decir, sysrq-s) para ver si eso provoca este comportamiento, o reiniciando sin sincronizar primero, es decir, con reboot -n y ver si no se produce un bloqueo.

El problema en sí mismo

Esto parece provenir de un BUG() en fs/ext4/inode.c:mpage_prepare_extent_to_map . La macro BUG() se usa para saltar intencionalmente el núcleo generando una excepción de instrucción ilegal. Está destinado a ser utilizado como un control de sanidad en tiempo de ejecución. La macro BUG() incondicionalmente genera una excepción, mientras que BUG_ON() toma un solo argumento y genera la excepción si el argumento se evalúa como verdadero.

En el registro que publicaste, se activa BUG_ON(PageWriteback(page)) , lo que significa que su argumento se evaluó como verdadero. Esto significa que, en este punto del código, PageWriteback(page) siempre debe devolver false. Esto se utiliza para evitar una escritura simultánea de la misma página. Las líneas relevantes son:

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

La primera línea es una función definida en 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 segunda línea proviene de 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 raíz del problema

Desafortunadamente, la razón exacta por la que esto ocurre no me queda clara. A juzgar por cómo funciona el exploit de DirtyCow, tiene sentido, ya que parece obvio que esto es el resultado de una condición de carrera (de lo contrario, la página no debería recuperar repentinamente el bit de reescritura después de esperar a que se elimine, a menos que se indique explícitamente). Desearía realizar una depuración más exhaustiva para comprender el problema completamente. Como es probable que se trate de una condición de carrera, no tendrás mucha suerte con solo este registro de Oops. Tendrá que mirar el código (sin fallas, tan silencioso) que se está ejecutando en otra CPU que está activando esto.

Puedo decir que resultó en uno de los tres eventos posibles que desencadenaron este resultado:

• La página de destino no tenía el bit de reescritura establecido. Como resultado, wait_on_page_writeback() actuó como un no-op. De alguna manera, el bit se estableció poco después de que se devolvió la función.
• La página de destino tenía el bit de reescritura establecido. El wait_on_page_writeback() esperó hasta que se eliminó el bit antes de regresar. De alguna manera, después de que se eliminó el bit, se estableció de nuevo.
• La página de destino tenía el bit de reescritura establecido, y se suponía que wait_on_page_writeback() regresaba solo cuando el bit estaba desactivado. De alguna manera, volvió a pesar de que el bit aún estaba configurado.

Independientemente de cuál de estos sea el caso, la función wait_on_page_writeback() regresó, sin embargo, la página aún tenía o recuperó rápidamente el bit de reescritura. Esto fue detectado por un BUG_ON() sanity check porque nunca debería suceder.

Cómo el registro de Oops revela esto

En lugar de simplemente decir "esto es lo que es", explicaré cómo recopilé esto del registro que publicaste.

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

Esto me dice que el problema fue una comprobación de validez relacionada con BUG() . La primera línea lo señala explícitamente, e incluso apunta a la línea exacta y al archivo fuente de interés. La segunda línea también refuerza esto implícitamente, porque BUG() y las funciones relacionadas ejecutan la instrucción ud2 , lo que resulta en un error de opcode (instrucción) no válido.

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

El RIP es el puntero de instrucción (llamado EIP y IP en los procesadores de 32 y 16 bits, respectivamente). Apuntará a la ubicación de la instrucción que se está ejecutando actualmente, que estará dentro de la función actual. Como tengo una versión del kernel diferente y no quería buscar su versión exacta, pude ir a la función mpage_prepare_extent_to_map() en fs/ext4/inode.c y buscar algo como BUG() o BUG_ON() , así como cualquier línea justo por encima de ella. Buscar los archivos donde se definen las dos funciones wait_on_page_writeback() y PageWriteback() reveló su propósito. Específicamente, estas garantías proporcionadas por las dos líneas de código fuente resultaron ser incorrectas:

• Después de que wait_on_page_writeback(page) devuelva, page no tendrá el bit de reescritura establecido.
• PageWriteback(page) devolverá false, ya que page no tendrá el bit de reescritura establecido.
• Por lo tanto, BUG_ON(PageWriteback(page)) no se activará.

Debido a que se activó BUG_ON() , el problema se vuelve obvio.

  

¿De qué dependen los choques? ¿Es el hardware? ¿La versión del kernel? ¿El exploit?

Para obtener información sobre el bloqueo del kernel, debe utilizar kdump-tools , se puede encontrar un tuto completo aquí

  

¿Cómo puedo corregir el bloqueo del kernel al reiniciar mientras estoy usando lib-c para root exploit?

Debería arrancar desde un Linux live cd / usb, cree su entorno chroot y luego reinstale linux-image .