18
Sarah’s Security Brief: Your Intel CPU runs firmware-level patches called microcode, and they are your first line of defense against hardware-level exploits. Intel just dropped microcode-20260811 fixing eight security advisories today. I am going to show you exactly how to check, install, and verify these updates on Ubuntu, Fedora, and Arch, step by step.
Your processor is not a static piece of silicon. Intel ships firmware updates, called microcode, that patch security holes and fix hardware bugs at the instruction level. These are not optional “nice to have” patches. The Spectre and Meltdown families of vulnerabilities proved that CPU-level flaws can expose your entire system. As someone who has spent years tracking hardware security advisories, I can tell you that keeping your microcode current is one of the simplest and most impactful things you can do for your Linux box.
Today, Intel released microcode-20260811, addressing eight security advisories including CVE-2025-31936 (CVSS 7.0 HIGH) which allows privilege escalation on Xeon 6 processors with Intel TDX. If you are running any Intel processor from 10th Gen Core through the latest Xeon Scalable, this update matters to you.
What Is CPU Microcode and Why Does It Exist
Think of microcode as firmware for your processor’s brain. Every instruction your CPU executes passes through a layer of internal logic, and microcode controls that logic. When Intel discovers a bug in how a particular instruction behaves, or when a security researcher finds a way to exploit the execution pipeline, Intel writes a microcode patch that changes the processor’s behavior without requiring a physical recall.
Here is the critical detail that most beginners miss: microcode is volatile. It lives in internal CPU registers that are wiped clean every time you power off or reboot your machine. This means your operating system must reload the microcode from disk every single time it boots. The kernel reads the microcode files from /lib/firmware/intel-ucode/, packages them into the initramfs, and applies them before your root filesystem even mounts. Without this early loading, your CPU runs whatever default microcode was burned in at the factory.
Pro Tip: Run dmesg | grep microcode after every reboot to confirm your kernel loaded updated microcode. If you see “Updated early from” in the output, you are protected.
How to Check Your Current Microcode Version on Linux
Before updating anything, you need to know what version your CPU is currently running. This tells you whether an update is already applied or if you are running stale firmware. I always start here because it gives me a baseline before touching anything on the system.
Check the Running Microcode Revision
The simplest way to see your current microcode is reading the CPU information directly from the kernel:
fosslinux@ubuntu:~$ grep microcode /proc/cpuinfo | sort | uniq microcode : 0x000000f4
The hex value (in this example, 0x000000f4) is your current microcode revision. A higher number generally means a newer update, though Intel does not publish a public mapping of revision numbers to release dates.
Check the Kernel Boot Log
The kernel logs microcode loading during boot. Use journalctl to see the history:
fosslinux@ubuntu:~$ journalctl -k --grep='microcode:' --no-pager | tail -5 Aug 11 19:00:01 ubuntu kernel: microcode: Current revision: 0x000000f4 Aug 11 19:00:01 ubuntu kernel: microcode: Updated early from: 0x000000f0
The “Updated early from” line confirms the kernel replaced the old microcode (0xf0) with the newer version (0xf4) during boot. If you only see “Current revision” without “Updated early,” either your BIOS already loaded the latest microcode, or no update is available for your specific CPU model.
Insight: The “0xffffffff” value you sometimes see in virtual machines is a VMware artifact. VMware does not expose real microcode revision numbers to guests because the hypervisor manages microcode loading on the host. If you see this in a VM, that is expected behavior.
Check What Package Is Installed
Each distribution packages Intel microcode differently. Here is how to check which package you have:
fosslinux@ubuntu:~$ dpkg -s intel-microcode | grep Version Version: 3.20260210.1ubuntu2
This tells you which Intel microcode release your distribution currently ships. Ubuntu 26.04 LTS currently has the February 2026 release. The August 2026 update (microcode-20260811) will land in the repositories once Canonical publishes it to the security pocket.
How to Update Intel Microcode on Ubuntu and Debian
Ubuntu and Debian use the intel-microcode package, maintained by the Debian microcode team. The package installs firmware files to /lib/firmware/intel-ucode/ and automatically includes them in the initramfs during installation. I have been running this on my production servers for years, and it is the smoothest microcode update experience of any distro.
Install or Update Microcode
fosslinux@ubuntu:~$ sudo apt update fosslinux@ubuntu:~$ sudo apt install intel-microcode Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: intel-microcode 0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded. Need to get 2,847 kB of archives. After this operation, 8,388 kB of additional disk space will be used. Get:1 resolute/main amd64 intel-microcode amd64 3.20260210.1ubuntu2 [2,847 kB] Fetched 2,847 kB in 1s (2,847 kB/s) ... Setting up intel-microcode (3.20260210.1ubuntu2) ... update-initramfs: Generating /boot/initrd.img-7.0.0-29-generic Processing triggers for man-db (2.13.0-1) ...
Notice the last line: update-initramfs: Generating /boot/initrd.img-7.0.0-29-generic. Ubuntu automatically rebuilds the initramfs with the new microcode. You do not need to run any additional commands.
Verify the Update
fosslinux@ubuntu:~$ lsinitramfs /boot/initrd.img-$(uname -r) | grep microcode kernel/x86/microcode kernel/x86/microcode/GenuineIntel.bin
The presence of GenuineIntel.bin in the initramfs confirms the microcode is packaged and ready to load on next boot. Reboot your system to activate the update.
Why It Matters: Ubuntu’s update-initramfs hook runs automatically when you install or upgrade the intel-microcode package. This is not the case on all distributions. Arch and Fedora require you to manually rebuild the initramfs after installing microcode updates, which is one of the most common mistakes beginners make.
How to Update Intel Microcode on Fedora
Fedora takes a different approach from Ubuntu. Instead of a dedicated microcode package, Fedora bundles Intel and AMD microcode into the linux-firmware package, with microcode_ctl as the companion utility. When I first moved my lab machines to Fedora, this difference caught me off guard because the package names are completely different from what Debian-based users expect.
Install or Update Microcode
fosslinux@fedora:~$ sudo dnf install microcode_ctl linux-firmware Last metadata expiration check: 0:12:34 ago on Tue 11 Aug 2026 06:45:00 PM EDT. Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Installing: microcode_ctl x86_64 2.1-74.fc44 updates 98 k linux-firmware noarch 20260519-1.fc44 updates 267 M Total download size: 267 M Installed size: 892 M ... Complete!
Rebuild the Initramfs
This is where Fedora differs from Ubuntu. You must manually trigger dracut to rebuild the initramfs with the new microcode files:
fosslinux@fedora:~$ sudo dracut --force
Without this step, the updated microcode sits on disk but never gets loaded into the initramfs. Your next boot will still use the old microcode. I have seen this mistake cause false confidence in security audits: the package is “updated” but the running kernel still loads stale firmware. This is the single most common mistake Fedora users make after updating firmware packages.
Verify the Update
fosslinux@fedora:~$ rpm -q microcode_ctl linux-firmware microcode_ctl-2.1-74.fc44.x86_64 linux-firmware-20260519-1.fc44.noarch fosslinux@fedora:~$ journalctl -k --grep='microcode:' --no-pager | tail -3 Aug 11 19:00:01 fedora kernel: microcode: Current revision: 0x000000f4 Aug 11 19:00:01 fedora kernel: microcode: Updated early from: 0x000000f0
Worth Knowing: Fedora Silverblue and other immutable variants use rpm-ostree instead of dnf. The microcode packages are the same, but the update mechanism differs. On Silverblue, run rpm-ostree upgrade and reboot. The initramfs rebuild happens automatically during the ostree transaction.
How to Update Intel Microcode on Arch Linux
Arch Linux uses the intel-ucode package, which integrates with mkinitcpio to prepend microcode into the initramfs. Arch gives you the most control over the process, but also requires the most manual steps. If you are coming from Ubuntu, read our complete Arch Linux installation guide first to understand how mkinitcpio works.
Install Microcode
fosslinux@arch:~$ sudo pacman -S intel-ucode resolving dependencies... looking for conflicting packages... Packages (1) intel-ucode-20260512-1 Total Download Size: 1.87 MiB Total Installed Size: 14.21 MiB :: Proceed with installation? [Y/n] y :: Retrieving packages... intel-ucode-20260512-1-x86_64.pkg.tar.zst 1.9 MiB 5.2 MiB/s 00:00 ... (1/1) installing intel-ucode [#####] 100%
Verify the mkinitcpio Hook
Before rebuilding, confirm that the microcode hook is present in your mkinitcpio configuration:
fosslinux@arch:~$ grep -E '^HOOKS' /etc/mkinitcpio.conf HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block filesystems fsck)
The microcode hook must appear in the HOOKS array. If it is missing, add it before rebuilding. Without this hook, mkinitcpio will not include the microcode files in the initramfs.
Rebuild the Initramfs
fosslinux@arch:~$ sudo mkinitcpio -P ==> Building image from preset: /etc/mkinitcpio.d/preset: 'default' -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf /boot/initramfs-linux.img ==> Starting build: 'default' -> Running build hook: [base] -> Running build hook: [systemd] -> Running build hook: [autodetect] -> Running build hook: [microcode] -> Running build hook: [modconf] -> Running build hook: [kms] -> Running build hook: [keyboard] ... ==> Image generation successful
The output should show -> Running build hook: [microcode] and end with Image generation successful. This confirms the microcode was prepended to the initramfs.
Verify Microcode in Initramfs
fosslinux@arch:~$ lsinitcpio --early /boot/initramfs-linux.img | grep microcode kernel/x86/microcode/ kernel/x86/microcode/GenuineIntel.bin
The presence of GenuineIntel.bin confirms your initramfs contains the Intel microcode. Reboot to activate.
How to Verify Your Microcode Update After Reboot
After rebooting, confirm the update took effect. The two commands below work across all distributions:
fosslinux@ubuntu:~$ journalctl -k --grep='microcode:' --no-pager [sudo] password for fosslinux: Aug 11 19:00:01 ubuntu kernel: microcode: Current revision: 0x000000f4 Aug 11 19:00:01 ubuntu kernel: microcode: Updated early from: 0x000000f0 fosslinux@ubuntu:~$ grep microcode /proc/cpuinfo | sort | uniq microcode : 0x000000f4
If journalctl shows “Updated early from” with a different (lower) revision, your microcode was successfully updated during boot. If you only see “Current revision” with no “Updated early” line, it means either your BIOS already loaded the latest microcode before the kernel ran, or no update is available for your CPU model.
BIOS Updates vs OS Microcode Updates
Intel states clearly that BIOS updates are the preferred method for applying microcode. Here is why: some microcode patches can only be applied from BIOS and are never packaged for OS distribution. BIOS updates also persist across power cycles, while OS-loaded microcode must be reloaded on every boot.
That said, OS updates have a major advantage: speed. When Intel releases a security patch, distribution maintainers can package it within days. BIOS updates from motherboard manufacturers often take weeks or months. For older hardware that no longer receives BIOS updates, the OS microcode package is your only option.
The best practice is to use both. Install the OS microcode package for immediate protection, and apply BIOS updates when they become available from your motherboard manufacturer. I follow this approach on all my personal machines: Ubuntu handles the OS microcode, and I check my motherboard vendor’s support page quarterly for BIOS updates.
AMD Users: A Quick Note
If you are running an AMD processor, the process is nearly identical but uses different package names:
- Ubuntu/Debian:
sudo apt install amd64-microcode - Fedora: Included in the
linux-firmwarepackage (same as Intel) - Arch:
sudo pacman -S amd-ucode
The same initramfs rules apply: Arch requires mkinitcpio -P, Fedora requires dracut --force, and Ubuntu handles it automatically. AMD microcode files are stored in /lib/firmware/amd-ucode/ and the kernel path is /kernel/x86/microcode/AuthenticAMD.bin.
Frequently Asked Questions
How often should I update my CPU microcode?
Intel releases microcode updates on an irregular schedule, typically aligned with security advisory disclosures. You do not need to check manually. If you keep your system updated through your distribution’s regular package updates, you will receive microcode patches automatically. The most important thing is to reboot after installing firmware updates. Microcode only takes effect on boot.
Will updating microcode slow down my computer?
Some early Spectre/Meltdown mitigations caused measurable performance regressions. However, Intel has spent years refining these patches. The performance impact of modern microcode updates is negligible for most workloads. The security benefit far outweighs any theoretical slowdown.
Can I skip the OS update and just use BIOS microcode?
You can, but you should not. BIOS updates from motherboard manufacturers lag behind OS packages by weeks or months. During that gap, your system is vulnerable. The OS microcode package provides faster protection. Use both: OS for speed, BIOS for persistence.
What if my CPU is too old and no microcode update exists?
Check journalctl -k --grep='microcode:' after a reboot. If the kernel does not show an “Updated early” line, it means no microcode update is available for your specific CPU model in the package. This does not necessarily mean your CPU is vulnerable; it may already have the correct microcode from the factory. Check Intel’s security advisory page to verify whether your processor family is affected.
Do I need to update microcode in virtual machines?
Microcode updates belong on the host, not inside guest VMs. If you are running VMware, VirtualBox, or KVM, update the host system’s microcode. The hypervisor handles passing the correct microcode to guests. Running microcode updates inside a guest is redundant and may not even take effect depending on the virtualization layer.
Keeping your CPU microcode current is one of the easiest security wins on Linux. Install the right package for your distribution, rebuild the initramfs where required, reboot, and verify. Your processor silently protects you with every boot. If you are setting up a fresh Debian system, check our post-install hardening guide which covers microcode alongside other essential security steps.