[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug w/ gawk stat extension

From: Glenn Zazulia
Subject: Re: Bug w/ gawk stat extension
Date: Mon, 20 Jun 2005 15:10:22 -0600 (MDT)

Great!  I thought I'd also send another slight fix in the same 
section of code:  pass in "sizeof buf - 1" to readlink() for the
bufsize arg to save room for appending the trailing NULL character.
This should prevent that fatal("size of symbolic link too big") failure
case from ever occurring.  This is just a boundary case in sample
extension code; so again, it's not a critical fix, but if you're
already updating the filefuncs.c file with the other fix, you might
as well include this too.  Attached is the complete patch, including
both fixes.



On Jun 20, Aharon Robbins wrote:
> Thanks for the fix.  I'll get it in for the next release.
> Arnold
>> Date: Fri, 17 Jun 2005 14:35:13 -0600 (MDT)
>> From: Glenn Zazulia <address@hidden>
>> Subject: Bug w/ gawk tat extension
>> To: address@hidden
>> Cc: address@hidden
>> Hello,
>> I noticed a bug with the readlink() call in extension/filefuncs.c when
>> stat()ing a symlink.  Notice that the code does not check the return
>> value. When readlink() fails, the return value is set to -1, of course,
>> and that value is used as an array offset a few lines later, corrupting
>> the stack and ultimately causing a SEGV abort.
>> Example filesystem symlinks that cause readlink() to fail can be found
>> in the /proc filesystem on Linux systems (at least on the various RedHat
>> versions that I've tested, such as 8 & 9).  In particular, look for the
>> low-numbered kernel process, such as /proc/10/exe.
>> Since this bug occurs just in the sample extension code, it's probably
>> not considered especially serious, but I thought I'd report it anyway.
>> Please see below for a sample patch...
>> Glenn Zazulia
>> address@hidden

Attachment: gawk-stat.patch
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]