|Summary:||Misaligned access in res_query.c HEADER struct|
|Product:||glibc||Reporter:||John David Anglin <danglin>|
|Component:||network||Assignee:||Not yet assigned to anyone <unassigned>|
|Severity:||normal||CC:||adhemerval.zanella, deller, fweimer, sam|
Description John David Anglin 2016-06-11 17:19:25 UTC
For some time, we see various unaligned exceptions running apt-get on hppa: http(13559): unaligned access to 0x00000000fa703d49 at ip=0x00000000f9f0a9bb handle_unaligned: 37 callbacks suppressed http(13810): unaligned access to 0x00000000fa703d49 at ip=0x00000000f9f0a9bb http(13810): unaligned access to 0x00000000fa703d49 at ip=0x00000000f9f0a9c3 http(13810): unaligned access to 0x00000000fa703d49 at ip=0x00000000f9f0cdf3 http(13810): unaligned access to 0x00000000fa703d49 at ip=0x00000000f9f0cecf http(13810): unaligned access to 0x00000000fa703d4d at ip=0x00000000f9f0c69b Helge and myself tracked the first of these exceptions to the following line in res_query.c: hp->rcode = NOERROR; /* default */ The argument answer has the type u_char *. Thus, the function __libc_res_nquery should nominally be prepared to access the HEADER struct on a byte boundary. However, the struct HEADER is not defined with the packed attribute, so accesses to the bit fields in the struct are done with word rather than byte accesses. This causes the above faults. This is very inefficient on strict alignment targets such as hppa and ia64, and slow on x86, etc. Adding "__attribute__((packed))" to the HEADER typedef appears to eliminate the unaligned accesses from http.
Comment 1 John David Anglin 2016-06-15 11:45:25 UTC
Comment 2 John David Anglin 2016-06-17 22:57:39 UTC
New patch here: https://sourceware.org/ml/libc-alpha/2016-06/msg00679.html
Comment 3 John David Anglin 2016-06-25 16:05:51 UTC
New patch is here: https://sourceware.org/ml/libc-alpha/2016-06/msg01020.html
Comment 4 Sam James 2022-01-31 03:29:36 UTC
Did this ever get landed? https://sourceware.org/legacy-ml/libc-alpha/2016-06/msg01020.html
Comment 5 dave.anglin 2022-01-31 14:36:57 UTC
On 2022-01-30 10:29 p.m., sam at gentoo dot org wrote: > Did this ever get landed? No but Debian has been carrying it for some time.
Comment 6 Sam James 2022-03-14 18:40:50 UTC
(In reply to dave.anglin from comment #5) > On 2022-01-30 10:29 p.m., sam at gentoo dot org wrote: > > Did this ever get landed? > No but Debian has been carrying it for some time. I spoke to azanella and we agreed the patch seems reasonable: [17:44:45] <azanella> sam_, this has triggered an issue with or1k recently https://email@example.com/ and I think the latest patch from david should be ok (although I am not very found of the packet usage) [17:52:21] <sam_> oh I'd missed that one [18:03:55] <sam_> are you able to apply it or do I need to ask david to do it? [18:09:35] <azanella> sam_, could you please ask sam to repost it, so we can proper review it? [18:39:27] <sam_> azanella: ofc, will do Could you resend it to libc-alpha and then we can get this in?
Comment 7 dave.anglin 2022-03-14 19:02:05 UTC
On 2022-03-14 2:40 p.m., sam at gentoo dot org wrote: > Could you resend it to libc-alpha and then we can get this in? Will do after recheck on master.
Comment 8 John David Anglin 2022-03-17 23:06:54 UTC
Comment 9 John David Anglin 2022-03-22 17:40:00 UTC
commit 05dec22d7be722987ff07aebf9690f6078b3c4e9 (HEAD -> master, origin/master, origin/HEAD) Author: John David Anglin <firstname.lastname@example.org> Date: Tue Mar 22 17:35:54 2022 +0000 resolv: Fix unaligned accesses to fields in HEADER struct The structure HEADER is normally aligned to a word boundary but sometimes it needs to be accessed when aligned on a byte boundary. This change defines a new typedef, UHEADER, with alignment 1. It is used to ensure the fields are accessed with byte loads and stores when necessary. V4: Change to res_mkquery.c deleted. Small whitespace fix. V5: Move UHEADER typedef to resolv/resolv-internal.h. Replace all HEADER usage with UHEADER in resolv/res_send.c. Signed-off-by: John David Anglin <email@example.com> Reviewed-by: Adhemerval Zanella <firstname.lastname@example.org>