Bug 970673 - named-sdb segfaults when dlz query contains keyword with unknown value [NEEDINFO]
named-sdb segfaults when dlz query contains keyword with unknown value
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: bind (Show other bugs)
6.4
Unspecified Linux
low Severity low
: rc
: ---
Assigned To: Tomáš Hozza
qe-baseos-daemons
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-04 10:48 EDT by Michal Ingeli
Modified: 2016-07-25 08:02 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-25 08:02:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
thozza: needinfo? (mi)


Attachments (Terms of Use)

  None (edit)
Description Michal Ingeli 2013-06-04 10:48:13 EDT
Description of problem:

named-sdb segfaults, when encounters query from dlz configuration, that contains keyword with unknown value in current context. When build_querylist() parses query and encounters one of [ $record$, $zone$, $client$ ] keywords, it sets them as "tseg->direct = isc_boolean_false" and "tseg->sql = (char**) zone" (or record or client), that may not be set. This configuration error leads to unexpected behaviour.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. configure dlz backend
2. change one query (first, for simplest reproducer) to contain keywords, that are required ($zone$) and some, that is not or even invalid/unknown in that context ($record$)
3. start named-sdb
4. send dns query to this running instance of named-sdb for dlz backed zone

Actual results:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff1a04700 (LWP 2682)]
__strlen_sse42 () at ../sysdeps/x86_64/multiarch/strlen-sse4.S:32
32              pcmpeqb (%rdi), %xmm1

#0  __strlen_sse42 () at ../sysdeps/x86_64/multiarch/strlen-sse4.S:32
#1  0x00007ffff7fdcc44 in sdlzh_build_querystring (mctx=0x7ffff8208250, querylist=0x7ffff7f2e480) at ../../contrib/dlz/drivers/sdlz_helper.c:304
#2  0x00007ffff7fde943 in mysql_get_resultset (zone=<value optimized out>, record=0x0, client=<value optimized out>, query=4, dbdata=0x7ffff7f2a730, rs=0x7ffff1a016d8)
    at ../../contrib/dlz/drivers/dlz_mysql_driver.c:288
#3  0x00007ffff7fdea6b in mysql_findzone (driverarg=<value optimized out>, dbdata=0x7ffff7f2a730, name=0x7ffff1a01760 "syslog.lx") at ../../contrib/dlz/drivers/dlz_mysql_driver.c:515
#4  0x00007ffff789b18c in dns_sdlzfindzone (driverarg=0x7ffff7f0c240, dbdata=0x7ffff7f2a730, mctx=0x7ffff8208250, rdclass=1, name=0x7ffff1a01bc0, dbp=0x7ffff1a01e40) at sdlz.c:1635
#5  0x00007ffff77ee16c in dns_dlzfindzone (view=0x7fffe80008e0, name=0x7ffff7ea1010, minlabels=0, dbp=0x7ffff1a01e40) at dlz.c:302
#6  0x00007ffff7f9ddc4 in query_getdb (client=0x7fffe8091560, name=0x7ffff7ea1010, qtype=1, options=0, zonep=0x7ffff1a022c0, dbp=0x7ffff1a02328, versionp=0x7ffff1a022c8, is_zonep=0x7ffff1a0233c)
    at query.c:1043
#7  0x00007ffff7fa557d in query_find (client=<value optimized out>, event=0x0, qtype=1) at query.c:5385
#8  0x00007ffff7fac47c in ns_query_start (client=0x7fffe8091560) at query.c:7352
#9  0x00007ffff7f91746 in client_request (task=<value optimized out>, event=<value optimized out>) at client.c:1961
#10 0x00007ffff69682f8 in dispatch (uap=0x7ffff7f10010) at task.c:1012
#11 run (uap=0x7ffff7f10010) at task.c:1157
#12 0x00007ffff544f851 in start_thread (arg=0x7ffff1a04700) at pthread_create.c:301
#13 0x00007ffff49b190d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Expected results:
named-sdb will not start and inform user, or end with error message informing user.

Additional info:

This issue report is not critical, more as reference.
Comment 2 Tomáš Hozza 2014-12-04 09:51:16 EST
(In reply to Michal Ingeli from comment #0)
> Steps to Reproduce:
> 1. configure dlz backend
> 2. change one query (first, for simplest reproducer) to contain keywords,
> that are required ($zone$) and some, that is not or even invalid/unknown in
> that context ($record$)

Could you please be more specific on the second step? I don't understand what you mean by "change on query". Where?

Thank you.

> 3. start named-sdb
> 4. send dns query to this running instance of named-sdb for dlz backed zone
Comment 3 Tomáš Hozza 2015-01-19 08:32:39 EST
Feel free to reopen with the requested information.
Comment 4 Michal Ingeli 2015-03-11 04:50:09 EDT
...been some time. It was "change one query". 
Anyway, as I recollect, for the example take the first database query of the dlz block, that's "findzone()". According to documentation, for each query there are few keywords (macros) available (declared) and initialised with value. But not each of them for every query.
Comment 5 Tomáš Hozza 2015-03-11 07:02:31 EDT
Would you mind attaching a specific reproducer?

Thank you!
Comment 7 Tomáš Hozza 2016-07-25 08:02:20 EDT
This request was evaluated by Red Hat Engineering for inclusion in a Red
Hat Enterprise Linux maintenance release.

As this bug has been in NEEDINFO for an extended period of time we are going
to close this bug due to inactivity. If you would like to pursue this
matter feel free to reopen this bug and attach the needed information.

With the goal of minimizing risk of change for deployed systems, and in
response to customer and partner requirements, Red Hat takes a conservative
approach when evaluating enhancements for inclusion in maintenance updates
for currently deployed products. The primary objectives of update releases
are to enable new hardware platform support and to resolve critical
defects.

However, Red Hat will further review this request for potential inclusion
in future major releases of Red Hat Enterprise Linux.

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