#1706 segfault in async_resolv.c
Closed: Fixed None Opened 11 years ago by jhrozek.

I saw this crash today on my laptop:

(gdb) bt
#0  0x00000038cde35ba5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63
#1  0x00000038cde37358 in __GI_abort () at abort.c:90
#2  0x00000038d1a022e6 in talloc_abort (reason=0x38d1a08718 "Bad talloc magic value - access after free") at ../talloc.c:317
#3  0x00000038d1a02314 in talloc_abort_access_after_free () at ../talloc.c:336
#4  talloc_chunk_from_ptr (ptr=ptr@entry=0x223ccf0) at ../talloc.c:357
#5  0x00000038d1a06b23 in talloc_chunk_from_ptr (ptr=0x223ccf0) at ../talloc.c:355
#6  _talloc_steal_loc (new_ctx=new_ctx@entry=0x22484d0, ptr=0x223ccf0, location=location@entry=0x474f50 "src/resolv/async_resolv.c:1084") at ../talloc.c:952
#7  0x0000000000429409 in resolv_gethostbyname_dns_recv (rhostent=0x2248500, timeouts=0x224850c, status=0x2248508, mem_ctx=0x22484d0, req=0x2249590) at src/resolv/async_resolv.c:1084
#8  resolv_gethostbyname_done (subreq=0x2249590) at src/resolv/async_resolv.c:1384
#9  0x00000038d22050b7 in tevent_req_finish (location=0x474942 "src/resolv/async_resolv.c:984", state=TEVENT_REQ_USER_ERROR, req=0x2249590) at ../tevent_req.c:110
#10 _tevent_req_error (req=req@entry=0x2249590, error=error@entry=2, location=location@entry=0x474942 "src/resolv/async_resolv.c:984") at ../tevent_req.c:128
#11 0x000000000042a1e6 in resolv_gethostbyname_dns_query_done (arg=<optimized out>, status=<optimized out>, timeouts=<optimized out>, abuf=<optimized out>, alen=<optimized out>) at src/resolv/async_resolv.c:984
#12 0x00000038ce60c0b4 in end_squery (squery=squery@entry=0x2250d90, status=<optimized out>, abuf=<optimized out>, alen=<optimized out>) at ares_search.c:208
#13 0x00000038ce60c269 in search_callback (arg=0x2250d90, status=<optimized out>, timeouts=<optimized out>, abuf=<optimized out>, alen=<optimized out>) at ares_search.c:155
#14 0x00000038ce60beae in qcallback (arg=0x220eb30, status=<optimized out>, timeouts=<optimized out>, abuf=<optimized out>, alen=<optimized out>) at ares_query.c:180
#15 0x00000038ce60a7da in end_query (channel=channel@entry=0x2253920, query=query@entry=0x224f0a0, status=status@entry=0, abuf=abuf@entry=0x7fff39617830 "\237\205\205\200", alen=alen@entry=204)
    at ares_process.c:1266
#16 0x00000038ce60b522 in process_answer (channel=channel@entry=0x2253920, abuf=abuf@entry=0x7fff39617830 "\237\205\205\200", alen=204, whichserver=whichserver@entry=0, tcp=tcp@entry=0, now=now@entry=
    0x7fff39617ab0) at ares_process.c:611
#17 0x00000038ce60b786 in process_answer (now=0x7fff39617ab0, tcp=0, whichserver=0, alen=<optimized out>, abuf=0x7fff39617830 "\237\205\205\200", channel=0x2253920) at ares_process.c:547
#18 read_udp_packets (channel=channel@entry=0x2253920, read_fds=read_fds@entry=0x0, read_fd=read_fd@entry=24, now=now@entry=0x7fff39617ab0) at ares_process.c:497
#19 0x00000038ce60bac7 in processfds (channel=0x2253920, read_fds=read_fds@entry=0x0, read_fd=24, write_fds=write_fds@entry=0x0, write_fd=write_fd@entry=-1) at ares_process.c:152
#20 0x00000038ce60bdce in ares_process_fd (channel=<optimized out>, read_fd=<optimized out>, write_fd=write_fd@entry=-1) at ares_process.c:173
#21 0x0000000000427c22 in fd_input_available (ev=<optimized out>, fde=<optimized out>, flags=1, data=<optimized out>) at src/resolv/async_resolv.c:196
#22 0x00000038d2207552 in epoll_event_loop (tvalp=0x7fff39617b90, std_ev=0x2205680) at ../tevent_standard.c:328
#23 std_event_loop_once (ev=<optimized out>, location=<optimized out>) at ../tevent_standard.c:567
#24 0x00000038d2204060 in _tevent_loop_once (ev=ev@entry=0x22055b0, location=location@entry=0x47ae17 "src/util/server.c:601") at ../tevent.c:507
#25 0x00000038d22041eb in tevent_common_loop_wait (ev=0x22055b0, location=0x47ae17 "src/util/server.c:601") at ../tevent.c:608
#26 0x0000000000452a63 in server_loop (main_ctx=0x22066c0) at src/util/server.c:601
#27 0x000000000040c149 in main (argc=<optimized out>, argv=<optimized out>) at src/providers/data_provider_be.c:2606

Seems like a use-after-free situation.


Fields changed

owner: somebody => jhrozek
patch: 0 => 1
status: new => assigned

milestone: NEEDS_TRIAGE => SSSD 1.9.4
resolution: => fixed
status: assigned => closed

Metadata Update from @jhrozek:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.9.4

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2748

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata