A security notice says “critical.” A second page from the same vendor says “moderate.” Meanwhile, another Linux distributor says patched kernels are available—but only in a testing repository. For an administrator, the immediate question is not which label wins. It is whether a particular system is affected, whether its distributor has issued a fix for its supported kernel, and what to do while that answer is still developing.
That is the practical problem raised by CVE-2026-98432, a use-after-free in Linux kernel IPv4 networking. Red Hat’s October 30 advisory calls it critical and describes a race involving TCP connection requests. Red Hat’s separate CVE page calls it moderate, describing crash or denial of service as the main impact and possible memory corruption. AlmaLinux also calls it critical, but its October 30 post says patched kernels are available in testing—not that they have reached general production availability. Red Hat advisory Red Hat CVE page AlmaLinux post
The upstream Linux kernel CVE announcement is dated October 15 and lists fixes in versions 6.12.113 and 6.18.56. That date matters: Red Hat’s October 30 advisory is not the first disclosure. Nor do those upstream version numbers, by themselves, show whether a distributor’s kernel package includes a fix. Upstream announcement
For operators, the useful response is a short evidence-gathering process: identify the systems and their distribution, check the relevant vendor’s status, distinguish a test package from a released update, and plan an update or follow-up accordingly. The available notices do not establish active exploitation, so avoid treating severity labels as evidence that exploitation is occurring.
First, keep the three questions separate
Security discussions often collapse three different questions into one: how serious the flaw may be, whether a specific installation is affected, and whether a fix is ready for that installation. They are related, but the notices answer them in different ways.
Severity is an assessment, not a shared verdict. Red Hat’s advisory rating is critical; Red Hat’s CVE page rating is moderate. AlmaLinux’s post calls the vulnerability critical. Those are attributed judgments from the publishers, and the supplied evidence does not settle the disagreement. Do not quietly select the highest or lowest label and present it as a universal consensus.
Exposure depends on the system and its supported package stream. The issue is in Linux kernel IPv4 networking, and the Red Hat advisory describes a race involving TCP connection requests. But the evidence provided here does not give a complete product-by-product affected-version list. You need the status for the distribution, release, and kernel stream actually deployed—not a guess based on the word “Linux.”
Fix availability is a release-status question. AlmaLinux says patched kernels are available in its testing repository. Testing availability is useful information, but it is not the same as a general production release. The upstream announcement lists fixed kernel versions, but distribution packaging and supported branches can differ. Treat each status as a separate fact rather than turning it into a broad “patched” or “unpatched” claim.
A helpful mental picture is a repair journey through three checkpoints. The severity label is the warning light: it describes a publisher’s assessment, not the condition of every vehicle. The system inventory is the vehicle’s registration and service history: it identifies which product and version you actually operate. The package channel is the workshop’s parts counter: a repair part being tested there is not necessarily ready for every customer’s production vehicle. The analogy is only a way to organize the questions; it does not establish the flaw’s real-world impact or prove a system is exposed.
A practical triage, without guessing from version numbers
1. Write down what you actually run
Start with an inventory of the systems you may need to assess. Record the Linux distribution and release, the kernel package or kernel stream in use, and whether the machine is a production host or another kind of system. Use the records and tools your organization already trusts for identifying installed packages; do not infer the distribution’s security status from a kernel version copied from a search result.
The goal is to make follow-up specific. “We have Linux” is too broad to resolve package status. “This system runs this distributor’s release and kernel stream” gives an operator a concrete set of vendor guidance to check. If the inventory is incomplete, mark that gap instead of treating an unverified assumption as confirmation.
2. Check the distributor’s own status for that system
Look for the vendor’s advisory or security-status information for CVE-2026-98432 and match it to the operating system release and kernel stream in your inventory. For Red Hat users, the October 30 advisory is relevant evidence, but the existence of the advisory does not by itself answer the status of every Red Hat system. Consult the product-specific information associated with the systems you operate. Red Hat advisory
For AlmaLinux, distinguish the October 30 statement about packages in testing from a later notice that might establish a broader release. The post supports saying that patched kernels were available in testing at that time. It does not support saying they were generally released for production. If you use a different distribution, these sources do not establish its package status; check that distribution’s own current guidance.
3. Treat upstream versions as clues, not a universal pass/fail test
The upstream announcement names 6.12.113 and 6.18.56 as versions with fixes. That is useful when following the technical lineage of the correction. It is not enough to declare every system running a lower-looking version vulnerable or every system reporting one of those numbers safe. A distributor may package fixes for supported branches in its own way, and the evidence here expressly does not establish that upstream numbers alone determine patch status.
If a package report and an upstream version list seem to disagree, do not resolve the discrepancy by intuition. Check the distributor’s advisory and package information for the actual release. If the available status is unclear, record it as unresolved and seek the appropriate vendor or internal security-team guidance.
4. Separate “not known” from “not affected”
The reviewed sources do not establish active exploitation. That means you should not claim that exploitation is happening on the basis of these notices. It also does not mean that every deployment is unaffected, or that the vulnerability is unimportant. Keep those conclusions distinct: exploitation status is one question; package exposure and remediation status are others.
Similarly, a missing update announcement is not proof that a system is safe, and a critical rating is not proof that a particular host is vulnerable. The evidence may be incomplete, the relevant package may not yet have a published status, or the host may use a product stream not covered by the notice you first found. State what has been verified and what remains unknown.
An illustrative case: two systems, one incident record
Illustrative scenario: An operations team finds one Red Hat system and one AlmaLinux system in its inventory. A colleague forwards the Red Hat advisory and describes both machines as “critical and unpatched.” The team does not accept that shorthand as its conclusion. It records the Red Hat advisory’s critical rating alongside the separate moderate rating on Red Hat’s CVE page, without pretending that the sources agree. It then checks the Red Hat system’s specific release and kernel status against the applicable vendor information.
For the AlmaLinux machine, the team notes that the October 30 post reported patched kernels in testing. It does not mark the production host patched based on that statement alone, and it does not assume the test packages are generally released. Someone is assigned to check for a subsequent production update and confirm the host’s package status. The two machines receive separate entries because their distributor and update status differ.
This example is a way to keep records honest, not a claim about what either system will ultimately require. The supplied evidence does not establish which of these hypothetical machines is affected, which package is appropriate for a particular deployment, or what operational action an organization must take. Those depend on the actual product and current vendor guidance.
Picture two labeled-by-context tool trays on a workbench, each holding a different machine part. One tray contains a part marked for testing; the other awaits confirmation from its manufacturer. The parts look similar, but the mechanic cannot safely treat them as interchangeable or ready for installation without checking the fit and release status. That is the point of tracking each distribution separately: a shared kernel flaw does not make package channels or readiness identical.
Common mistakes that slow down a good response
Choosing one severity rating and hiding the disagreement. A short status update can say that Red Hat’s advisory calls the issue critical while its CVE page rates it moderate, and that AlmaLinux calls it critical. That is clearer than describing “the industry rating” as if there were one agreed answer.
Calling testing packages production-ready. AlmaLinux’s wording matters. “Available in testing” is a useful status update; it is not evidence of general production availability. Keep the distinction in tickets, change plans, and messages to service owners.
Treating an upstream version as a complete inventory check. The upstream announcement provides fixed version numbers, but supported distribution branches and packages can differ. A version comparison may help direct a question; it cannot replace checking the distributor’s status for the system in question.
Turning an absence of evidence into reassurance or alarm. The reviewed sources do not establish in-the-wild exploitation. Do not turn that into “there is no risk,” and do not imply active attacks without evidence. Likewise, an advisory does not prove that every host is affected.
Using one status for an entire fleet. A fleet may contain multiple distributions, releases, or package channels. The facts here do not establish that all machines share the same status. Track what is known per system or per clearly defined group, and leave uncertain cases visibly unresolved until checked.
A compact checklist for the next update
Before closing the assessment, make sure your record answers these questions:
- Which systems, distributions, releases, and kernel streams are in scope?
- What does the relevant distributor say about CVE-2026-98432 for those systems?
- Have you kept Red Hat’s conflicting severity ratings attributed to their respective pages?
- Is a package in testing, generally released, or not yet confirmed? What source supports that status?
- Are upstream fixed versions being used as context rather than as a universal package test?
- Has anyone claimed active exploitation? If so, what evidence supports that claim? The reviewed sources do not establish it.
- Who will recheck unresolved package status, and what vendor or internal guidance will they use?
The most defensible summary is also the most operationally useful: CVE-2026-98432 is a Linux kernel IPv4 use-after-free; publishers give conflicting severity assessments; AlmaLinux reported patched kernels in testing; and upstream listed fixes in specified versions. None of those facts, alone, determines the status of every deployed system. Work from the actual distribution and kernel stream, preserve uncertainty where the notices leave it, and update the record when a relevant package status is confirmed.
Sources
- RHSB-2026-016 Use-after-free - kernel IPv4 (CVE-2026-98432) (2026-10-30)
- CVE-2026-98432: Patched kernels available in testing (2026-10-30)
- CVE-2026-98432 (publication date not stated)
- CVE-2026-98432: ipv4: free inet_opt and ireq_opt after an RCU grace period (2026-10-15)
