Se o kernel não é uma reescrita completa (com nomes de função alterados etc, reordenação de parâmetros passados para funções), você pode analisar os binários do kernel original e do kernel corrigido, e ver quais funções foram alteradas.
Depois, você sobrescreve o início de uma rotina alterada para ir para uma versão alterada da rotina que você carregou na memória. Isso é feito enquanto nenhum outro processo está sendo executado.
O artigo da Wikipédia sobre ksplice explica isso mais detalhadamente de uma maneira compreensível.
Você pode, claro, tentar programar um patch e criar pequenos patches (com algumas linhas de código de máquina, em vez de funções completas). Esses patches menores exigem que você salte de volta na rotina original, em vez de apenas retornar da chamada de função corrigida.
Corrigir o menu grub para ter um novo número de versão é fácil comparado à análise e correção dos binários do kernel. Esse menu é apenas texto. Mas a ideia é que você nunca verá o menu grub após a primeira inicialização de qualquer maneira.
Este pode ser um novo recurso no Red Hat e no Open SuSE, mas não foi inventado há apenas um ano, por exemplo, O ksplice começou a consertar os kernels em execução em 2008. O conceito de consertar um programa (não necessariamente o kernel do Linux) na memória é muito mais antigo. Eu usei patching de programas na memória com base na análise manual eu mesmo em 1984 (remendo o código de máquina do 6502), e eu certamente não tive a ideia de fazer isso eu mesmo naquela época.