IT17058: SIGSEGV in xtrWriteTraceHeader if MQ trace is on, and getpwuid call fails

APAR status

• Closed as program error.

Error description

• MQ called getpwuid to find a username to write in the header at
  the top of an MQ trace file.
  
  Something was wrong in the user/group subsystem causing the
  getpwuid call to fail even though the uid being queried had been
  returned from geteuid a moment beforehand.
  
  Immediately after the failed getpwuid call, the MQ code used a
  null pointer, which caused a SIGSEGV, which caused a core file
  from the user's process, and the ending of the process.
  
  The underlying root cause of such a problem is external to MQ.
  
  But MQ should not cause a memory exception when it happens.
  
  In addition, some separate errors may be seen written in FDC
  files from other parts of MQ with the same underlying reason
  within the user/group database.
  Example:
  PROBE ID:  XY051170
  Comment1 :- xcsGetpwuid failed to get password entry for process
  Comment2 :- Details: getuid() returned 41668358;
  getpwuid_r(41668358) failed with errno=0.
  Comment3 :- A user name of "UNKNOWN" will be used, which will
  likely cause later authorisation failures. Note this FFST can be
   turned off by exporting env var AMQ_NOFFST_PROCESS_UID.
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  Users who are switching on MQ trace, and have a serious problem
  in their user/group database causing getpwuid to fail for a uid
  that the OS has just returned via getuid or geteuid.  This
  problem has only been seen on a system where the user/group
  database was managed externally from the local operating system.
  
  
  Platforms affected:
  AIX, HP-UX Itanium, Linux on Power, Linux on x86, Linux on
  x86-64, Linux on zSeries, Solaris SPARC, Solaris x86-64
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  The root cause of such a problem is external to MQ.  But MQ
  should not have caused a memory exception when it happens, this
  was due to an incorrect pointer access within MQ when handling
  the external error.
  

Problem conclusion

• The MQ product code has been changed to ensure that a null
  pointer is not used in this failure scenario.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v8.0       8.0.0.6
  v9.0 CD    9.0.4
  v9.0 LTS   9.0.0.1
  
  The latest available maintenance can be obtained from
  'WebSphere MQ Recommended Fixes'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
  
  If the maintenance level is not yet available information on
  its planned availability can be found in 'WebSphere MQ
  Planned Maintenance Release Dates'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
  ---------------------------------------------------------------
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  WMQ BASE MULTIP

• Fixed component ID

  5724H7251

Applicable component levels

• R800 PSY

     UP