Bug 205113 - libresolv query ids reused after fork()
libresolv query ids reused after fork()
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-09-04 05:39 EDT by Wolfgang Breyha
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.4.90-29
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-05 05:01:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
PoC Code... (1.22 KB, text/plain)
2006-09-04 05:39 EDT, Wolfgang Breyha
no flags Details

  None (edit)
Description Wolfgang Breyha 2006-09-04 05:39:58 EDT
Description of problem:
If a parent process initialises the resolver structure with res_init() and forks
childs afterwards every child uses the last query id the parent had in _res.id
for the first request. This can lead to a lot of requests with the same id if
done by a daemon (eg. PTR lookup for the connecting client). If the nameserver
uses "use-id-pool" you will get lots of timeouts and retries.

Version-Release number of selected component (if applicable):
Tried on latest packeges for FC4(2.3.6-3), FC5(2.4-8). Same result.

How reproducible:
I've written PoC Code... attached.

Steps to Reproduce:
1. start "tcpdump port 53"
2. call my PoC Code several times and watch the query IDs
Actual results:
timeouts and retries with same nameservers

Expected results:
No timeouts;-) 

Additional info:
I currently use a workarround in the daemon by doing a
_res.id = res_randomid();
after the fork in the child section.
Comment 1 Wolfgang Breyha 2006-09-04 05:39:58 EDT
Created attachment 135485 [details]
PoC Code...
Comment 3 Jakub Jelinek 2006-09-04 16:01:19 EDT
Fixed in CVS, will show up in next rawhide build.
Comment 4 Jakub Jelinek 2006-09-05 05:01:47 EDT
Fixed in glibc-2.4.90-29.

Note You need to log in before you can comment on or make changes to this bug.