Bug 58646 - Risky variable declaration inside a macros may cause segmentation fault
Risky variable declaration inside a macros may cause segmentation fault
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: mm (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-22 04:06 EST by Denis
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-22 04:06:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Denis 2002-01-22 04:06:09 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Description of problem:
The package mm contains the header file mm.h. There is a bug in mm.h. By the 
way, this header file is installed into the directory /usr/include where 
standard header files are. 
mm.h contains macro versions of the standard functions memset and memcpy, and 
may declare these macros instead of the real functions in some conditions. See 
the lines 119-130 of mm.h:

#if !defined(HAVE_MEMCPY)
#if defined(HAVE_BCOPY)
#define memcpy(to,from,len) bcopy(from,to,len)
#else
#define memcpy(to,from,len) \
        { int i; for (i = 0; i < (len); i++) *(((char *)(to))+i) = *(((char *)
(from))+i); }
#endif
#endif
#if !defined(HAVE_MEMSET)
#define memset(to,ch,len) \
        { int i; for (i = 0; i < (len); i++) *(((char *)(to))+i) = (ch); }
#endif

You can see that the variable "i" is declared inside the macros. It is risky. 
For example, this causes a real problem if trying to build the package mm not 
by the standard GNU C/C++ compiler (gcc) but the Intel C/C++ compiler (icc). 
For gcc, the script "configure" makes HAVE_MEMCPY and HAVE_MEMSET defined so 
that the macros are not declared. For icc, they are declared. (In future 
versions of icc, this may change.) Then mm_test.c is built, run and then 
crashes emitting the message "Segmentation fault". The problem is that 
mm_test.c calls memset in the following way (line 225):
memset(cp[i], 0xF5, (i+1)*(i+1));
You can see that this macro call will be preprocessed into the following 
erroneous code:
{ int i; for (i = 0; i < ((i+1)*(i+1)); i++) *(((char *)(cp[i]))+i) = (0xF5); };


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


How reproducible:
Always

Steps to Reproduce:
If you don't have Intel compiler (icc) you are unable to reproduce the problem. 
This compiler is not free. If you really need it to fix the problem, let me 
know and I'll try to help you. If you have the compiler, the steps to reproduce 
the problem will be the following:
1. Make sure that all environment necessary for icc is set.
2. Make sure that icc will be called instead of gcc, g++, cc, cpp and c++. I 
recommend you make links to icc with these names, put them into some directory 
and add this directory to the beginning of the PATH variable.
3. Install the package mentioned above from the .src.rpm file (-i option of 
rpm). Make sure you have enough permissions to do that.
4. Try to build the .spec file (-bc option of rpm).


Actual Results:  The package won't build. In the output (somewhere near the 
end), you may see the message "Segmentation fault". 


Expected Results:  The package should build Ok and print the following in the 
end:
OK - ALL TESTS SUCCESSFULLY PASSED.


Additional info:

I would recommend you to substitute "__i" for "i" in the macro definitions. As 
far as I know, the prefix "__" is reserved for standard headers and user is not 
expected to start his/her variable names with "__".
Comment 1 Nalin Dahyabhai 2002-07-24 15:07:06 EDT
These macros appear to be defined in the private section of the header, and
shouldn't be processed at all unless MM_PRIVATE has been defined at
compile-time.  I'm inclined to close this bug and tag it "won't fix" because I
don't see how this could happen if the header were used properly.

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