Skip to content

Fix S0C4 in process_dd for multi-digit SPACE values#22

Merged
mgrossmann merged 1 commit intomainfrom
fix/process-dd-space-overflow
Mar 12, 2026
Merged

Fix S0C4 in process_dd for multi-digit SPACE values#22
mgrossmann merged 1 commit intomainfrom
fix/process-dd-space-overflow

Conversation

@mgrossmann
Copy link
Contributor

Summary

  • Fix hardcoded buf += 7 in the 0x83 SPACE quantities handler to properly parse variable-length length-prefixed values
  • Add bounds checking on memcpy lengths in DDK (max 8), DSNAMEK (max 44), SYSOUTK (max 4) as defense in depth

Root Cause

The 0x83 sub-key encodes SPACE quantities as length-prefixed numeric strings. Single-digit values like (1,1,1) are 7 bytes total, but multi-digit values like (600,100,200) are 13 bytes. The hardcoded advancement misaligned the parser, causing stack buffer overflows and R13 corruption → S0C4.

Test plan

  • Rebuild crent370 and re-link mvsMF
  • Run mbt bulk build for a project with large SPACE values (e.g. FTPD with SPACE=(TRK,(600,100,200)))
  • Verify no S0C4 ABENDs during job status queries

Closes #21

The 0x83 sub-key handler used a hardcoded buf += 7, which only worked
for single-digit SPACE values (e.g. 1,1,1). Multi-digit values like
(600,100,200) use longer length-prefixed encodings, causing the parser
to misalign and overflow stack buffers via DDK/DSNAMEK/SYSOUTK memcpy
calls, corrupting R13 and triggering S0C4 on function return.

Replace hardcoded advancement with a proper loop that follows
length-prefixed values. Add bounds checking on memcpy lengths as
defense in depth.

Closes #21
@mgrossmann mgrossmann merged commit 58319b2 into main Mar 12, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

S0C4 ABEND in process_dd when parsing SPACE with multi-digit values

1 participant