In September 2025, SAP had released a security bulletin [CVE-2025-42958] for the operating system IBM i in SAP Note 3627373. It delivered patches for all supported SAP kernel releases on IBM i (7.22, 7.53, and 7.54). A month later, SAP Host Agent 7.22, patch level 69 was released. It contained code to overcome the vulnerability also for SAP systems that did not have the patches of SAP Note 3627373 applied. When the SAP Host Agent is applied in patch level 69 or higher and an SAP kernel does not have the patch level of SAP Note 3627373, there are cases when ADM user profiles are made unusable, so that the related SAP system can no longer be started.

So, before you upgrade the SAP Host Agent to the current level, make sure that your SAP systems all use the kernel patch levels that are documented in SAP Note 3627373. If you cannot apply a stack kernel (SAPEXE.SAR) in the specified level or higher, be aware that you need to apply the ILE patch for the fix, not disp+work. If you follow this rule, you are done and should not see any problems with ADM. If you want to know more about the background, you can read on.

What is the background?

Prior to security bulletin [CVE-2025-42958], all ADM user profiles were owned by group profile R3GROUP. In addition to the R3GROUP authorities that came from the ownership, additional private authorities were granted for the ADM user profile itself, so that it could be used for signing on and for database connections. Sharing the ownership of all ADM user profiles through R3GROUP was considered unsafe, so the ILE patches of SAP Note 3627373 changed the ownership of ADM to itself when the patch was applied and the SAP system was started. With that change, the private authority for ADM was no longer needed and dropped, and R3GROUP has no longer authority to ADM. So far, no issue, everything is running fine. These changes were implemented in the CRTSAPUSR tool of the kernel.

With SAP Host Agent patch level 69, code was introduced to scan the whole system for user profiles that are still owned by R3GROUP. If their naming followed the pattern ADM or OFR, the ownership was changed to itself. This code is contained in program R3SAP400/SAPINIT and executed when the SAP Host Agent is installed or upgraded, or when the system is IPLed.

With those changes in place, all ADM user profiles should be owned by itself. However, if you still have a kernel at a patch level prior to SAP Note 3627373, and if you have SAPCPE activated (see SAP Note 1632754), an old version of CRTSAPUSR may be executed by process SAPILEDX that reverts the ownership of ADM from itself to R3GROUP. During this process, the private authority for ADM is not granted, so that further attempts to use the ADM are failing.

If you experience that problem and cannot upgrade to the required ILE patch level immediately, you can solve the problem temporarily by changing the ownership of ADM back to itself. Unfortunately, each time the kernel library SAPIND is touched (e.g. during a backup), SAPILEDX will be executed and the ownership would be changed back to the incorrect value R3GROUP. To prevent this from happening, you can create a data area named SUPPORT in the kernel library as described in SAP Note 1637588. The data area should be deleted automatically when you apply the required ILE patch through the APYSIDKRN tool, but to be on the safe side, you should verify this and delete the data area manually if required.

This is the command to change the owner back to ADM:

CHGOBJOWN OBJ(ADM) OBJTYPE(*USRPRF) NEWOWN(ADM) CUROWNAUT(*REVOKE)

This is the command to create the data area SUPPORT in order to avoid changing the ownership back by SAPILEDX:

CRTDTAARA DTAARA(SAPIND/SUPPORT) TYPE(*CHAR) LEN(1)

Please note that the above is just a workaround. The recommended solution is to apply the ILE patches of SAP Note 3627373 for all affected SAP systems.