Bug 469495 - procps string size issue
procps string size issue
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: procps (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Daniel Novotny
Depends On:
Blocks: 498182
  Show dependency treegraph
Reported: 2008-11-01 10:57 EDT by Steve Grubb
Modified: 2010-03-30 04:06 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 498182 (view as bug list)
Last Closed: 2010-03-30 04:06:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch fixing problems described herein (446 bytes, patch)
2008-11-01 10:59 EDT, Steve Grubb
no flags Details | Diff

  None (edit)
Description Steve Grubb 2008-11-01 10:57:10 EDT
Description of problem:
proc/devname.c has an array that is 4 characters wide that is trying to hold strings that are 5 bytes wide, like "AM12". I will attach a patch fixing this. 

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

Additional Info:
fedora has the same problem.
Comment 1 Steve Grubb 2008-11-01 10:59:49 EDT
Created attachment 322171 [details]
patch fixing problems described herein

This patch widens the strings so they have the NUL terminator. Please apply to RHEL when the opportunity hits and to Fedora at first chance. Thanks!
Comment 2 Daniel Novotny 2009-04-29 06:45:39 EDT
thanks for the patch, cloned this to Fedora (bug #498182)
Comment 3 Albert Cahalan 2009-05-03 02:45:50 EDT
Not a bug.

This is one of the differences between C and C++. The strings are in fact exactly the size requested. Unlike a C++ compiler, a C compiler will respect the programmer's wishes.

The "strings" are of course lacking the typical NUL byte in some cases. This is correctly handled by the code.
Comment 4 Steve Grubb 2009-05-03 15:38:27 EDT
Is a bug. :) Try this simple test:

#include <stdio.h>
#include <string.h>

int main(void)
        char array[3][4] = { "123", "4567", "890" };
        int i;

        for (i=0; i<3; i++)
                printf("string %d, \"%s\", len=%d\n", i, array[i],
        return 0;

This is what you get:
string 0, "123", len=3
string 1, "4567890", len=7
string 2, "890", len=3
Comment 5 Steve Grubb 2009-05-03 16:10:33 EDT
This is where the array gets used:

    if(min >= sizeof low_density_names / sizeof low_density_names[0]) return 0;
    sprintf(buf, "/dev/tty%s",  low_density_names[min]);

If the sprintf had something like %.3s as the format specifier, it would handle the string overrun correctly. This goes into a buffer, tmp that is TTY_NAME_SIZE, which is 128 bytes. So there is no security issue here. The issue is that some of the names are unusable due to the string size issue. The names AM10 - 15 and SMX0 - 3 would be affected.
Comment 6 Albert Cahalan 2009-05-10 01:59:26 EDT
(In reply to comment #5)
> This is where the array gets used:
>     if(min >= sizeof low_density_names / sizeof low_density_names[0]) return 0;
>     sprintf(buf, "/dev/tty%s",  low_density_names[min]);

I thought 3.2.7 had the current (in CVS) code, but it doesn't.
Somehow this change didn't get into the 3.2.8 release notes.
The current code uses memcpy.
Comment 9 Daniel Novotny 2009-11-19 09:40:50 EST
fixed in procps-3.2.7-12.el5
Comment 10 Daniel Novotny 2009-11-19 10:09:09 EST
hello Steve, is there an reproducer of the bug available, in order to test the erratum?
Comment 12 Steve Grubb 2009-11-19 10:22:02 EST
You would need to have a system that has "Low-density serial ports" dev major 204 and run a program that would report the dev name. You would need to be on one of the following devices: "AM10", "AM11", "AM12", "AM13", "AM14", "AM15", "SMX0",  "SMX1",  "SMX2".

Hope this helps...
Comment 15 errata-xmlrpc 2010-03-30 04:06:42 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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