[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
buffer underflow in evalfile.c
From: |
highguy |
Subject: |
buffer underflow in evalfile.c |
Date: |
Sun, 30 Dec 2007 19:19:11 +0100 |
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O3 -march=nocona -pipe
uname output: Linux HIGHGuY 2.6.22-gentoo-r2by_HIGHGuY #7 SMP PREEMPT Sun Sep
30 11:57:33 CEST 2007 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
GenuineIntel GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 3.2
Patch Level: 17
Release Status: release
Description:
There is a buffer underflow in evalfile.c which causes glibc to assert.
It is generally caused by faulty media when trying to evaluate files.
I encountered it when trying to log into a device with a corrupted
CompactFlash card.
builtins/evalfile.c:152
When read() returns -1 a NULL-character is written ahead of the buffer.
MontaVista linux has already fixed this issue upon request, although
I'm not sure
if this fix is pushed upstream.
Repeat-By:
Not reproducable without bad media.
Fix:
Move the incorrect NULL-assignment below both resultcode checks.
patch below on the latest downloadable version.
152d151
< string[result] = '\0';
169c168,170
<
---
>
> string[result] = '\0';
>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- buffer underflow in evalfile.c,
highguy <=