[ros-bugs] [Bug 3593] New: char comparision out of range in tcpsvcs

[ReactOS.Bugzilla at www.reactos.org]

http://www.reactos.org/bugzilla/show_bug.cgi?id=3593

           Summary: char comparision out of range in tcpsvcs
           Product: ReactOS
           Version: TRUNK
          Platform: x86 Hardware
        OS/Version: ReactOS
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: Networking
        AssignedTo: ros-bugs at reactos.org
        ReportedBy: mslomp at linuxmail.org
         QAContact: ros-bugs at reactos.org


chargen.c::GenerateChars

since charIndex starts in 0, the highest index reached by chars is [ASCII_END -
ASCII_START - 1].
in another words, chars[0] = ASCII_START and chars[NUM_CHARS - 1] = ASCII_END.
this way, following the definition of NUM_CHARS, the comparision with
chars[NUM_CHARS] may:
- never be true
- fail even for the highest ascii char
- cause a segfault while accessing an invalid memory address.

another reason for this is that charIndex never will be equal to NUM_CHARS,
because a previous if statement break this situation:

if (loopIndex == NUM_CHARS)
  loopIndex = 0;
charIndex = loopIndex;
...

notice that GCC 4.3+ series already catches this pitfall inside nested loops,
while the one bundled in RosBE allows the compilation without at least a
warning.
Follows a patch to fix this issue.

Regards,
Marcelo A. B. Slomp


Index: base/services/tcpsvcs/chargen.c
===================================================================
--- base/services/tcpsvcs/chargen.c     (revision 34816)
+++ base/services/tcpsvcs/chargen.c     (working copy)
@@ -74,7 +74,7 @@
             line[i] = chars[charIndex];

             /* if we hit the end char, reset it */
-            if (chars[charIndex] == chars[NUM_CHARS])
+            if (chars[charIndex] == chars[NUM_CHARS - 1])
                 charIndex = 0;
             else
                 charIndex++;


-- 
Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.