Patch validation for CVE-2026-98851: test the error, then test deletion

A kernel patch is not validated by confirming that a source file contains the word err. The CVE-2026-98851 correction must release a flowtable reference when connection tracking setup fails during nftables flow offload initialization. A useful regression test must reproduce the failure path and prove that the flowtable can still be deleted afterward.

The Linux kernel CVE affects nft_flow_offload_init(). The vulnerable function calls nft_use_inc() and then returns an error from nf_ct_netns_get() without calling nft_use_dec(). The failed expression does not receive normal destroy handling, so the use count can remain elevated. A later NFT_MSG_DELFLOWTABLE operation can return -EBUSY.

The corrected function saves the error, decrements the flowtable use count when the value is negative, and returns the original error. The fix is recorded in 6.12.113, 6.18.56, 7.2.10, and 7.3-rc6. Ubuntu rates the vulnerability Low with CVSS 4.0 base 2.0 and low availability impact.

Test the contract, not only the diff

The ownership contract has three parts:

  1. A successful expression initialization keeps the use count paired with a live expression.
  2. A failed initialization returns an error and releases the count it took.
  3. A flowtable with no live rules can be deleted after the failed attempt.

The upstream patch addresses the second part directly and makes the third observable. A source review can confirm the branches, but a behavioral test finds integration problems such as an unexpected vendor backport, a test setup that never reaches the target function, or a namespace with different capability rules.

Build the test environment

Use a disposable virtual machine or test host with a network namespace dedicated to the test. Record the kernel release, package build, architecture, and relevant configuration. Confirm that nftables and flow offload support are available in the test namespace.

Keep host networking isolated from production. The test will intentionally create and remove flowtables and may need a controlled way to make connection tracking acquisition fail. The exact failure injection depends on the distribution and kernel build. Do not claim a reproduced security condition if the test only issues malformed syntax and never reaches the target call.

Capture a baseline on the vulnerable kernel

If a vulnerable test kernel is available, run the sequence before installing the fix:

  1. Create a test flowtable.
  2. Submit a flow offload rule addition that reaches nf_ct_netns_get() and fails.
  3. Record the return code and diagnostic.
  4. Attempt to delete the flowtable.
  5. Record whether deletion returns -EBUSY.

Repeat the failed addition in a bounded loop to see whether references accumulate. A vulnerable kernel may remain stuck after the first failure or after several attempts, depending on the surrounding state. Do not force the result by editing the database or faking a return code.

Run the same sequence on the fixed kernel

Boot the fixed kernel and repeat the same setup. Confirm that the rule addition still fails for the intended reason. The patch should not turn an error into success. Then attempt to delete the flowtable.

The expected result is that the failed initialization does not leave a reference behind. The deletion should complete once no legitimate rule owns the table. If it does not, check whether another rule, namespace, or configured reference is responsible before declaring the patch ineffective.

Preserve evidence

The test record should contain:

  • Booted kernel and package version.
  • Test namespace and capability configuration.
  • Exact rule definition and failure injection method.
  • Return code from the failed initialization.
  • Deletion return code and CLI message.
  • Number of retries.
  • Outcome before and after the patch.

This evidence supports both security assurance and future regression testing. It also prevents a common reporting error where "the command failed" is recorded without showing which stage failed or what state remained.

Verify the vendor package

Organizations normally deploy distribution kernels, not the upstream mainline tree. Confirm the vendor advisory and package changelog for CVE-2026-98851. Then verify the running package with uname -r or the platform's equivalent endpoint inventory.

Ubuntu's CVE page may differ across kernel families and releases. Use its current package status for the asset under test. Other vendors may use their own backport and support rules.

Exposure context

The ZoomEye Search used for this topic was product="Linux" and returned 3,138,332 matches. The CVE Filter was vul.cve="CVE-2026-98851" and returned zero. The broad Search does not count vulnerable kernels. It counts Linux product fingerprints in the index.

The Filter zero is not evidence that patch validation is unnecessary. It shows that the selected query did not recover CVE-specific assets. Combine the inventory signal with package and configuration data before estimating the test population.

Mitigation and rollback

The durable mitigation is the fixed kernel. Restricting nftables management to trusted users and namespaces reduces the chance of repeated failures on unpatched hosts but does not remove the bug.

A rollback image must be labeled vulnerable if it lacks the fix. Rolling back after a failed deployment can reintroduce the cleanup defect. Keep the test artifacts so a failed delete can be distinguished from an unrelated configuration mistake.

If a production host has already leaked references, a reboot can clear the in-memory state. Collect logs and configuration evidence first. After the reboot, confirm the fixed kernel is running before returning the host to normal automation.

Release criterion

The patch is ready for fleet deployment when the vendor package is identified, the fixed kernel is booted, the failing initialization still returns its error, and the flowtable can be deleted afterward. The validation should also confirm that the change did not alter legitimate expression creation or deletion.

For CVE-2026-98851, the strongest proof is the disappearance of the post-failure cleanup defect. A source diff explains why the fix should work; the error-and-delete test shows that it does.

References