177336 - File name buffer may not be large enough

Status: NEW

(NSPR :: NSPR, defect)

Description

[Wan-Teh Chang]

In mozilla/nsprpub/pr/src/linking/prlink.c, we have:

    char                  cName[64];
...
        FSSpec fileSpec;
...
        memcpy(cName, fileSpec.name + 1, fileSpec.name[0]);
        cName[fileSpec.name[0]] = '\0';

The FSSpec structure is defined as:

struct FSSpec {
    SInt16 vRefNum; 
    SInt32 parID; 
    StrFileName name;
};

and StrFileName is defined as:

typedef Str255 StrFileName;

This seems to mean that fileSpec.name can be 255
character long, and the cName buffer, which can
only hold a 63 character string, may not be large
enough.

Is my understanding correct?

If my understanding is correct, the fix would be:
1. Declare cName as:

    char                  cName[256];

2. For extra protection, check that fileSpec.name[0]
is less than 256 before copying fileSpec.name to
cName.

Comment 1

[Simon Fraser [no longer active]]

File names in FSSpecs can be a max of 31 chars long, so the buffer will always
be big enough, but we should play safe here.

Comment 2

[Steve Dagley]

Actually StrFileName should be defined as a Str63 when building for Mac.  It's a
Str255 under Windows (thanks to QuickTime APIs being cross-platform)

Comment 3

[Wan-Teh Chang]

I may be looking at the wrong definitions.  Here
are the URLs of the definitions I cited.

FSSpec:
http://developer.apple.com/techpubs/macosx/Carbon/Files/FileManager/File_Manager/DataTypes/FSSpec.html

StrFileName:
http://developer.apple.com/techpubs/quicktime/qtdevdocs/APIREF/SOURCESIV/stringtypes.htm

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.