Bug 1259923 - if a policy zone updated during regular operation, then RPZ summary data to fall out of sync
Summary: if a policy zone updated during regular operation, then RPZ summary data to f...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: bind
Version: 6.8
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: ---
Assignee: Petr Menšík
QA Contact: Petr Sklenar
URL:
Whiteboard:
Depends On:
Blocks: 1269194 1254457 1359261
TreeView+ depends on / blocked
 
Reported: 2015-09-03 19:43 UTC by Sameer Jadhav
Modified: 2017-03-21 10:06 UTC (History)
4 users (show)

Fixed In Version: bind-9.8.2-0.55.rc1.el6
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-21 10:06:13 UTC
Target Upstream Version:


Attachments (Terms of Use)
baskported relevant part of the upstream fix (2.36 KB, patch)
2016-03-03 11:59 UTC, Tomáš Hozza
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0651 normal SHIPPED_LIVE bind bug fix update 2017-03-21 12:32:44 UTC

Comment 2 Tomáš Hozza 2015-10-05 12:15:28 UTC
Hi.

Please provide reproducer so engineering and QE can verify the fix.

Thank you!

Comment 3 Tomáš Hozza 2015-10-06 15:17:46 UTC
Hi.

Based on the information provided in ticket I tried this:

1. generated sample RPZ zone with 3 millions of records using simple script:
https://gitlab.com/thozza/random-scripts/blob/master/gen_rpz_zone.py


scenario 1:
- configured server (A) as master with one RPZ zones each 3m records.
- configured sserver (B) with RPZ zone which was slave and transfered from the server (A).
- I was querying server (B) with random queries while:
 - I removed all entries but SOA from the RPZ zone file on server (A)
 - The server (B) transfered the zone using AXFR
 - I changed the RPZ zone on server (A) back to 3m records.
 - The server (B) transfered the zone using AXFR

The querying server (B) never locked up and the query resolution never took more than 1 second


scenario 2:
Same as scenario 1 but with two RPZ zones.


I can try to blindly map the changes from upstream to the RHEL-6 code, but having the reproducer is needed to verify that the issue is fixed.

Thanks.

Comment 4 Tomáš Hozza 2015-10-09 08:15:22 UTC
I went through the patch you requested as the one that should fix the issue. 

First part of the patch (patching rbtdb.c) is applicable to the RHEL-6 version of BIND. Based on my understanding this is preventing the possible inconsistencies when zone is updated and addition/deletion of a node fails.

However the second part of the patch (patching rpz.{c,h}) is changing code that is not even present in el6 version of BIND, therefore it can not affect the behavior.

Without a reproducer I can not proceed with the work on possible fix.

Please provide step-by-step reproducer and also backtrace from all threads when bind is in "locked" state (attach to bind while running using 'gdb -p <pid>' and then run 'thread apply all bt'. Don't forget to install the debuginfo packages before doing this, otherwise the backtrace will be worthless.).

Setting Devel Cond NAK 'Reproducer' and 'Patch' for now.

Comment 11 Tomáš Hozza 2016-03-03 11:59:00 UTC
Created attachment 1132733 [details]
baskported relevant part of the upstream fix

Comment 27 errata-xmlrpc 2017-03-21 10:06:13 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2017-0651.html


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