On Mon, Jun 12, 2006 at 08:18:28AM +0000, Gerrit Pape wrote:
> On Wed, Jun 07, 2006 at 09:39:41AM +0200, Carlo Contavalli wrote:
> > Well, after a couple months, a couple days ago I just updated
> > the whole system. Still trying to understand which is the cause,
> > but when writing 'some files' cfsd crashes with a SIGSEGV
> > and leaves my directory unusable.
ok, I just had some time to investigate the problem. I've attacched
the strace of the fetchmail process that caused the crash and
the strace of cfsd.
The problem is quite simple: I didn't realize one of the mailbox
files (a backup file) passed the 2.0G of size. So, the upgrade
of the system has nothing to do with the crash.
> Can you try to construct a simple test case to reproduce the crash, so
> that I can start debugging? I'm thinking of something like:
sorry for the last report, but I really was in a hurry, didn't
have enough time to produce a test case, and was really scared
by the bug :)
Now, it is quite simple to reproduce: append some data to a 2.0G
file under an encrypted mount, and you should see the crash.
I think the problem is in:
dodecrypt(k,s,l,salt,vect)
cfskey *k;
char *s;
int l;
int salt;
char *vect;
where salt is used as an index in an array:
s[i+j] ^= k->secmask[(i+j+salt)%smsize];
However, dodecrypt is almost always called with something like:
dodecrypt(key,buf,iolen,begin,vect);
where begin is declared as:
u_long begin;
so, if begin is greater than 2.0G (allowed for an unsigned long),
dodecrypt gets a negative salt (int). The negative salt leads to
a negative module to be calculated, underflowing secmask by a
random amount of data which might be big, depending on smsize.
A quick and dirty fix would probably be to change:
dodecrypt(k,s,l,salt,vect)
cfskey *k;
char *s;
int l;
u_long salt;
char *vect;
I don't have enough knowledge about NFS interfaces and 64 bits
offset support when accessing files (lseek64, ...) to know if
that fix would just be enough, or would just "delay problems"
until the 4G limits is hit... for sure, the daemon shouldn't
read some random data from memory, and shouldn't crash, ...
Cheers,
Carlo
--
GPG Fingerprint: 2383 7B14 4D08 53A4 2C1A CA29 9E98 5431 1A68 6975
-------------
A CONS is an object which cares.
-- Bernie Greenberg.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
