Patch Name: PHCO_29702 Patch Description: s700_800 11.04 (VVOS) csh(1) cumulative patch Creation Date: 03/09/23 Post Date: 03/10/28 Hardware Platforms - OS Releases: s700: 11.04 s800: 11.04 Products: N/A Filesets: OS-Core.CMDS-MIN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP VirtualVaultOS.VVOS-AUX-IA,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP Automatic Reboot?: No Status: General Release Critical: Yes PHCO_29702: ABORT OTHER Based on HP-UX Patch PHCO_28346: ABORT Based on HP-UX Patch PHCO_27763: ABORT Based on HP-UX Patch PHCO_24146: OTHER csh does not handle the ~operator option correctly. Category Tags: defect_repair general_release critical halts_system Path Name: /hp-ux_patches/s700_800/11.X/PHCO_29702 Symptoms: PHCO_29702: Ported HP-UX patch PHCO_28346 to VVOS Based on HP-UX patch PHCO_28346: 1. csh(1) dumps core when a multibyte string of size greater than 4118 character is passed to builtin echo. Based on HP-UX patch PHCO_27763: 1.csh(1) misbehaves when the file system is full. ), and behaves inconsistantly if erase character is > 0x20. 3.csh(1) has problems when just the right number of file descriptors are open at the time it is invoked. Based on HP-UX patch PHCO_26014: 1.csh(1) intermittently gives the error message "invalid multibyte character" when multibyte characters, which are got as a result of evaluating an expression using ``(backquotes)are passed to it. Based on HP-UX patch PHCO_24146: 1.csh(1) fails to expand bracket expressions correctly. 2.csh fails with input redirection involving ~username. 3.csh fails with output redirection involving ~username. 4.csh -xv terminates with "out of memory" for scripts of size > 1GB. 5.csh(1) does not create, start of header code correctly. 6.Read from the pipe fails in csh(1) scripts when SIGWINCH is sent to it. Based on HP-UX patch PHCO_19435: 1. When maxssiz is set to 2,000,000, csh aborts with core dump. 2. csh does not sort globbed output when using multi-byte NLS. 3. csh file globbing does not find >2Gb file. 4. csh file enquiries like if ( -f filename ) fail for large (>=2GB) files. 5. ~ expansion fails with csh. 6. csh does not handle pwd correctly on LOFS(Loopback File System) mount. 7. csh doesn't handle SIGWINCH well. 8. Pattern match fails in case statement. 9. Setting LC_ALL to some locale has no effect on the messages being displayed. 10.csh(1) does not handle file name globbing correctly. 11.csh(1) does not handle '\0' character in backtick substitution. 12.csh(1) does not interpret the left shift operator when it is given in the if-then-else statements. 13.csh(1) doesn't compare multibyte characters correctly in utf8. PHCO_18672: Ported HP-UX patch PHCO_16149 to VVOS Based on HP-UX patch PHCO_16149: what string of /usr/bin/csh was wrong after installation of patch PHCO_14084. Based on HP-UX patch PHCO_14084: Missing "critical" in the Category Tags field of the previous patch PHCO_13217. Based on HP-UX patch PHCO_13217: csh(1) is not able to expand wildcard characters when it's used with quote characters. For example, ls "/bin"/* in csh gives /bin/: not found eventhough the directory /bin/ exists in a system. Defect Description: PHCO_29702: Ported HP-UX patch PHCO_28346 to VVOS Based on HP-UX patch PHCO_28346: 1. If a multibyte string of size greater than 4118 characters is passed to builtin echo then csh(1) dumps core. Problem can be reproduced using the below script: $ cat test.sh #!/usr/bin/csh setenv LANG ja_JP.SJIS set i=0 set NAME= while (( $i < $1)) set NAME=${NAME}"A" i++ end echo $NAME $ ./test.sh 4118 Illegal instruction(coredump) We were using a wide character buffer of size 4096 bytes to store the wide character converted input multibyte string. In the above case the converted wide character string was exceeding the buffer size resulting in core dump. Resolution: csh(1) has been modified to allocate memory dynamically for the buffer based on the input multibyte string length. Based on HP-UX patch PHCO_27763: 1.csh(1) misbehaves when the file system is full. Resolution: Problem has been fixed. 2.In csh code, on receiving control characters (0 to 0x20 and 0177) all the multibyte characters left in the input buffer are converted into wide characters. While processing the kill and erase characters the code assumed that all the characters in the input buffer got converted to wide characters. But this was not the case as the value of kill and erase characters is greater than 0x20 and not equal to 0177. This resulted in buffer underflow. The problem can be reproduced as follows: 1.$ export LANG=ja_JP.SJIS 2.$ /usr/bin/csh Memory fault(coredump) Resolution: Now the code is modified to convert all the multibyte characters in the input buffer to wide chars even in the case of kill and erase characters. 3.csh creates some fixed file descriptors for its use. These fixed file descriptors are used instead of the usual 0,1,2. At some point of time when a catalog file descriptor is initialised , it coincides with one of the fixed file descriptors. When the catalog file descriptor gets closed, one of the fixed file descriptor gets closed. The problem can be reproduced as follows: 1. Create a c program $ cat open_test.c #include #include #include #include extern int errno ; void main() { FILE *fp ; int i ,j ,ret ; for(i=0; i<20; i++) { printf("***** count=%d\n", i) ; errno = 0 ; ret = system("./test.csh") ; if( !(fp = fopen("temp.txt", "r")) ) { printf("*fopen error %d \n", errno) ; exit(1); } if((ret = unlink("temp.txt"))) printf("remove error ret=%d errno=%d\n", ret, errno) ; } } 2. compile the above program cc -o open_test -O open_test.c 3. Create a test.csh cat > test.csh #! /usr/bin/csh ls -l > "temp.txt" 4. Invoke csh as a login shell 5. setenv LANG C 6. Execute open_test 7. open_test gives "*fopen error 2". Resolution: The code has been modified to ensure that the catalog file descriptor will take the value other than the fixed file descriptors. Based on HP-UX patch PHCO_26014: 1. When multibyte characters, which are got as a result of evaluating an expression using `` (backquotes) are passed to csh(1), it gives an error message "backeval(1): Invalid multibyte character" intermittently. One can re-produce the problem as follows : $ cat multibyte.c #include main() { int i, j; unsigned char buf[10], ch; strcpy(buf, "?"); for (i=0; i<10; i++) { for (j=0; j<4; j++) write(1, &(buf[j]), 1); } ch = '\n'; write(1, &ch, 1); } $ cc multibyte.c -o multibyte $ export LANG=ja_JP.SJIS $ cat xxx.csh #!/usr/bin/csh set variable = `echo "?" ` echo $variable set variable = `./multibyte` echo $variable $ ./xxx.csh ? backeval(1): Invalid multibyte character. Resolution : When reading through pipes, sometimes, all the characters of a multi-byte may not be read immediately by the process and there will be a delay in receiving few characters of a multi-byte. This was resulting in an incomplete read and when the characters returned through pipes did not form a valid multi-byte(some characters still arriving), csh(1) was returning "invalid multi-byte" character. To address this problem, the process which reads the data through pipe, will read the pipe multiple times(instead of previous one time) and it is assumed that all the data will have arrived by the time a second read of the pipe is done. Even after reading multiple times, if there is no data and the data obtained from earlier results in an invalid multibyte, csh(1) continues to report the error message. Based on HP-UX patch PHCO_24146: 1. csh(1) fails to expand bracket expressions correctly. For example, csh(1) expands [ab] to NULL , a ,b which is incorrect. It should match either a or b. Resolution: Problem was due to storing of matching patterns. It is fixed to resolve the problem. 2. csh(1) input redirection does not work correctly with ~ operator. Resolution: csh(1) wrongly assumes that file descriptors 0, 1 and 2 are closed. But the underlying layer keeps them open and this caused the problem.Now the file descriptors are closed to fix the problem. 3. The csh(1) output redirection does not work correctly with the ~ operator. Resolution: csh(1) wrongly assumes that file descriptors 0, 1 and 2 are closed. But the underlying layer keeps them open and this caused the problem.Now the file descriptors are closed to fix the problem. 4.csh(1) dies and gives error message "out of memory" when cat | csh -xv option is used , when is large. This problem is basically caused due to memory leak in csh(1) while doing a buffered read/write. Problem occurs only when handling large files as the memory allocated for csh(1) is exhausted due to memory leak. Resolution: Now, memory leak is fixed to avoid "Out of memory" error. 5."echo ^A" csh does not create start of header code correctly. Resolution: When ^A occurs, it is quoted with another ^A so that start of the header is recognized properly. 6.Read from the pipe fails in csh(1) scripts when SIGWINCH is sent to it. When the csh(1) received a SIGWINCH while reading using the read(2) system call , it handled the signal, but failed to restart the read(2), which returned with no bytes read.Since the errno wasn't checked for EINTR, csh(1) erroneously assumed to have received an EOF from the pipe, and prematurely closes the pipe thus resulting in SIGPIPE. Resolution: Problem is fixed by registering signal handler for SIGWINCH using sigaction(3C) with SA_RESTART flag instead of signal(3C). This will make sure to restart any call that is interrupted due to SIGWINCH. Since read(2) gets restarted, data is read from the pipe completely thus avoiding SIGPIPE. Also return value as well as error codes for read(2) are checked. Based on HP-UX patch PHCO_19435: 1. When the stack size(maxssiz) is set to 2,000,000 or less, csh dumps core on executing the command, echo "hello" . 2. In multi-byte NLS environment, for example LANG=ja_JP.SJIS and LANG=ja_JP.eucJP, csh(1) is not sorting the globbed output correctly. 3. csh(1) is not handling the wildcard characters for large files(>2GB). For example : ls */sparse, where "sparse" is a large file displays "sparse not found". 4. The execution of "if (-f filename)" fails in a csh script, if "filename" is a large file(>=2GB). 5. 11.00 csh(1) closes stderr if argument to a command contains ~. 6. In a loopback file system (LOFS), the 'pwd' command returns with "no such file or directory" in csh(1). 7. csh(1) does not handle "SIGWINCH" properly . It gives a Bus error(core dumped) or Signal 16. 8. Pattern matching fails because csh(1) compares the wchar_t value of the characters and is not considering the collation sequence. 9. csh(1) doesn't call setlocale() when setting LC_ALL , this results in messages not being displayed properly. 10.csh(1) is not handling NULL characters properly ,which causes incorrect filename globbing . 11.Due to inappropriate handling of NULLS, csh(1) give errors in backtick substitution. 12.csh(1) wrongly incorporates bit shift operators(<<) as here-document when the operator(<<) is not used in if-then-else. 13.csh(1) doesn't handle comparison of multibyte characters. This results in bad filename pattern match in utf8. Resolution: 1. The problem was occuring because the header file, was redefining the actual value of NCARGS in "sh.local.h". The value of NCARGS in is a large value(20,48,000) as compared to the value in "sh.local.h"(10240). So, when the stack size is set to 2MB or less and trying to allocate space for 20,48,000 in the stack frame results in a core dump. Henceforth, including "sh.local.h" after solves the issue. 2. This problem was due to {} mismatch. Adding the {} braces at appropriate places solves the problem. 3. The system call "stat" was failing for >2GB files. So, replacing the stat call with stat64 call solves the problem. 4. The system call "stat" was failing for >2GB files. So, replacing the stat call with stat64 call solves the problem. 5. The fds(stdin, stdout, stderr) are being kept open before making the call to getpwnam(). Closing the above mentioned fds in csh(1) before making a call to getpwnam() solves the problem. 6. Changing the local function call, getworkdir() to libc call,getcwd() solves the problem. 7. The problem was that csh(1) was not blocking the signal SIGWINCH in certain critical regions of code like vfork(). So holding and releasing SIGWINCH at appropriate places solves the problem. 8. csh(1) has been changed so that it now calls strcoll() to compare characters. The strcoll() looks for the collation order of the characters and not its wchar_t values. PHCO_18672: Ported HP-UX patch PHCO_16149 to VVOS Based on HP-UX patch PHCO_16149: The previous patch PHCO_14084 was created with wrong patch tag. Based on HP-UX patch PHCO_14084: Missing "critical" in the Category Tags field of the previous patch PHCO_13217. Based on HP-UX patch PHCO_13217: csh(1) is not able to expand wildcard characters when it's used with quote characters. For example, ls "/bin"/* in csh gives /bin/: not found even though Enhancement: No SR: 8606286981 8606242998 8606181552 8606259489 8606105829 8606225988 8606225986 8606163608 8606163597 8606152261 8606110562 1653241323 1653230813 8606114866 1653309260 1653308668 1653257584 1653205583 8606100262 1653308023 8606102436 1653282509 1653285858 5003444554 4701418301 1653295451 8606102437 5003438903 1653276535 1653255398 1653258566 8606102992 4701374884 5003392464 Patch Files: OS-Core.CMDS-MIN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/bin/csh VirtualVaultOS.VVOS-AUX-IA,fr=B.11.04, fa=HP-UX_B.11.04_32/64,v=HP: /etc/auth/system/files.fcdb/05.patches/29702_PHCO.fcdb what(1) Output: OS-Core.CMDS-MIN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/bin/csh: $Revision: Hewlett-Packard ISSL Level vvos_rose42 $ $Header: Hewlett-Packard ISSL Release vvos_r ose $ $Date: Fri Oct 17 13:20:17 EDT 2003 $ $Source: cmd/csh/sh.func.c, hpuxcmdsh, vvos_rose $ $ Date: 03/10/22 06:38:38 $ $Revision: 1.3 PAT CH_11.04 (PHCO_29702) $ $Revision: 82.5 $ VirtualVaultOS.VVOS-AUX-IA,fr=B.11.04, fa=HP-UX_B.11.04_32/64,v=HP: /etc/auth/system/files.fcdb/05.patches/29702_PHCO.fcdb: $Revision: Hewlett-Packard ISSL 1.1 etc/auth/system/ files.fcdb/05.patches/29702_PHCO.fcdb, hpuxp atch, vvos_rose, rose0327 $ $Date: 03/10/09 08:01:45 $ cksum(1) Output: OS-Core.CMDS-MIN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: 325448807 163840 /usr/bin/csh VirtualVaultOS.VVOS-AUX-IA,fr=B.11.04, fa=HP-UX_B.11.04_32/64,v=HP: 1741524307 448 /etc/auth/system/files.fcdb/05.patches/ 29702_PHCO.fcdb Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHCO_18672 Equivalent Patches: PHCO_28346: s700: 11.00 s800: 11.00 Patch Package Size: 120 KBytes Installation Instructions: Please review all instructions and the Hewlett-Packard SupportLine User Guide or your Hewlett-Packard support terms and conditions for precautions, scope of license, restrictions, and, limitation of liability and warranties, before installing this patch. ------------------------------------------------------------ 1. Back up your system before installing a patch. 2. Login as root. 3. Copy the patch to the /tmp directory. 4. Move to the /tmp directory and unshar the patch: cd /tmp sh PHCO_29702 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHCO_29702.depot By default swinstall will archive the original software in /var/adm/sw/save/PHCO_29702. If you do not wish to retain a copy of the original software, include the patch_save_files option in the swinstall command above: -x patch_save_files=false WARNING: If patch_save_files is false when a patch is installed, the patch cannot be deinstalled. Please be careful when using this feature. For future reference, the contents of the PHCO_29702.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHCO_29702.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHCO_29702.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None