Created attachment 15053 [details]
Fix for unaligned accesses in resolver

Helge wrote recently:

Hi Dave,

I'm sure you have seen such messages in dmesg as well:
[ 5073.977098] exim4(11935): unaligned access to 0xf7ebadcd at ip 0xf5f7e307 (iir 0xd481043)
[ 5074.134880] exim4(11935): unaligned access to 0xf7ebadcd at ip 0xf5f7e1cf (iir 0xee8104d)

I got annoyed by it, and tried to find the root cause:

Runing: prctl --unaligned=signal gdb /usr/sbin/exim4

points to glibc:

Program received signal SIGBUS, Bus error.
__GI___libc_res_queriesmatch (buf1=0xf7e29e70 "}\031\001", eom1=0xf7e29e91 "", buf2=0xf7e28e09 "}\031\205\200",
    eom2=0xf7e29209 "\342\220\310\367\342\221\324") at res_queriesmatch.c:105
105     res_queriesmatch.c: No such file or directory.
(gdb) bt
#0  __GI___libc_res_queriesmatch (buf1=0xf7e29e70 "}\031\001", eom1=0xf7e29e91 "", buf2=0xf7e28e09 "}\031\205\200",
    eom2=0xf7e29209 "\342\220\310\367\342\221\324") at res_queriesmatch.c:105
#1  0xf5f81380 in send_dg (ansp2_malloced=0x0, resplen2=0x0, anssizp2=0x0, ansp2=0x0, anscp=0xf7e2938c, gotsomewhere=<synthetic pointer>,
    v_circuit=<synthetic pointer>, ns=<optimized out>, terrno=0xf7e2a088, anssizp=0xf7e29fc4, ansp=0xf7e29fc8, buflen2=0, buf2=0x0, buflen=33,
    buf=0xf7e29e70 "}\031\001", statp=0xf5fefab0 <_res>) at res_send.c:1204
#2  __GI___res_context_send (ctx=<optimized out>, buf=<optimized out>, buflen=<optimized out>, buf2=0x0, buflen2=<optimized out>, ans=<optimized out>,
    anssiz=<optimized out>, ansp=<optimized out>, ansp2=<optimized out>, nansp2=<optimized out>, resplen2=<optimized out>, ansp2_malloced=<optimized out>)
    at res_send.c:373
#3  0xf5f7e600 in __GI___res_context_query (ctx=0xf7e29e70, name=0x20035 <acl_ratelimit+2344> "\301?Q#V\340", class=-1062726654, type=-167838588,
    answer=<optimized out>, anslen=<optimized out>, answerp=<optimized out>, answerp2=<optimized out>, nanswerp2=<optimized out>, resplen2=<optimized out>,
    answerp2_malloced=<optimized out>) at res_query.c:221
#4  0x00000000 in ?? ()

In glibc's ./resolv/res_queriesmatch.c:

 /* Note that we initially do not convert QDCOUNT to the host byte
     order.  We can compare it with the second buffer's QDCOUNT
     value without doing this.  */
  int qdcount = ((HEADER *) buf1)->qdcount;
  if (qdcount != ((HEADER *) buf2)->qdcount)

so, buf2 is unaligned and that breaks.

Can we do something about it?

Checking the tests in resolv, I found one more place where unaligned accesses
occur on hppa.

I'm testing the attached patch.