The zACS report (DOCTXT(IBMZACSR)) is the result of a zACS run with the zACS tool of z/OSv3.1 from SVA against our currect FLAMSTC. Current analysis of the zACS report by Jörn Meyburg SYSeins GmbH *** Yes, I have analysed the report and, to be honest, I have my doubts a little about the zACS expertise. There are again two instructions are criticised. The first instruction is in the FLZXMR, and is the same as the last but one report for ticket #87, but this is now behind a VSMLOC call that checks the R2 area for validity, see below. The second one is in the recovery routine FLZXRR, and here my question mark is even bigger, because the instruction belongs to the macro resolution of VSMLOC, see below. Here is the report of the first one: ZACS INITIALIZED ON MAIN AT 2025/04/25 16:17:06 LEVEL UJ96080 ON Z/OS 3.1 *** POTENTIAL VULNERABILITY FOUND IN PC 00180700 00000002 *** ABEND COMPLETION CODE: 0C4000 REASON CODE: 00000011 PSW: 070C4000 8B405772 MODULE: PVTMOD=(FLZXMR,00000092) LIKELY EYECATCHER AT 0B4056E0: .{..0{.........{.0{.\......\..JK.}.H. INSTR LEN: 04 FAILING INSTR: A774 0255 1777 5830 20AC 4130 TRANSLATED INSTR: L R3,172(,R2) SOURCE ADDRESS CAUSING TRANSLATION EXCEPTION: 00000000_0002A801 HOME ASID: 002D PRIMARY ASID: 002C SECONDARY ASID: 002D HOME JOB: ZACSJ PRIMARY JOB: FALKSTC SECONDARY JOB: ZACSJ CVSS: 6.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) SLIP SAMPLE FOR PC 00180700 00000002: SLIP SET,ID=A000,COMP=0C4,P=(FLZXMR,00000092),A=(SVCD,RECORD),END +-----------------------------------------------+ |General Registers before the service | +-----------------------------------------------+ | R0:00000000_003FF7FF R1:00000000_0002A000 | | R2:00000000_003FF7FF R3:00000000_003FF7FF | | R4:00000000_003FF7FF R5:00000000_003FF7FF | | R6:00000000_003FF7FF R7:00000000_003FF7FF | | R8:00000000_003FF7FF R9:00000000_003FF7FF | | RA:00000000_003FF7FF RB:00000000_00180700 | | RC:00000000_003FF7FF RD:00000000_003FF7FF | | RE:00000000_003FF7FF RF:00000002_003FF7FF | +-----------------------------------------------+ |General Registers at time of error | +-----------------------------------------------+ | R0:00000000_03000001 R1:00000000_0002A000 | | R2:00000000_0002A000 R3:00000000_003FF7FF | | R4:00000000_02B67290 R5:00000000_003FF7FF | | R6:00000000_003FF7FF R7:00000000_00000000 | | R8:00000000_003FF7FF R9:00000000_003FF7FF | | RA:00000000_003FF7FF RB:00000000_00180700 | | RC:00000000_8B4056E2 RD:00000000_0E8688C0 | | RE:00000000_00000304 RF:00000000_00000000 | +-----------------------------------------------+ |Access Registers at time of error | +-----------------------------------------------+ |R0:00000000 R1:00000000 R2:00000001 R3:00000000| |R4:00000000 R5:00000000 R6:00000000 R7:00000000| |R8:00000000 R9:00000000 RA:00000000 RB:00000000| |RC:00000000 RD:00000000 RE:00000000 RF:00000000| +-----------------------------------------------+ *** END OF POTENTIAL VULNERABILITY REPORT *** zACS calls our FLUC-PC, the routine FLZXMR with an arbitrarily chosen R1, in the above case R1=0x00000000_0002A000, and, as expected, observes a 0C4 when accessing the FLZRQPDS structure. Incidentally, at the address 0x00000000_0002A801, which is exactly the centre of the addressed page. The faulty instruction is the one with the statement number 428 at offset 0x00000092, see also above: MODULE: PVTMOD=(FLZXMR,00000092), here with context: FLZXMR - Authorized PC Routine in Server A/S Page 11 Active Usings: FLZXMR+X'2',R12 WORKAREA,R13 Loc Object Code Addr1 Addr2 Stmt Source Statement HLASM R6.0 2025/04/29 21.23 388 * 389 * Locate original request area in 390 * secondary, save some important data 391 * in primary and issue GTRACE for 392 * "Eingang" event 393 * 000030 B249 0011 394 EREG R1,R1 Extract R1 from linkage stack 000034 1821 395 LR R2,R1 Copy into R2 000036 4100 0001 00001 396 LA R0,1 Load secondary's ALET value 00003A B24E 0020 397 SAR AR2,R0 Load into AR2 00003E 1700 398 XR R0,R0 Load primary's ALET value 000040 B24E 0040 399 SAR AR4,R0 Load into AR4 000044 B24E 00C0 400 SAR AR12,R0 Load into AR12 (program base) 000048 B24E 00D0 401 SAR AR13,R0 Load into AR13 (work area) 00004C 5020 D11C 0011C 402 ST R2,SASID_RQP_Address Save RQPDS's address in secondary R:2 00000 403 USING FLZRQPDS,R2 Tell assembler 000050 B279 0200 00200 404 SACF 512 Switch to AR mode 405 * 406 * Check if valid request, VSMLOC-check 407 * 000054 4170 004C 0004C 408 LA R7,Invalid_FLZR_Request_V Assume VSMLOC check negative 409 VSMLOC PVT, Verify VSM PVT allocation + AREA=((R2),FLZRQPDL), this area in this length + LINKAGE=SYSTEM generate basic PC 000058 1812 411+ LR 1,R2 ADDRESS OF AREA @L1C 01-VSMLO 00005A 5800 C83A 0083C 412+ L 0,=A(FLZRQPDL) LENGTH OF AREA 01-VSMLO 00005E B227 00F0 413+ ESAR 15 GET SECONDARY ASN 01-VSMLO 000062 90FC D010 00010 414+ STM 15,12,16(13) SAVE REGISTERS 01-VSMLO 000066 41F0 0003 00003 415+ LA 15,3(0,0) STORAGE TYPE 01-VSMLO 00006A 89F0 0018 00018 416+ SLL 15,24 POSITION STORAGE TYPE 01-VSMLO 00006E 58E0 0010 00010 417+ L 14,16(0,0) OBTAIN CVT ADDRESS 01-VSMLO 000072 58E0 E304 00304 418+ L 14,772(,14) ADDRESS OF SYSTEM LINKAGE TABLE 01-VSMLO 000076 58E0 E05C 0005C 419+ L 14,92(,14) OBTAIN PC NUMBER 01-VSMLO 00007A B218 E000 00000 420+ PC 0(14) PC TO VSMLOC ROUTINE 01-VSMLO 00007E 5820 D010 00010 421+ L 2,16(,13) RESTORE SECONDARY ASN 01-VSMLO 000082 B225 0020 422+ SSAR 2 RESTORE SECONDARY ASN 01-VSMLO 000086 982C D01C 0001C 423+ LM 2,12,28(13) RESTORE REGISTERS 01-VSMLO 00008A 12FF 424 LTR R15,R15 FLZRQPDS address valid ? (RC=00) 00008C A774 0255 00536 425 JNZ FLZXMR_15 No, pass RC=76 000090 1777 426 XR R7,R7 Clear intermediate RC again 427 * 000092 5830 20AC 000AC 428 L R3,FLZRLNTH Copy DATA's length from secondary 000096 4130 30B0 000B0 429 LA R3,FLZRQPDL(,R3) Add fixed part of FLZRQPDS We copy R1 to R2, base the FLZRQPDS structure on R2 and determine the total length (fixed plus variable) to copy the data from the secondary A/S (caller) to the primary A/S (server). To do this we load the variable length FLZRLNTH into R3 (0C4!) and add the fixed length with LA. We have made the following correction with ticket #87: * ---------+----------+---------------------------------------- * * 19.05.23 | FLZXMR | zACS Analyse (#87): zACS Check vom * * | | 28.04.2023 kritisiert den Zugriff auf * * | | das Laengenfeld FLZRLNTH als S0C4- * * | | gefaehrdet. In gleicher Weise besteht * * | | auch beim Zugriff auf das Acronym FLZR * * | | die Gefahr eines S0C4 Abends, wenn das * * | | Parameter-Register vom Caller ungueltig * * | | uebergeben wird. * * | | FLZXMR macht daher einen weiteren * * | | VSMLOC-Test auf die "black Box" der * * | | FLZRQPDS-Struktur. * * | | * * | | Test auf "Emergency-Close" von FLZPCR * * | | ESTAE-Routine. Setze dann RC=92, * * | | FLZSRV_Client_ABEND. * * | | * * | | Gemeinsame WORKAREA mit ESTAE/ARR FLZXRR, * * | | COPYBOOK FLZXWA (FLZXWA.inc, locally) * * | | * * ---------+----------+---------------------------------------- * That was my question when processing ticket #87: ‘I'm curious whether zACS recognises the VSMLOC coding. . .’. In Joachim's zACS test run from 5 Jun1 2023 this was probably the case. Under z/OS 3.1, zACS apparently no longer recognises the VSMLOC coding. This also applies to the second ‘POTENTIAL VULNERABILITY’: *** POTENTIAL VULNERABILITY FOUND IN PC 00180700 00000002 *** ABEND COMPLETION CODE: 0C4000 REASON CODE: 00000011 PSW: 470C1000 8B405552 MODULE: PVTMOD=(FLZXRR,0000005A) LIKELY EYECATCHER AT 0B4054F8:  .\......AD{.k...... ..&..&&.q#&.} INSTR LEN: 04 FAILING INSTR: 0020 B227 00F0 90FC D010 41F0 TRANSLATED INSTR: STM R15,R12,16(R13) TARGET ADDRESS CAUSING TRANSLATION EXCEPTION: 00000000_7FFFF400 HOME ASID: 002D PRIMARY ASID: 002C SECONDARY ASID: 002D HOME JOB: ZACSJ PRIMARY JOB: FALKSTC SECONDARY JOB: ZACSJ CVSS: 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) SLIP SAMPLE FOR PC 00180700 00000002: SLIP SET,ID=A001,COMP=0C4,P=(FLZXRR,0000005A),A=(SVCD,RECORD),END +-----------------------------------------------+ |General Registers before the service | +-----------------------------------------------+ | R0:00000000_003FF7FF R1:00000000_0002A000 | | R2:00000000_003FF7FF R3:00000000_003FF7FF | | R4:00000000_003FF7FF R5:00000000_003FF7FF | | R6:00000000_003FF7FF R7:00000000_003FF7FF | | R8:00000000_003FF7FF R9:00000000_003FF7FF | | RA:00000000_003FF7FF RB:00000000_00180700 | | RC:00000000_003FF7FF RD:00000000_003FF7FF | | RE:00000000_003FF7FF RF:00000002_003FF7FF | +-----------------------------------------------+ |General Registers at time of error | +-----------------------------------------------+ | R0:00000000_00000020 R1:00000000_00000000 | | R2:00000000_7F4412D8 R3:00000000_7F441960 | | R4:00000000_7F441570 R5:00000000_00000000 | | R6:00000000_00000000 R7:00000000_00000000 | | R8:00000000_00000000 R9:00000000_00000000 | | RA:00000000_00FD70F0 RB:00000000_00000000 | | RC:00000000_0B4054F8 RD:00000000_7FFFF000 | | RE:00000000_00FD7140 RF:00000000_0000002D | +-----------------------------------------------+ *** END OF POTENTIAL VULNERABILITY REPORT *** We are in the ARR recovery routine FLZXRR for the PC module FLZXMR, see above PVTMOD=(FLZXRR,0000005A). Again, zACS sets a register arbitrarily, this time R13 with 0x7FFFF000 and there is a 0C4 at 0x7FFFF400, in the first quarter of the 4K page. Here is the coding, statement 215 at offset 0x0000005A is criticised, and this is where the zACS analysis becomes strange: FLZXRR - ARR-type Recovery Routine for FLZXMR Page 8 Active Usings: SDWA,R2 SDWAPTRS,R3 SDWARC1,R4 FLZCOMDS,R11 FLZXRR,R12 WORKAREA,R13 R-Loc Object Code Addr1 Addr2 Stmt Source Statement HLASM R6.0 2025/04/29 22.02 208 * 209 print on,gen 210 VSMLOC PVT, Verify VSM PVT allocation + AREA=((R5),&LRIDS), this area in this length + LINKAGE=SYSTEM generate basic PC 000050 1815 212+ LR 1,R5 ADDRESS OF AREA @L1C 01-VSMLO 000052 4100 0020 00020 213+ LA 0,32(0,0) LENGTH OF AREA 01-VSMLO 000056 B227 00F0 214+ ESAR 15 GET SECONDARY ASN 01-VSMLO 00005A 90FC D010 00010 215+ STM 15,12,16(13) SAVE REGISTERS 01-VSMLO 00005E 41F0 0003 00003 216+ LA 15,3(0,0) STORAGE TYPE 01-VSMLO 000062 89F0 0018 00018 217+ SLL 15,24 POSITION STORAGE TYPE 01-VSMLO 000066 58E0 0010 00010 218+ L 14,16(0,0) OBTAIN CVT ADDRESS 01-VSMLO 00006A 58E0 E304 00304 219+ L 14,772(,14) ADDRESS OF SYSTEM LINKAGE TABLE 01-VSMLO 00006E 58E0 E05C 0005C 220+ L 14,92(,14) OBTAIN PC NUMBER 01-VSMLO 000072 B218 E000 00000 221+ PC 0(14) PC TO VSMLOC ROUTINE 01-VSMLO 000076 5820 D010 00010 222+ L 2,16(,13) RESTORE SECONDARY ASN 01-VSMLO 00007A B225 0020 223+ SSAR 2 RESTORE SECONDARY ASN 01-VSMLO 00007E 982C D01C 0001C 224+ LM 2,12,28(13) RESTORE REGISTERS 01-VSMLO 225 print on,nogen 000082 12FF 226 LTR R15,R15 RIDS valid ? (RC=00) 000084 A784 0004 0008C 227 JZ FLZXRR_3 Yes, go on 000088 0700 228 SETRP RC=00 No, Let RTM2 do her/his work Because, as you can easily see, the Store Multiple (STM) is part of the macro resolution of VSMLOC. And I think it is quite unlikely, if not impossible, that calling an IBM macro, especially VSMLOC (Verify(!) virtual storage Allocation), will result in a ‘POTENTIAL VULNERABILITY’ in the coding. And another subtle question: Why is the same STM instruction in the VSMLOC resolution not criticised in the FLZXMR above, where statement 414 is criticised at offset 0x00000062? *** We rate both issues as false positives of the new zACS tool and our customers are welcome to open a PMR with IBM.