The July kernel respin: reboot, and mind your out-of-tree modules
Canonical shipped a batch of Linux kernel security fixes this month, and LWN flagged three stable kernel updates landing upstream in the same window. None of this is dramatic. It is the ordinary heartbeat of running Linux under a mail stack — but "ordinary" still means a reboot, and there are two details worth reading before you schedule one.
What actually shipped
There are two notices that matter if you run Ubuntu. USN-8490-1 covers the generic kernel and moves 25.10 (questing) and the 24.04 HWE/OEM lines to 6.17.0-40.40. USN-8490-2 is the real-time respin of the same body of fixes, landing at 6.17.0-1017.19 (and ~24.04.1 for Noble under Ubuntu Pro). Same story, different flavour: if you deliberately run the real-time kernel you already know it, and everyone else wants the generic notice.
The fix list is long and spread across a lot of subsystems — ARM64, the block layer, NVMe and SCSI, ext4, Netfilter, IPv4/IPv6, Multipath TCP, and more. Canonical's summary is the usual careful phrasing: an attacker "could possibly use these to compromise the system." No CVE numbers or severity ratings came through in what I was given, so I'm not going to assign a threat level the source didn't. Treat it as a normal stable roll-up: apply it, don't panic about it.
Two things that touch a mail box specifically
First, the fix list includes the NFS server daemon and the SMB network file system. If your mail spool, your Dovecot maildirs, or your Zimbra store live on network storage, those are exactly the code paths you lean on all day. That's not a reason to rush a hotfix at 2am — it's a reason to not put this patch off for a month "because it's just a kernel bump." The kernel that mounts your mail is in scope.
Second, and this is the one that bites people: Canonical warns of an unavoidable ABI change, which means a new version number and any third-party kernel modules recompiled and reinstalled. On a plain mail server that's usually a non-event, because the standard metapackages (linux-generic and friends) pull the rebuild through for you. But if you've got out-of-tree modules — a proprietary NIC driver, ZFS on some boxes, a hypervisor guest module — those are the things that quietly fail to load after the reboot. Check what you've compiled by hand before you cycle the machine, not after.
The reboot is the whole job
A kernel update you haven't rebooted into is a kernel update you haven't applied. That's the operational reality here: Postfix and Dovecot come back cleanly on boot, but you still want a maintenance window rather than a surprise. Confirm the machine actually comes up on the new version afterward, and confirm your queue drains and your listeners are bound before you walk away.
One housekeeping note: the metadata on these notices carried mixed publication dates (mid-July on the feed, an earlier date inside one page), so if you're reconciling against your own patch log, trust the version numbers over the timestamps.
Sources
Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.
More about the author →Was this article helpful?
Tap a star — no sign-in needed.
Be the first to rate this article.
Related guides
The AI Kernel Exploit Got the Headline; These Patches Got Shipped
Two things landed on the same day, 28 July 2026, and it's worth being clear about which one you can act on.
NTFS-3G Gets a Pile of Overflows — But Ask Where You Actually Mount NTFS
Debian shipped DSA-6389-1 for ntfs-3g on 15 July, and Ubuntu followed with USN-8554-1 the next day. Between them they close a batch of nine CVEs: seven heap buffer overflows (CVE-2026-42616, 42617, 42618, 46569, 46570, 46572 and 56135) and two out-of-bounds reads (CVE-2026-46571 and 56136). The overflows can lead to arbitrary code execution; the reads can leak memory contents.
The OpenSSL Memory Leak With No CVE to Patch Against
Okta's Red Team gave this one a name, HollowByte, and named things get attention. What deserves the attention here isn't the trick — it's the paperwork, or rather the lack of it.
The SCTP Use-After-Free You Probably Don't Run — But Might Load
A use-after-free landed on oss-security this week as CVE-2026-64564 , in the Linux kernel's SCTP code — specifically the ASCONF transport handling. The advisory and a follow-up describe it as local privilege escalation and container escape. Those two phrases are what make people forward a CVE to their whole team on a Friday, so it's worth stopping to ask what it actually means for the machines this blog is about: Postfix relays, Dovecot backends, Zimbra boxes, iRedMail stacks.