Re: Bug w/ gawk stat extension

[Glenn Zazulia]

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.

Glenn

--

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

gawk-stat.patch
Description: Text document