Bug 145167 - unix2dos segfaults with -n switch
unix2dos segfaults with -n switch
Status: CLOSED DUPLICATE of bug 153079
Product: Fedora
Classification: Fedora
Component: unix2dos (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-14 17:02 EST by Jon Salz
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-12 09:56:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to fix gcc warnings (2.28 KB, patch)
2005-01-15 07:06 EST, Sitsofe Wheeler
no flags Details | Diff

  None (edit)
Description Jon Salz 2005-01-14 17:02:32 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 
7.54  [en]

Description of problem:
unix2dos -n segfaults whenever the -n switch is used.  This problem 
was not present in unix2dos-2.2-21.

Version-Release number of selected component (if applicable):
unix2dos-2.2-24

How reproducible:
Always

Steps to Reproduce:
echo foo > foo.txt
unix2dos -n foo.txt foo.txt.dos
    

Actual Results:  unix2dos: converting file foo.txt to file foo.txt.
dos in DOS format ...
zsh: segmentation fault  unix2dos -n foo.txt foo.txt.dos


Additional info:

unix2dos-2.2-24
glibc-2.3.3-74
Linux lrrr 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 i686 
i686 i386 GNU/Linux
Comment 1 Sitsofe Wheeler 2005-01-15 06:21:37 EST
(The debuginfo package would be more useful if the specfile compiles unix2dos
with -g option)

I quite like these clear, "small" bugs as they are easy to find with valgrind.
Speaking of valgrind:
unix2dos: converting file foo to file foo.txt.dos in DOS format ...
==5795== Use of uninitialised value of size 4
==5795==    at 0x1B902434: strcpy (mac_replace_strmem.c:198)
==5795==    by 0x8048E46: ConvertUnixToDosNewFile (unix2dos.c:253)
==5795==    by 0x8049794: main (unix2dos.c:510)
==5795==
==5795== Conditional jump or move depends on uninitialised value(s)
==5795==    at 0x1B90244B: strcpy (mac_replace_strmem.c:72)
==5795==    by 0x8048E46: ConvertUnixToDosNewFile (unix2dos.c:253)
==5795==    by 0x8049794: main (unix2dos.c:510)
==5795==
==5795== Conditional jump or move depends on uninitialised value(s)
==5795==    at 0x1B90246A: strcpy (mac_replace_strmem.c:81)
==5795==    by 0x8048E46: ConvertUnixToDosNewFile (unix2dos.c:253)
==5795==    by 0x8049794: main (unix2dos.c:510)
==5795==
==5795== Conditional jump or move depends on uninitialised value(s)
==5795==    at 0x1B90247F: strcpy (mac_replace_strmem.c:69)
==5795==    by 0x8048E46: ConvertUnixToDosNewFile (unix2dos.c:253)
==5795==    by 0x8049794: main (unix2dos.c:510)

The problem arises in the following:
  char *TempPath;
  struct stat StatBuf;
  struct utimbuf UTimeBuf;
  int fd;

  /* retrieve ipInFN file date stamp */
  if ((ipFlag->KeepDate) && stat(ipInFN, &StatBuf))
    RetVal = -1;

  strcpy (TempPath, "./u2dtmpXXXXXX");
  if((fd = MakeTempFileFrom (ipOutFN, &TempPath)) < 0) {

TempPath is not pointing to allocated memory for strcpy to copy into. Further
MakeTempFileFrom only uses TempPath to return a string - it NULLs the pointer
passed in early on so assinging anything to TempPath before calling it seems
useless. Removing the strcpy seems to fix the problem.
Comment 2 Sitsofe Wheeler 2005-01-15 07:04:04 EST
I was just about to add a patch when I noticed that this problem appears to be
due to a change in unix2dos-2.2-tmppath.patch . On line 59 of the patch, when
TempPath[16] was changed to *TempPath the strcpy was broken but this is not a
big deal because the strcpy is no longer needed because of the change to use
MakeTempFileFrom.
Comment 3 Sitsofe Wheeler 2005-01-15 07:06:03 EST
Created attachment 109817 [details]
Patch to fix gcc warnings

A small patch that adds brackets to quieten gcc. The binary compiled is
identical to the one without brackets and I'm fairly sure the logic is correct
because the line format effectively suggests how the expression was meant to be
read.
Comment 4 Tim Waugh 2005-04-12 09:56:00 EDT

*** This bug has been marked as a duplicate of 153079 ***

Note You need to log in before you can comment on or make changes to this bug.