[OpenAFS] Fwd: Bug#415952: openafs-client: klog fails with an "bus access error" for password longer then 8 symbols.

[Marcus Watts]

Russ Allbery <rra@stanford.edu> sent:
> Date:    Fri, 22 Jun 2007 01:42:29 PDT
> To:      openafs-info@openafs.org
> From:    Russ Allbery <rra@stanford.edu>
> Subject: [OpenAFS] Fwd: Bug#415952: openafs-client: klog fails with an "bus acc
>      ***ess error" for password longer then 8 symbols.
> 
> Bcc'd to bugs.  This is only on SPARC I believe.  Some sort of alignment
> issue in the DES code?  I don't know why it would just start showing up
> now, though.
> 
> Date: Wed, 13 Jun 2007 11:13:12 +0200
> From: Marko R=F6=DFler <marr@infotech.tu-chemnitz.de>
> To: Russ Allbery <rra@debian.org>
> Cc: 415952@bugs.debian.org
> Subject: Re: Bug#415952: openafs-client: klog fails with an "bus access err=
> or" for password longer then 8 symbols.
> 
> Hi Russ,
> 
> finaly i managed to compile the openafs-client with debug symbols and
> received the following BackTrace:
> 
> (gdb) run
> Starting program:
> /var/cache/apt-build/build/openafs-1.4.4.dfsg1/src/kauth/klog=20
> Password:
> 
> Program received signal SIGBUS, Bus error.
> 0x0004a2a8 in des_key_sched ()
> (gdb) bt
> #0  0x0004a2a8 in des_key_sched ()
> #1  0x00012708 in ka_StringToKey ()
> #2  0x00013f34 in ka_UserAuthenticateGeneral ()
> #3  0x00012008 in CommandProc ()
> #4  0x0004cccc in cmd_Dispatch ()
> #5  0x00011b28 in main ()
> 
> Can i help any further?
> 
> Cheers,
> Marko
> 
> --=20
> Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 

It's a shame there's not a bit more information here.
If compiled with "-g", it ought to be possible to see line numbers
and procedure arguments, which would be helpful.  Absent that,
it would have been interesting to see the current instruction
and register contents, or better yet, instructions from the last
subroutine entered up to around the point of failure...
As it is- the above traceback appears to be ignoring static routines
where it's probably actually dying.

Anyways, to take a stab in the dark:
pwlen.gt.8 characters goes to StringToKey (instead of Andrew_StringToKey),
(in src/kauth/client.c).  This calls des_key_sched with 2 parms,
char temp_key[8] and des_key_schedule schedule.  Somewhere inside
the depths of des_key_schedule, it is indeed assumed that the
key schedule can be accessed as integers.  Presumably this is
what is failing.

So, key_schedule in stock 1.4.4 is defined this way:
typedef struct des_ks_struct { des_cblock _; } des_key_schedule[16];
That is, an array of 16 blocks of 8 characters.  The C compiler will
indeed only give that character alignment, so a problem is quite possible.
A relatively simple fix is to instead do this:
typedef struct des_ks_struct { int _[8/sizeof(int)]; } des_key_schedule[16];
which will give it exactly the same size but require int alignment, which
is what is required.  This should compile and work without errors; the
fieldname itself is never used.

Another possible problem is that "ivec" in StringToKey also has
similar integer alignment issues, because des_cbc_cksum writes integers
to its output buffer.  A crude fix would be to make it "int ivec[8/sizeof(int)]".  
This is not as likely - probably MUSTALIGN is asserted when src/des/cksum.c
is compiled, in which case this doesn't matter.

I don't see any reason why this would suddenly start to fail
on sparc -- was the compiler changed recently?  Could BUFSIZ be defined
by stdio.h to have an odd value?  Regardless, it has probably been a latent
bug for a long time.

			-Marcus