AlmaLinux 8 kernel fixes land for CVE-2026-17523

AlmaLinux published new AlmaLinux 8 kernel and kernel-rt security updates on August 18, 2026, and the practical reason to care is CVE-2026-17523: a Linux CAN BCM issue described in vendor and vulnerability-tracking sources as a local path to kernel-code execution and privilege escalation. This is not a remote edge-service emergency by itself, but it is exactly the kind of kernel bug that matters on shared hosts, CI workers, developer workstations, jump boxes, virtualization hosts, and any server where a low-privileged account is still inside your threat model.

The update also reminds us of a boring but important operations rule: kernel advisories are only “done” after the fixed kernel is installed and actually running on the machine. Package scanners, update dashboards, and dnf update output are useful, but they do not prove the old kernel is gone from memory. For fleets that run AlmaLinux 8, RHEL-like rebuilds, or mixed enterprise Linux images, this should go into the next patch window with explicit reboot verification.

What changed

LWN’s August 18 security-update index lists AlmaLinux advisory ALSA-2026:55764 for AlmaLinux 8 kernel and ALSA-2026:55765 for AlmaLinux 8 kernel-rt, both dated 2026-08-18. The AlmaLinux announcement mirrored by LWN marks ALSA-2026:55764 as an Important kernel security, bug-fix, and enhancement update for AlmaLinux 8.

The kernel advisory includes multiple fixes, but CVE-2026-17523 is the one I would put at the top of an SRE patch note. In the AlmaLinux announcement text, it is summarized as a can:bcm issue that can lead to arbitrary kernel code execution and privilege escalation. Tenable’s plugin record for the matching AlmaLinux 8 kernel-rt advisory independently lists the same CVE in the fixed set and marks the local check as looking for missing AlmaLinux security updates.

Red Hat’s Bugzilla entry for CVE-2026-17523 ties the issue to the Linux CAN Broadcast Manager path and links the relevant Red Hat product errata for RHSA-2026:55764 and RHSA-2026:55765. SentinelOne’s vulnerability database gives a useful independent technical framing: the affected area is the kernel’s Controller Area Network Broadcast Manager implementation, with exploitation requiring local access and the ability to create CAN BCM sockets.

Why this matters to working engineers

Local privilege escalation bugs are often under-prioritized because they are not exposed directly to the internet. That is usually the wrong mental model. The question is not “can the internet hit this kernel path directly?” The better question is “where do we allow untrusted or semi-trusted code to run?”

That list is longer than most inventories admit. CI runners execute pull-request code. Build hosts unpack dependencies and run test suites. Bastion hosts and admin workstations accumulate shell users. Multi-tenant application boxes sometimes still exist. Internal automation accounts often have more filesystem reach than they should. A local-root kernel bug turns all of those into more serious boundaries.

CVE-2026-17523 is especially worth noticing because it sits in a subsystem many server teams do not think about: CAN networking. CAN is common in automotive, industrial, embedded, and test-lab environments, but the kernel modules and socket families can also exist on general-purpose distributions. If a host does not intentionally use CAN, the right operational answer is not just “patch”; it is also “confirm whether this code path is loadable or already loaded.”

What this changes in practice

For AlmaLinux 8 fleets, treat ALSA-2026:55764 and ALSA-2026:55765 as a kernel reboot campaign, not a background package update. The fixed package being present on disk is not enough. You need the fixed kernel booted.

A practical runbook should look like this:

# See relevant security advisories known to dnf
sudo dnf updateinfo list --security | grep -E 'ALSA-2026:55764|ALSA-2026:55765|kernel'

# Apply kernel updates
sudo dnf update --security kernel\* kernel-rt\*

# Reboot in your normal maintenance process
sudo systemctl reboot

# After reboot, verify what is running
uname -r
rpm -q kernel kernel-core kernel-modules 2>/dev/null | sort
rpm -q kernel-rt kernel-rt-core kernel-rt-modules 2>/dev/null | sort

If you use live patching, do not assume coverage. Kernel live patch products vary by distribution, kernel stream, CVE, and package family. Verify the live-patch vendor’s advisory mapping for CVE-2026-17523, and still schedule a normal reboot if your compliance or incident-response process requires the base kernel package to be advanced.

For infrastructure teams, I would also add a quick CAN exposure check to the same ticket:

lsmod | grep -E '^can|^can_bcm|^vcan'
modprobe --show-depends can-bcm 2>/dev/null || true
find /etc/modules-load.d /usr/lib/modules-load.d -type f -maxdepth 1 -print -exec grep -H 'can' {} \; 2>/dev/null

Do not treat an empty lsmod result as a replacement for patching. It only helps you understand exposure and prioritize suspicious hosts. Modules can be loaded later if policy allows it.

Fleet notes

For container-heavy environments, remember that containers share the host kernel. Rebuilding application images does not remediate a host kernel vulnerability. Updating the base image in a Dockerfile or Kubernetes workload may be good hygiene, but it does not replace updating and rebooting the node.

For Kubernetes or Nomad nodes, drain before rebooting and verify the node returns with the expected kernel:

kubectl drain NODE --ignore-daemonsets --delete-emptydir-data
# patch and reboot the node
kubectl uncordon NODE
kubectl get nodes -o wide

For autoscaled groups, the cleaner route is usually to bake a fresh machine image, roll the group, and terminate old instances. That gives you a reproducible artifact and avoids one-off snowflake patch state.

For CI systems, prioritize shared runners before single-user laptops. A runner that executes untrusted branch code is a better target than a locked-down server with no shell users. If you allow privileged containers, Docker socket mounts, nested virtualization, or broad device access, raise the priority again.

Caveats

I have not seen enough public, primary-source detail to claim active exploitation from these sources. Tenable’s record says its check relies on self-reported package versions, which is normal for authenticated Linux package checks but worth understanding when triaging scanner output. SentinelOne’s vulnerability page is useful independent analysis, but it is not a distribution advisory; for exact package status, use AlmaLinux, Red Hat, or your vendor’s errata data.

The safest statement is narrower and still operationally important: AlmaLinux 8 shipped Important kernel updates on August 18, 2026; those updates include CVE-2026-17523; the issue is described by multiple sources as a local privilege-escalation path involving CAN BCM; and affected hosts need updated kernels plus reboot verification.

Sources

• LWN: Security updates for Tuesday
• LWN mirror of AlmaLinux ALSA-2026:55764 announcement
• Tenable/Vulners: AlmaLinux 8 kernel-rt ALSA-2026:55765
• Red Hat Bugzilla: CVE-2026-17523
• SentinelOne vulnerability database: CVE-2026-17523
• AlmaLinux errata: ALSA-2026:55764
• AlmaLinux errata: ALSA-2026:55765