File name buffer may not be large enough

ASSIGNED
Assigned to

Status

ASSIGNED
16 years ago
10 years ago

People

(Reporter: wtc, Assigned: wtc)

Tracking

PowerPC
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

16 years ago
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

16 years ago
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.
Status: NEW → ASSIGNED

Comment 2

16 years ago
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)
(Assignee)

Comment 3

16 years ago
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
QA Contact: wtchang → nspr

Updated

10 years ago
Assignee: sfraser_bugs → wtc
You need to log in before you can comment on or make changes to this bug.