Is it possible for a virus of any kind to be installed inside Linux swap partition? If so, could it be transferred to the system even after formatting the Linux partition only and reinstalling the OS (without formatting the swap area)?

  • I am not a linux pro, but doesn't swap have limited R/W capability? I think it depends on what is actually the malicious intent of the virus, Should just sit in the swap and do nothing even after reinstalling the OS (think the swap has to be mapped after reinstall of OS yes?). Dec 23, 2015 at 20:47
  • 3
    I don't think so. AFAIK when the OS boots it treats the swap area as unallocated memory. It only uses swap space when it writes to disk, and doesn't just start reading from it. It maps out the swap space in memory, not disk, so the contents of the disk only contain "active memory" after it's written to. Dec 23, 2015 at 20:52
  • That's another reason to use an encrypted swap partition or file.
    – ott--
    Dec 23, 2015 at 22:31
  • A virus could be in memory and swapped out to the swap file. However, it won't cause an infection after re-install. Maybe re-flash your bios and clear sectors,if you have MBT 1-63 a nice hiding spot for viruses.
    – cybernard
    Dec 24, 2015 at 1:36

2 Answers 2


It's possible but it requires a roundabout way, and it would take rare circumstances to make it useful.

When Linux boots, it treats the swap area as unallocated space. It isn't going to read back what was already there, only what it wrote. So while you could put malicious software there, it's never going to be loaded into memory, let alone executed.

The one exception is recovering from hibernation. When the Linux kernel boots, it can be told to treat a swap partition as a potential hibernation image. If the swap partition has a valid (non-cryptographic) signature, then Linux loads data from the swap partition into memory, including kernel data and code. This could include malware or more generally a backdoor (e.g. a process image of a shell running as root and listening on a network port).

As others have already remarked, the question in this case is: if the attacker could write to the hibernation image, what prevented them from writing to the root partition or the boot partition? In most configurations, they're on the same physical device, and they can only be accessed directly by someone who already has full control (root) over the system in the first place.

In the reinstallation scenario, where a compromised system was wiped by reinstalling, the swap is a potential reinfection vector. However, all the installers I remember seeing reformat the swap area during installation, so if you do a normal installation, this isn't a concern. (There may well be other ways for malware to persist, by infecting a hardware component that has its own flash memory, but that's another question.) On the other hand, if you recover the system partition from a full-partition backup, then malware could be staying behind. If you have a system recovery procedure, make sure that beyond recovering the system files and data, it includes steps to reinstall the bootloader and reformat the swap (i.e. run mkswap).

Another scenario where swap could be an infection vector is an evil maid attack. A protection against this attack is sign the bootloader and the system (kernel and all security-relevant system files), with a verification chain at boot time starting in hardware (e.g. on a PC, with a TPM). But if the kernel and bootloader are configured to support hibernation, and the swap image is not signed, then the swap becomes a possible attack vector. (Note that the relevant property is that it's signed, not encrypted, although even unauthenticated encryption can make it difficult for the attacker to inject malware that does something useful.) That would be a misconfiguration. If you want system integrity, you need to make to sure that you've protected all the security-sensitive components.


It is difficult to think of a way to write to the swap partition as Linux doesn't allow you to write to them. The only scenario I can come up with where this may be possible is when the system is coming out of sleep or hibernation and memory has been paged out to the swap file. Prior to restarting Linux, the bootloader or some other boot-time code makes malicious modifications to the swap partion.

Certainly encrypting your swap partition, as suggested in a comment by @ott, would make this more difficult. It may not be impossible as the OS must be able to decrypt the swap partition, but it will likely be much more complex.

The above notwithstanding, I've never heard of such an attack. I suspect the reason is that by the time you are in a position to modify the bootloader, you've pretty much pwned the computer and have no reason to mess around with subtle attacks like this one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.