A broad search result can create more work than clarity. ZoomEye returned 3,138,477 matches for product="Linux" while researching CVE-2026-98438, and the exact CVE filter returned 0. The product count is a useful map of Linux fingerprints. It is not a list of vulnerable MPTCP endpoints, and the review process needs to make that distinction explicit.
CVE-2026-98438 is an uninitialized checksum bug in mptcp_write_data_fin(). The issue was introduced in Linux 7.1 and fixed in 7.2.7 and 7.3-rc3. A zero-length DATA_FIN with checksum negotiation can cause the kernel to calculate a packet checksum before ext->csum has been set. Public descriptions identify packet corruption, dropped packets, and denial of service as possible effects.
Start with the right denominator
The denominator is not every Linux asset. It is the set of assets that can run the affected code and expose the relevant path to an untrusted peer. Asset records should include the kernel package, running release, vendor, build identifier, MPTCP enablement, network role, and owner. A product search cannot supply all of those fields.
The first reduction is vendor affectedness. Red Hat reports that its Enterprise Linux 9 and 10 kernels do not contain the vulnerable code. Debian's tracker lists stable bookworm and trixie kernels as not affected while newer branches have fixed packages. The upstream record says the issue began in 7.1 and is fixed in 7.2.7 and 7.3-rc3. Use those statements as evidence for a build, not as assumptions about every host that runs Linux.
The second reduction is configuration. A host with MPTCP compiled into the kernel but not used has less immediate exposure than a service that accepts MPTCP connections from untrusted networks. Confirm the runtime policy with the interfaces supported by the distribution. Do not infer protocol enablement from a product fingerprint alone.
Interpret the ZoomEye numbers
product="Linux" is a product-fingerprint query. Its 3,138,477 result describes indexed Linux product matches. It does not show kernel versions, MPTCP options, checksum negotiation, or whether the host is reachable by a peer that can trigger the flaw. The CVE filter vul.cve="CVE-2026-98438" returned 0, which means the exact indexed query had no matching result at that time.
Neither result should be used as a claim that 3.1 million systems are affected or that zero systems are vulnerable. A useful workflow keeps the external observation separate from internal evidence:
Use the product search to find externally visible Linux services that belong to the organization.
Join those addresses to inventory, ownership, kernel version, and vendor patch status.
Remove hosts whose vendor confirms the vulnerable code is absent.
Test or restrict the MPTCP path on the remaining hosts.
Record the query time and the exact dorks with the decision.
That sequence preserves the value of ZoomEye without turning an exposure estimate into a vulnerability count. It also protects teams from wasting time on hosts that cannot reach the affected branch.
Build a prioritization model
A reasonable priority score combines reachability, availability impact, patch status, and confidence. Reachability is high when an untrusted peer can establish an MPTCP connection with checksum negotiation. Availability impact is high when teardown failures could interrupt a critical service or trigger broad retries. Patch status is high when the running kernel lacks the checksum reset. Confidence is high when the owner has verified the kernel and protocol configuration directly.
This model does not need to invent probability data. The public records do not quantify exploitation or outage rates. They do give a clear vulnerable code path, a small fix, and a set of affected releases. The prioritization can therefore focus on evidence quality and service criticality.
Remediate and close the review item
Install the vendor or upstream kernel containing the fix. For upstream releases, the relevant fixed versions are 7.2.7 and 7.3-rc3. For custom kernels, verify that ext->csum = 0 is present before checksum calculation in mptcp_write_data_fin(). Then confirm the running kernel matches the approved build.
If MPTCP is not required, disabling it or blocking its traffic may reduce immediate exposure. That decision should include a rollback path and a test of legitimate multipath services. A network block can be useful containment, but it does not prove that the source defect was repaired.
After patching, test a representative connection that negotiates checksums and closes with a zero-length DATA_FIN. Review retransmissions, checksum errors, and connection resets during the rollout. The item can close when the owner has recorded the kernel evidence, the source fix, the MPTCP policy, and the teardown result.
The main lesson from this inventory is procedural. A broad product count is useful for finding the population, while a narrow source and runtime check determines affectedness. CVE-2026-98438 is fixed by a one-line checksum reset, and the quality of the remediation record depends on proving that the reset is running where MPTCP is exposed.