Já que você já executou memtest por um período de tempo suficiente, o suspeito de hardware mais óbvio foi desclassificado. Eu entendo que você tenha notado se a linha
BUG: unable to handle kernel paging request at 0000020000000018
carrega o mesmo ou um endereço diferente a cada vez, certo?
Não consigo ajudá-lo com este relatório, mas posso sugerir que você use Apport para coletar informações sobre suas falhas? Apport é o pacote oficial do Ubuntu para coleta de dados em casos de falhas e bugs, você encontra uma boa Introdução aqui .
Você precisa ativá-lo, (edite como sudo /etc/apport/crashdb.conf, encontre esta linha,
'problem_types': ['Bug', 'Package'],
e adicione um símbolo de hash, # em seu início), e ele produzirá um traço completo da chamada que gerou o travamento. Não precisa se preocupar com o ulimit nas versões mais recentes do Ubuntu, já que o Apport é capaz de contornar sua indicação, mesmo que seja 0.
Em geral, a melhor coisa a fazer é enviar o relatório de falha para o Launchpad; O Apport faz isso automaticamente. Ainda há algumas informações que podem ser úteis até mesmo para o usuário inexperiente. A introdução mencionada acima afirma:
Some fields warrant further details:
SegvAnalysis: when examining a Segmentation Fault (signal 11), Apport attempts to review the exact machine instruction that caused the fault, and checks the program counter, source, and destination addresses, looking for any virtual memory address (VMA) that is outside an allocated range (as reported in the ProcMaps attachment).
SegvReason: a VMA can be read from, written to, or executed. On a SegFault, one of these 3 CPU actions has taken place at a given VMA that either not allocated, or lacks permissions to perform the action. For example:
SegvReason: reading NULL VMA would mean that a NULL pointer was most likely dereferenced while reading a value.
SegvReason: writing unknown VMA would mean that something was attempting to write to the destination of a pointer aimed outside of allocated memory. (This is sometimes a security issue.)
SegvReason: executing writable VMA [stack] would mean that something was causing code on the stack to be executed, but the stack (correctly) lacked execute permissions. (This is almost always a security issue.)
No passado, isso me permitiu identificar um programa com um bug (VirtualBox) que causou as falhas. Após uma limpeza completa e reinstalação, o problema evaporou. Eu só te desejo a mesma sorte.