OPSDEN.
Explore the library
← All security intelligenceOPS DEN / INDEPENDENT TECHNICAL BRIEFING
HOST SECURITY / KERNELUPDATED 2026-11-04
Critical / patch6 min READ

Linux IPv4 TCP use-after-free

A race inside Linux IPv4 TCP request handling can allow a remote attacker to corrupt kernel memory before the application sees a connection. Your exposure assessment starts with the kernel running on each host, including OpenShift nodes.

CVE-2026-98432
Article link ↗
OPERATOR VIEWWhat needs attention

Inventory RHEL, OpenShift, and Kubernetes node kernels. Compare installed packages with your vendor's CVE erratum and check reboot state. Include container hosts in the scope.

What happened

CVE-2026-98432 affects the Linux kernel IPv4 TCP path. Concurrent processing can release IPv4 option storage while a separate operation is still using it. A remote peer can try to create this timing condition during connection handling. Research has shown remote root command execution in a configuration that uses Multipath TCP (MPTCP).

The problem sits below application authentication. An HTTP WAF cannot inspect or repair the affected kernel operation. Red Hat identifies RHEL 8, 9, 10, and OpenShift Container Platform as affected products and states that MPTCP being disabled does not establish safety. The advisory distinguishes partial traffic filtering from a complete kernel fix.

An installed kernel update is not enough evidence. Check the kernel that is running after the maintenance operation. For OpenShift, include every node and inspect MachineConfigPool progress before declaring the cluster updated.

Where to look

  • RHEL virtual machines, bare-metal hosts, and network appliances with affected kernels and IPv4 TCP enabled.
  • OpenShift and Kubernetes workers and control-plane hosts. Containers share the host kernel.
  • Systems that accept inbound IPv4 TCP traffic. MPTCP listeners deserve prompt attention, but other IPv4 TCP listeners remain in scope.

Initial investigation

  1. List Internet-facing services and cluster ingress paths. Include alternate origin addresses and internal networks.
  2. Capture the running kernel release, vendor build, and installed kernel packages on each affected host.
  3. Compare these exact builds with the Red Hat security bulletin and relevant RHSA advisories. Account for vendor backports.
  4. Check reboot or node-update status. Verify whether the fixed kernel is the one currently running.

Operator commands

READ-ONLY EXAMPLES

Use these commands to collect evidence. Confirm the running service and vendor security fix before assigning patch status.

RHEL host · read-only inventory
uname -r
rpm -q kernel-core
rpm -q --last kernel-core
ss -ltn
OpenShift · cluster and node state
oc get nodes -o wide
oc get mcp
oc get clusterversion

Remediation plan

  1. Apply the kernel release that your distribution or platform vendor identifies as fixed. Follow its update and reboot procedure.
  2. For OpenShift, use the supported node update path. Monitor pool rollout and protect workload availability during the change.
  3. If you must use interim packet filtering, use Red Hat's exact guidance and test it against the actual traffic topology. The filtering is a partial mitigation, and OVN-Kubernetes traffic paths require separate review.

Evidence to retain

  • Host or node name, environment, and owner.
  • Running kernel build, vendor advisory, and applied RHSA or cluster release.
  • Reachable IPv4 TCP services, any MPTCP exposure, and interim controls.
  • Timestamp of post-reboot verification and remaining unknown hosts.

References

EXTERNAL SOURCES

Read the analysis on Ops Den. Open a reference only when you need the current vendor release or primary evidence.

LOCAL ASSESSMENT

Track your environment

Saved only in this browser. Ops Den does not receive or store your selections.