The DRDA and DDM protocol layer represents an underexamined attack surface on IBM i, and the generic 'improper processing' description in this CVE masks a parsing vulnerability that warrants deeper technical scrutiny than the advisory provides.
The core problem is what the CVE doesn't tell you. 'Improper processing of DRDA and DDM resynchronization requests' could describe a buffer condition, a state machine error, or resource exhaustion. This ambiguity matters: resynchronization is a recovery mechanism, and recovery code paths are reached through error conditions rather than happy paths — exactly where vulnerabilities hide. Protocol resync handlers are structurally prone to bugs because they're written under time pressure, rarely exercised by QA, and handle complex state transitions that are hard to reason about.
The attack surface is significant. DRDA and DDM are the wire protocols for DB2 for i remote connectivity — they aren't general-purpose services that get scanned constantly. Security research on IBM i protocols lags behind mainstream platforms. This vulnerability may be reachable by an unauthenticated remote attacker on ports 446/448/448, which for a database protocol is a meaningful constraint on exposure. The low EPSS likely reflects limited automated exploitation tooling, not limited exploitability.
Two things you should do now: first, check whether PTFs for this issue have been applied AND are not deferred. On IBM i, a deferred PTF leaves vulnerable code physically present in production memory — the fix exists but isn't active. Second, evaluate whether DRDA/DDM ports are exposed to untrusted networks. Protocol-level filtering is the only viable compensating control for DRDA/DDM exposure, but it requires accepting reduced remote database connectivity. That's the uncomfortable tradeoff that causes these patches to get deferred — not because the risk isn't understood, but because the control feels worse than the vulnerability.
Watch for the IBM APAR to clarify whether this resolves to memory corruption or a simpler parsing error. Historical patterns in similar protocol-layer bugs suggest memory corruption is the modal outcome when recovery handlers fail — treat this as potentially worse than a pure DoS until proven otherwise.