Kernel risk management
CVE-2026-98432: mitigation is not a kernel fix
An anonymised CVE-2026-98432 response: distribution checks, temporary firewall mitigation, service validation and a documented path to a definitive kernel fix.
For CVE-2026-98432, a temporary mitigation and a corrected running kernel are different states. The handover needs to preserve that distinction.
Start with the distribution and the active kernel
The Red Hat bulletin describes a use-after-free in Linux IPv4 TCP processing. Its network-level nature makes this an infrastructure response, rather than a website-plugin update.
The AlmaLinux advisory documents affected branches, distribution-specific fixed packages and temporary filtering guidance. MPTCP being disabled does not establish that the underlying flaw is fixed.
In the anonymised assessment documented on 1 November 2026, we checked the distribution, the active kernel, installed kernels and the packages available in the server's official production repositories. The corrected package was not available in those repositories at the time of that check.
An upstream version comparison would not have been sufficient because distribution packages can carry backported fixes. Equally, an installed kernel is not evidence that the machine has booted into it. The inventory needed to distinguish both states.
Apply a scoped mitigation with an exit plan
The documented response applied temporary network filtering after compatibility checks, retained MPTCP disabled and prepared a reversal path. Existing firewall rules were preserved. No testing kernel was installed and the server was not rebooted.
Configuration checks covered the filter syntax, its dedicated service and persistence settings. Persistence was configured and inspected, but not exercised through a reboot. That distinction belongs in the acceptance record.
A network mitigation should be assessed against the host's actual workloads, including container networking and any use of IPv4 options. It should not be copied from an article into a production shell without reviewing those dependencies.
The state after this intervention was temporary mitigation applied, definitive kernel correction pending. Server ownership includes retaining that open item, even when the public websites continue to respond normally.
Validate service continuity and track the remaining fix
The recorded checks compared service state and sampled public HTTPS responses and assets before and after the intervention. No regressions were observed in those checks. Pre-existing public-access, DNS and certificate issues were kept separate.
These were service and HTTP checks, not full functional acceptance or an exploit-based test of the mitigation. No exploit was run. A working homepage cannot establish that a kernel vulnerability is closed.
Follow-up monitoring was configured to check official production-package availability and mitigation state. The remaining path was to prepare an approved kernel update, plan service and session recovery, boot the corrected kernel and validate the resulting state.
This note records the intervention as documented on 1 November 2026. It is not a live status page for any server or a current repository-availability guarantee. A new intervention needs a fresh advisory and repository check, supported by a security review, a recovery plan and clear follow-up ownership.
Practical takeaway
- Use the distribution's advisory and package evidence.
- Distinguish mitigation, package installation and the running kernel.
- Record persistence configuration separately from a reboot test.
- Keep the definitive update open until activation and validation.