[Bug libc/30750] New: Unaligned accesses in resolver

["danglin at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30750

            Bug ID: 30750
           Summary: Unaligned accesses in resolver
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: danglin at gcc dot gnu.org
                CC: deller at gmx dot de, drepper.fsp at gmail dot com
  Target Milestone: ---
              Host: hppa*-*-linux*
            Target: hppa*-*-linux*
             Build: hppa*-*-linux*

Created attachment 15053
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15053&action=edit
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.