NULL Pointer Dereference Affecting openshift/ose-rhel-coreos-9 package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RHEL7-OPENSHIFTOSERHELCOREOS9-22369524
- published8 Nov 2026
- disclosed28 Oct 2026
Introduced: 28 Oct 2026
NewCVE-2026-99165 (opens in a new tab)How to fix?
There is no fixed version for RHEL:7 openshift/ose-rhel-coreos-9.
NVD Description
Note: Versions mentioned in the description apply only to the upstream openshift/ose-rhel-coreos-9 package and not the openshift/ose-rhel-coreos-9 package as distributed by RHEL.
See How to fix? for RHEL:7 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
sctp: revalidate output stream after association connect wait
When message interleaving is enabled, the first send waits for association establishment before building its data chunks. The wait drops the socket lock, and handshake processing can reduce the output stream count to the peer-advertised inbound stream count. sctp_stream_init() then frees the extension of every removed stream.
The sender resumes with the stream that it checked before the wait. If the peer removed that stream, sctp_outq_tail() later dereferences its NULL extension. Fatal-oops policies then panic the host.
KASAN: null-ptr-deref in range [0x38-0x3f] RIP: sctp_outq_tail+0x49e/0xaa0 Call Trace: sctp_primitive_SEND sctp_sendmsg_to_asoc sctp_sendmsg
A range check alone is insufficient. Stream reconfiguration can grow the output count again while the lock is released without recreating extensions freed by the earlier shrink. The stream can then be in range while its extension remains NULL. The send-buffer wait has the same issue.
Factor the range and extension checks into a helper and repeat both after each send-path wait that drops the socket lock. Once the lock is reacquired, the validation remains stable through data creation and queueing.
If validation fails after the connect wait, the auto-created association is already established. Return ESRCH so the existing caller path keeps it under state-machine ownership instead of freeing it directly, which would leave protocol, counter and socket state inconsistent.
References
- https://access.redhat.com/security/cve/CVE-2026-99165
- https://git.kernel.org/stable/c/77a63d1b813b08c4e5a948f5e04fbaca6176aa8f
- https://git.kernel.org/stable/c/b7ad72414c673ce1fa1f463e807cd4f34f8be9bf
- https://git.kernel.org/stable/c/fd56ac95ec31a05b66e8938debfa847f49c0e993
- https://git.kernel.org/stable/c/26af2969b29cc5eb893a454fee2a36b39521a5bd
- https://git.kernel.org/stable/c/504bdf55438ad4b1ecbfba0f7fe95e1933f7fb66
- https://git.kernel.org/stable/c/84f741b7bb3974e674c9739055826aa040362bba
- https://git.kernel.org/stable/c/994694a2d4611d7b76cf05ff401a92b1c0451e1f
- https://git.kernel.org/stable/c/b925652ba3a3ee11b2617e68de92379144b5b84b