Not the OP, but you can find quite a good collection of info at https://www.multicians.org/, specially interesting is the B2 Security Evaluation (https://www.multicians.org/b2.html) with the pearl that none of the UNIX known exploits, possible due to C's lack of safety where possible to take advantage of on Multics, thanks PL/I.
Sadly, a buffer overflow attack has been found; it is possible to write bad PL/I. (The defective code is a user-space tool, so at best, a remote code exploit. No privilege escalation.)
A writeup is on my round tuit list; some day soon.
PL/I does bounds checking on arrays, but not on pointers.
The Kermit server allocated an insufficiently large buffer to decompress packets into, and used ptrs to write to the buffer. (Errors 1 and 2: allocation and ptrs)
Later in the code, there is a 'goto state(idx)' construct, with a declaration like 'dcl state (0:6) label init (state0, state1, ....);'.
Which label is jumped to depends on the value of idx.
The 'state' variable was not declared to be state (error 3), so the table is in writable memory, and due to whatever circumstances, is above the decompress buffer.
A correctly crafted packet, when decompressed, will write over the end of the buffer and onto the state array. Later, when the goto is executed, the address transferred has been changed. It is not the case that a transfer can be made into the decompress buffer, as it is not in an executable segment, there are lots of places that could be transferred to, leaving open the possibility of an exploit.
The error was discovered when a particular file transfer would reliably crash the kermit server, and analysis of the crash uncovered the coding errors.
And what was the role of PL/I in Multics?