Allocation of Resources Without Limits or Throttling Affecting openshift4/ose-sriov-network-webhook-rhel9 package, versions *


Severity

Recommended
high

Based on Red Hat Enterprise Linux security rating.

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 Learn

Learn about Allocation of Resources Without Limits or Throttling vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-RHEL7-OPENSHIFT4OSESRIOVNETWORKWEBHOOKRHEL9-16093359
  • published17 Apr 2026
  • disclosed13 Apr 2026

Introduced: 13 Apr 2026

NewCVE-2026-35469  (opens in a new tab)
CWE-770  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:7 openshift4/ose-sriov-network-webhook-rhel9.

NVD Description

Note: Versions mentioned in the description apply only to the upstream openshift4/ose-sriov-network-webhook-rhel9 package and not the openshift4/ose-sriov-network-webhook-rhel9 package as distributed by RHEL. See How to fix? for RHEL:7 relevant fixed versions and status.

spdystream is a Go library for multiplexing streams over SPDY connections. In versions 0.5.0 and below, the SPDY/3 frame parser does not validate attacker-controlled counts and lengths before allocating memory. Three allocation paths are affected: the SETTINGS frame entry count, the header count in parseHeaderValueBlock, and individual header field sizes — all read as 32-bit integers and used directly as allocation sizes with no bounds checking. Because SPDY header blocks are zlib-compressed, a small on-the-wire payload can decompress into large attacker-controlled values. A remote peer that can send SPDY frames to a service using spdystream can exhaust process memory and cause an out-of-memory crash with a single crafted control frame. This issue has been fixed in version 0.5.1.

CVSS Base Scores

version 3.1