PENTESTY · EDITORIAL ANALYSIS · · 4 min read
Linux kernel fixes: approve the kernel that actually runs
Available updates and packages undergoing qualification require different decisions. Acceptance should identify the kernel loaded after each server’s maintenance.
By Pentesty
Separate disclosure from delivery of fixes
The November 3 news concerns a distribution milestone: the CVE has an October 15 public date. The Red Hat bulletin describes a use-after-free condition in IPv4 TCP processing, with potential unauthenticated remote code execution. The priority is to connect that condition to the systems the company maintains.
Anthropic reported a research demonstration involving an internal model and an MPTCP service. That experiment demonstrates a result under the conditions the company described; by itself, it does not establish a campaign targeting organizations. Keep the update record separate from potential incident investigations, each with its own sources and observation period.
Match the advisory to the product and maintenance channel
On November 1, Red Hat published RHSA-2026:93414 for RHEL 8, rated Critical, and RHSA-2026:93412 for RHEL 9 and RHSA-2026:93413 for RHEL 10, rated Important. Those advisory ratings differ from the overall Critical assessment and 9.8 CVSS score in the CVE record. Preserve both contexts in internal communication.
Identify the distribution release, architecture, kernel variant and maintenance channel. The three advisories include, respectively, 4.18.0-553.182.1.el8_10, 5.14.0-687.64.1.el9_8 and 6.12.0-211.72.1.el10_2. These are references for the listed products, without automatic equivalence across all cloud, real-time or CoreOS kernels. Associate each server with its applicable advisory.
Qualify the channel decision before installation
In its November 2 announcement, Canonical reported fixes in -proposed for Ubuntu 22.04, 24.04 and 26.04 LTS, still undergoing qualification and not selected for upgrades automatically. When checked on November 3, the Ubuntu tracker still showed work in progress for the linux package on those releases. Recheck the package and variant before making a change.
The team can assess a controlled group using the package undergoing qualification, or wait for the regular channel with a documented risk exception. Record ownership, dependencies, acceptance tests, the maintenance window and rollback conditions. Enabling -proposed indiscriminately expands the change scope and does not replace acceptance testing for the service.
Acceptance ends with the loaded kernel
The reviewed Red Hat advisories and Canonical guidance require a reboot for these updates to take effect. Retain the host identifier, installed package and running kernel version after the planned reboot. Compare those details with the advisory and timestamp the observation; the installer’s completion report alone does not establish which kernel was loaded.
Check startup, networking, storage and critical service functions on a representative group before expanding deployment. Include virtualization hosts, whose ownership we discuss in the KVM on ARM64 analysis, and track every cluster member, as in LXD update acceptance. The acceptance unit should match the component actually executing the code.
Keep exceptions and mitigations traceable
Red Hat describes IPv4-options filtering as exposure reduction, with incomplete coverage and possible application effects. Its scope should account for network paths and containers. Disabling MPTCP is also insufficient: the vendors explain that it is not a necessary condition for the vulnerability. Do not treat a firewall change as evidence of a fixed kernel.
For any outstanding server, record the reason, containment measures and next review. Remove temporary controls only after checking the fix and its effects on expected traffic. The distinction between an installed package and an active component also appears in PHP2Shell; keep maintenance evidence separate from conclusions about the earlier period.
Frequently asked questions
Does installing the package complete remediation?
Acceptance requires evidence of the kernel loaded after the reboot specified by the advisories. Connect the host, package, running version and service check; a completed installation alone does not demonstrate that the new code is active.
Should I enable -proposed across the Ubuntu fleet?
Canonical describes an option for operators conducting their own acceptance tests. Assess the specific package in a controlled group, with dependencies and rollback defined. Reconfirm the channel’s current status before deciding whether to expand deployment.
Why do the RHEL advisories have different severities?
The reviewed advisories rate RHEL 8 Critical and RHEL 9 and 10 Important, while the CVE has an overall Critical assessment and 9.8 CVSS score. Cite the exact product and advisory, preserving that distinction.
Does traffic filtering or disabling MPTCP resolve it?
The filtering Red Hat describes reduces exposure without fully preventing exploitation and may affect legitimate workloads. MPTCP is not a requirement for the flaw. Apply the appropriate product fix and validate the running kernel.
Sources and references
- Red Hat: technical bulletin and mitigation limits
- Red Hat: CVE record and product-specific fixes
- Red Hat: RHSA-2026:93414 for RHEL 8
- Red Hat: RHSA-2026:93412 for RHEL 9
- Red Hat: RHSA-2026:93413 for RHEL 10
- Canonical: fixes in qualification, November 2
- Ubuntu: current CVE-2026-98432 package status
- Anthropic: Linux research demonstration
Original Pentesty analysis, published November 3, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.