CVE-2026-98432 and CVE-2026-106378: Linux and Chrome Fixes

CVE-2026-98432 affects the Linux kernel’s IPv4 TCP handling; CVE-2026-106378 affects Chrome’s sandbox on macOS before 155.0.8059.39. Check Linux hosts against their vendor’s kernel advisory, and Mac browsers against the Chrome update record. Verify the active version after updating: a downloaded update alone does not establish that either fix is running.

Derek Ross’s October 30 warning brought the Linux issue to server, node and relay operators. PWN.AI’s October 30 post highlights the separate Chrome GPU sandbox escape. The practical question for a startup team is which machines, packages and browser installations need action.

The Linux CVE announcement dates to October 15; Google’s Chrome CVE record was published October 6. Today’s posts renew attention to existing vulnerabilities and fixes.

Status checked October 30, 2026. The vendor links below are the live sources of truth. Package availability can change after this article’s snapshot.

What is CVE-2026-98432, and does it allow remote takeover?

The confirmed defect concerns memory lifetime during TCP connection processing. Treat it as a serious kernel vulnerability, while keeping claims about reliable remote takeover separate from the documented bug.

In a use-after-free, code accesses memory after that memory has been released. Here, concurrent work can still read IPv4 socket options after another execution path frees them. The upstream patch changes two destruction paths to defer freeing those options until an RCU grace period has passed. RCU, or read-copy-update, is a kernel mechanism that lets existing readers finish before memory is reclaimed.

As checked on October 30, Ubuntu lists CVSS 3.1 at 9.8, and Red Hat’s live advisory lists a preliminary 9.8. Red Hat describes a potential crash, denial of service or memory corruption. Amazon Linux rates it 8.1. Attribute each score to its vendor and scoring version; a severity score does not prove that every affected deployment can be taken over reliably.

Anthropic’s October 27 research reports a demonstrated exploit that runs commands as root on a Linux server with a Multipath TCP (MPTCP) listener, without credentials or user interaction. That is a concrete remote-execution result, with a stated configuration. It does not establish exploit reliability for every affected kernel and deployment.

The Go Security Team’s October 29 advisory explains why teams may have such listeners unexpectedly: Go 1.24 enabled MPTCP by default for Linux listeners, subject to application and runtime overrides. The team recommends a patched kernel and warns that disabling MPTCP addresses the demonstrated path while leaving the underlying IPv4 bug unresolved.

For your incident record, separate three questions: does the vulnerable code exist, can relevant traffic reach it, and what exploitation has been demonstrated for your environment? You can prioritize patching while those answers are incomplete. An unknown answer establishes neither safety nor compromise.

Which Linux kernel versions are affected and fixed?

Upstream release numbers identify fixes in upstream kernel branches. Distribution packages need a separate check because vendors can backport a fix while retaining an older base version.

The current Linux CNA record traces the issue to Linux 4.4 and identifies these fixed release boundaries, checked October 30:

Use the latest supported release for the branch you maintain. These boundaries describe upstream branches, not a universal detection rule for Ubuntu, Debian, RHEL or a cloud image. Vendor advisories determine which distribution packages contain the correction.

A backport applies a correction to a maintained older codebase. That is why a vendor package with a lower-looking version can contain a fix, and why checking only whether uname -r is numerically above a version from a social post can misclassify a machine.

Keep the full package identity: distribution release, kernel family or flavor, architecture, and package revision. A cloud kernel, generic kernel and hardware-enablement kernel can follow different update tracks within the same distribution.

The upstream description also says IPv6 is unaffected by the first issue, while identifying a related IPv6 migration problem for a separate patch. Do not turn that narrow statement into a claim that changing a service to IPv6 resolves every relevant kernel concern. Check the advisory that applies to your configuration.

What is the Ubuntu, Debian, RHEL and cloud fix status?

Fix status belongs to a product and package line. The table is a dated starting point for finding that line; it cannot establish the state of a running host.

Sources: Ubuntu CVE tracker, Debian security tracker, Amazon Linux CVE tracker, Red Hat advisory, and Oracle Linux CVE repository.

Debian’s numbers here are source package versions, not literal values to expect from uname -r. Ubuntu’s tracker contains many additional flavors. Oracle’s UEK errata do not establish that every Oracle kernel line is fixed.

If your exact package is missing from this snapshot, open its vendor tracker. Record the answer as unknown until you can map it. Absence from a short article table is not evidence of safety.

How do you check the kernel your server is actually running?

Collect the operating system and running release first. Then connect those facts to the vendor’s package record.

These read-only commands are a starting point on a Linux host:

cat /etc/os-release
uname -r

Save the output with the host identity and check time. Run the checks in the environment whose kernel you need to establish, and identify who controls its updates. For a managed service, that may require a provider’s confirmation rather than access to a package manager.

Next, use your distribution’s package tools to identify the installed kernel packages and their full revisions. Compare the applicable package with the fixed build named by the vendor. A successful package-manager run records installation; you still need to establish which kernel is active.

Keep these states separate:

After a conventional kernel update, follow your vendor’s reboot procedure and check the running release again. If you use live patching, obtain explicit evidence that the provider covers this CVE on this kernel. A live-patching subscription alone does not answer that question.

Apply the same check to replacement machines. Check the image or template used for new hosts, then inspect a newly launched instance. Otherwise, a successful response on today’s servers can leave tomorrow’s replacement unverified.

What can you do while a vendor fix is pending?

Reduce relevant exposure, assign the next decision, and keep the unpatched state visible. Temporary controls need their own verification and removal plan.

Start with an exposure inventory: which hosts accept TCP connections, from which networks, through which controls? Include administrative interfaces and infrastructure services alongside the public application. A hostname alone does not describe the traffic path to the host.

Review whether unnecessary services can be stopped or access narrowed without breaking required operations. Describe the result precisely: which source networks can still reach which listener? Check it from the relevant network position. Treat this as exposure reduction, with the residual risk recorded.

The Red Hat advisory says no mitigation currently meets its published suitability criteria. The kernel CVE team’s guidance favors updating to a supported stable release and discourages cherry-picking isolated fixes. Prefer your vendor’s supported update path over a homemade kernel change.

The social warning also discusses filtering IPv4 options and disabling Multipath TCP, or MPTCP. The Go advisory confirms the reason to inspect MPTCP listeners, but warns that program-by-program configuration is fragile and the underlying bug is not MPTCP-specific. Before using a workaround, establish which code path it addresses, which traffic still reaches the host, and whether your vendor supports it for your configuration.

If your team changes network controls, preserve access for recovery, test required connectivity, and record how to reverse the change. A copied firewall rule cannot assess your existing policy or dependencies. Have the person who owns that network approve the specific change and verify its effect.

Give pending cases a named responder and a next advisory-check time. Escalate decisions that need downtime, provider action or an accepted period of residual risk. Our security fix escalation guide covers how to make that decision explicit.

What does Chrome CVE-2026-106378 require you to update?

Update Chrome on macOS to the current supported stable version and relaunch it. Google’s CVE record identifies versions before 155.0.8059.39 as affected by this issue; that historical fixed boundary is not a recommendation to stay on an old browser release.

Google listed this fix in its October 6 Chrome 155 release. PWN.AI’s October 30 post presents later research about a previously shipped correction.

In PWN.AI’s research, code already running inside Chrome’s GPU process could send synthetic keyboard input through macOS WindowServer. The demonstration opened Spotlight and launched Calculator outside the GPU sandbox. The researchers explicitly begin with native code execution in the GPU helper. Their test therefore demonstrates an escape step, rather than supplying the initial browser compromise.

Google’s CVE description states a prerequisite of a previously compromised renderer and rates the issue Medium under Chromium’s severity system. Keep that vendor description alongside the research’s specific GPU-process starting point. Neither warrants describing this individual bug as a complete, universal drive-by attack. Google’s CVE record.

The Chromium fix addresses inherited authorization under macOS’s privacy-permission system, TCC. Its description explains that directly launching Chromium’s executable from another process can pass that parent’s permissions to Chromium and its children. The GPU child should not inherit that authorization. Launch context and existing permissions matter to the reported behavior.

Assign a browser-update owner and record the evidence:

For Chrome, open Help → About Google Chrome, let the supported update finish, and relaunch when prompted. Recheck the displayed version afterward. Google’s Chrome update instructions explain the process. Keep the browser check separate from the Linux kernel rollout: they cover different software and activation steps.

What evidence should close these CVE remediation tasks?

Close a host’s remediation when you can connect its identity, applicable fix, active kernel and verification result. Keep exceptions separate so a completed rollout does not hide a machine still awaiting action.

For the Chrome task, use the same fields for the Mac, browser installation, advisory and post-relaunch version. Record a kernel reboot and a browser relaunch against their respective tasks.

Use a short record like this. It is an operational template, not a vendor requirement:

• Host and owner: stable machine identity, service, environment and responder.
• Applicability: distribution, kernel family, full package revision and advisory URL.
• Action: update or approved temporary control, with completion time.
• Activation: post-reboot running release, or explicit supported live-patch coverage.
• Verification: who checked the evidence, when, and whether required services remain healthy.
• Remaining work: deferred hosts, temporary controls, replacement images and the next check.

For a fleet, report completed and outstanding hosts against the same inventory. A statement such as “the kernel update is deployed” leaves too much room for interpretation. Say which machines are running the corrected build, which have it installed but inactive, and which remain pending.

Consider a hypothetical three-server application. Two machines reboot into the corrected kernel; the third has the package installed but misses its maintenance window. Keep the third machine open, name its owner, and give it a new activation time. The package installation succeeded, but that host has not met the same closure condition as the other two.

If a researcher reported the exposure, acknowledge the report and explain what you verified without disclosing unnecessary infrastructure details. Our guide to setting up a vulnerability disclosure program covers that communication path.

Common questions about the Linux and Chrome fixes

Does installing the latest kernel package finish the fix?

Confirm that the package contains the vendor’s correction and that the host is running it. Follow the supported reboot or live-patch procedure, then record the active state.

Is every Amazon Linux 2023 server patched?

No blanket conclusion follows from the distro name. In the October 30 snapshot, Amazon’s tracker lists fixes for kernel6.12 and kernel6.18, while its default kernel line remains pending. Check the package family on your host against the current Amazon advisory.

Does an old-looking kernel version prove vulnerability?

A maintained distribution can backport a fix. Use the full vendor package revision and advisory mapping, then verify activation. A version comparison against upstream alone is insufficient.

Does the warning mean my server was compromised?

The vulnerability alert establishes a reason to check exposure and remediate. A compromise claim needs separate evidence from your environment. Keep patch response and incident investigation distinct in your records.

Does the Chrome escape prove that a web page can take over every Mac?

The published GPU demonstration assumes prior native code execution, and Google’s CVE description also specifies a prior renderer compromise. Update affected browsers, while preserving those prerequisites when describing the research.

Keep the report owner and verification record in Kit

The useful handoff is small: a named owner, the applicable advisory, the action taken and the evidence checked. Your team performs the host inspection and patching; the case record keeps the decision understandable for the next responder.

Kit’s CSIRT workflow lets you assign a report, retain assignment and status history, and distinguish resolved from fix verified. Authorized staff can mark a resolved fix verified and add an optional note. That note can point to your host evidence; the status change itself is a human confirmation, not an automated kernel test.

For CVE-2026-98432, work from the current vendor package row through to the active host. For CVE-2026-106378, check the running Chrome version after relaunch. Keep pending machines visible until they meet the relevant closure condition. If your disclosure work needs an owner and a shared verification history, you can try Kit.