Bug 1030142
| Summary: | glibc module 'crypt', function 'crypt' leads to segfaults and coredumps | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Heinz-Peter Heidinger <hph> |
| Component: | glibc | Assignee: | Carlos O'Donell <codonell> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | berni, codonell, fweimer, jakub, law, pfrankli, schwab, spoyarek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-09-29 11:09:17 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Heinz-Peter Heidinger
2013-11-14 02:03:31 UTC
*** Bug 1030118 has been marked as a duplicate of this bug. *** (In reply to Heinz-Peter Heidinger from comment #0) > Run till exit from #0 crypt (key=0x7ffffffefbc0 " 2301152\032", > salt=0x7ffffffefbc0 " 2301152\032") at crypt-entry.c:164 > 0x0000000000685ad6 in psCreateCryptoKey(unsigned char*, char*) () > Value returned is $1 = 0x0 In glibc 2.17 the crypt function implementation was tightened up to allow for future implementation improvements, standards conformance, and FIPS compliance. From the 2.17 NEWS: * The `crypt' function now fails if passed salt bytes that violate the specification for those values. On Linux, the `crypt' function will consult /proc/sys/crypto/fips_enabled to determine if "FIPS mode" is enabled, and fail on encrypted strings using the MD5 or DES algorithm when the mode is enabled. In this particular case the salt is an invalid POSIX salt that contains an ASCII space " " in character 0 outside of the allowed alphabet for salts which is `./0-9a-zA-Z' and therefore crypt will reject that salt as invalid, return NULL, and set errno. Previous to glibc 2.17 a call to crypt would accept invalid POSIX salts. You have a couple of options: * Fix the caller to pass a valid POSIX salt and/or ensure that you check the return of crypt for a NULL return. * Preload a shared library with a custom implementation of crypt that supports non-POSIX salts. * Preload a shared library with a wrapper for crypt which fixes up the salt inputs and then uses RTLD_NEXT to call the real crypt with the new arguments. Does that answer your question? Upstream TSM bug: http://www-01.ibm.com/support/docview.wss?uid=swg1IC92662&myns=apar&mynp=DO IC92662: TSM CLIENT CAN CRASH WITH CERTAIN NODENAMES ON LINUX DISTRIBUTIONS IF USING GLIBC 2.16 OR HIGHER IN THE FUTURE APAR status Closed as program error. Error description A code defect has been detected in the TSM Linux x86 client. While it does not manifest today in any currently-supported Linux distributions, here would be the symptom: When PASSWORDACCESS is set to GENERATE, TSM Linux client could crash when trying to read or write the password file. This will happen when installed glibc is version 2.16 or higher, and only with certain node names. It is not possible to identify the node name pattern triggering the issue. The crash can occur on short and long names, with and without non-alpha characters. However, when the failing combination of characters is used as the node name, the problem is consistently recreatable. One class of node names known to trigger the issue are the names of 3 symbols or less. For example, ABC, F35, R2 etc. An example of a longer node name is LINUX-123456 Since currently-supported RedHet and SuSE distributions do not yet support this Glibc level, there is no current error. However, this APAR is being opened to address the potential future issue when that Glibc level is supported. Local fix One of the following workarounds can be used: 1. Downgrade glibc to version 2.15 or lower, if possible. 2. Change the node name. In most cases, adding, deleting or modifying a single character is sufficient. 3. Set PASSWORDACCESS to PROMPT and add PASSWORD option to your dsm.sys options file. Make sure to restrict file system access to dsm.sys so non-authorized users can't see the node password. Problem summary **************************************************************** * USERS AFFECTED: All clients versions 6.3 and 6.4 running * * on Linux platforms with glibc version 2.16 * * or higher. * **************************************************************** * PROBLEM DESCRIPTION: See ERROR DESCRIPTION. * **************************************************************** * RECOMMENDATION: Apply fixing level when available. This * * problem is currently projected to be fixed * * in levels 6.3.2 and 6.4.2. Note that until * * these levels are available, this * * information is subject to change at the * * discretion of IBM. * **************************************************************** * Problem conclusion The problem has been fixed so that it no longer occurs. As Bernhard Schmidt stated above: This bug vanished with TSM-Client version 6.4.2.0 (maintenance release) for linux X64. I tried this a some weeks ago (Aug/2014) with the recent kernel in Fedora at that time (3.15.xxx) and everything was working fine - as before ... Fixed in third-part application, not a bug in glibc. |