Report information
The Basics
Id:
46841
Status:
resolved
Priority:
Medium/Medium
Queue:

People
Owner:
Nobody in particular
Requestors:
scan-admin@coverity.com(no email address set)
Cc:
AdminCc:

BugTracker
Version Fixed:
9.12.1, 9.13.0
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
(no value)
Priority:
P3 Low
Severity:
S3 Low
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
(no value)
Area:
Other

Dates
Created:Tue, 12 Dec 2017 19:27:09 -0500
Updated:Sun, 14 Jan 2018 20:09:14 -0500
Closed:Sun, 14 Jan 2018 20:09:11 -0500



This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

From: scan-admin@coverity.com
To: bind9-bugs@isc.org
Date: Wed, 13 Dec 2017 00:27:02 +0000 (UTC)
Subject: New Defects reported by Coverity Scan for BIND
Hi, Please find the latest report on new defect(s) introduced to BIND found with Coverity Scan. 2 new defect(s) introduced to BIND found with Coverity Scan. 2 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 1426087: Control flow issues (DEADCODE) /lib/ns/tests/query_test.c: 60 in ns__query_sfcache_test() ________________________________________________________________________________________________________ *** CID 1426087: Control flow issues (DEADCODE) /lib/ns/tests/query_test.c: 60 in ns__query_sfcache_test() 54 REQUIRE(test->cache_entry_present == ISC_TRUE || 55 test->cache_entry_flags == 0); 56 57 /* 58 * Interrupt execution if query_done() is called. 59 */ >>> CID 1426087: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "query_hooks[query_hooks@dim...". 60 ns_hook_t query_hooks[NS_QUERY_HOOKS_COUNT] = { 61 [NS_QUERY_DONE_BEGIN] = { 62 .callback = ns_test_hook_catch_call, 63 .callback_data = NULL, 64 }, 65 }; ** CID 1426086: Control flow issues (DEADCODE) /lib/ns/tests/query_test.c: 267 in ns__query_start_test() ________________________________________________________________________________________________________ *** CID 1426086: Control flow issues (DEADCODE) /lib/ns/tests/query_test.c: 267 in ns__query_start_test() 261 (test->auth_zone_origin != NULL && 262 test->auth_zone_path != NULL)); 263 264 /* 265 * Interrupt execution if query_lookup() or query_done() is called. 266 */ >>> CID 1426086: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "query_hooks[query_hooks@dim...". 267 ns_hook_t query_hooks[NS_QUERY_HOOKS_COUNT] = { 268 [NS_QUERY_LOOKUP_BEGIN] = { 269 .callback = ns_test_hook_catch_call, 270 .callback_data = NULL, 271 }, 272 [NS_QUERY_DONE_BEGIN] = { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRatftY8JjD0XUVeK0eDwSEPh4vRqywf0w3swJ8N5sF82Q-3D-3D_QjBaZtEJDFdtBJj3YWWx4OwxXn6h7X1bCFA-2BmidshrgROp-2FZB5XLa-2FWMt7e0Dnc2DFiS2bIxzej3MpwjhxblKsEZwwDr4FH31xZBvxHwSzMZ3ngEueM2aJ0C2o9N3OaAkT7u1f0gv0IlQ-2Frm-2BCyzPNMIjG8JTJqK4u1rKnQf6aST6PBcLza4nLEzTZ5F-2FgFQ7HuKFwbhivL-2FaPPqR33Ceg-3D-3D To manage Coverity Scan email notifications for "bind9-bugs@isc.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4rIy41Xs74BznZj4k3EIh0OhIeqrl4tMKvZau-2B5LUEdCBSWjNYx5kf-2B92zKd1nnWiMMfay-2Fg7DuBn2-2BCqidUp9Y39BJMi1Fd-2FeSXcvFgX1I4-3D_QjBaZtEJDFdtBJj3YWWx4OwxXn6h7X1bCFA-2BmidshrgROp-2FZB5XLa-2FWMt7e0Dnc2cdJe2kViWAyRe1dLQjEkb-2Fs9bz7-2B-2FgdtneYj5UigTxIsEmMh6fvKr08w-2FnJb-2FKbippSeV8rNFJpR8K9W3dALD8FIRkdRLrI1ewKJT-2BuCRrM3H4QBUToiN4otvLduYx0HQsJj0MthPbFVysgfzsIwFg-3D-3D
Coverity assumes that all enum values are valid indexes into the array rather than the last one being a count value. I suggest that we replace the _COUNT with _LAST and use _LAST + 1 to size the array.
ready for review.
To be honest, I cannot really fathom what Coverity is complaining about here. According to the detailed Coverity Scan report, these are the "events" contributing to the first "issue": incr: Incrementing query_hooks@dim0. The value of query_hooks@dim0 is now 1. incr: Incrementing query_hooks@dim0. The value of query_hooks@dim0 is now 2. incr: Incrementing query_hooks@dim0. The value of query_hooks@dim0 is now 3. const: At condition query_hooks@dim0 < 3UL, the value of query_hooks@dim0 must be equal to 3. dead_error_condition: The condition query_hooks@dim0 < 3UL cannot be true. CID undefined (#1 of 1): Logically dead code (DEADCODE) dead_error_line: Execution cannot reach this statement: query_hooks[query_hooks@dim.... All of these "events" "happen" on the same source code line and they are identical for both "issues" found. Given the above: - I do not understand how merging rt46841 would silence these warnings. Mark, if Coverity's notes make sense to you, could you please try explaining it all to me like I am five? - Even if merging rt46841 would indeed get rid of these warnings, I still do not like how it sacrifices code clarity for silencing an obvious false alarm. Since neither NS_QUERY_HOOKS_LAST nor NS_QUERY_HOOKS_COUNT is used as a hook identifier, cannot we just keep using the latter, adding "+ 1" to the array size to achieve the same effect with minimal effort? - I am not totally opposed to adding a quick workaround for these "issues" given that "production-quality" hooks are planned for 9.13 and these would not use whole-table assignments employed in the red-flagged code anyway. But I would like to at least properly understand Coverity's reasons for complaining.
Subject: Re: [ISC-Bugs #46841] New Defects reported by Coverity Scan for BIND
Date: Wed, 3 Jan 2018 08:00:34 +1100
To: bind9-confidential@isc.org
From: "Mark Andrews" <marka@isc.org>
Coverity is trying each enum value and the final index value is out of range of the array indexes give C is zero based. -- Mark Andrews
We could also just mark these as intentional and ignore them.
> Coverity is trying each enum value and the final index value is out of range of the array indexes give C is zero based. But the flagged code is not even an array _access_, it is an array _declaration_. > We could also just mark these as intentional and ignore them. This is what I would be more inclined to do. I still do not understand how using [<enum> + 1] for the array size would help, but given that I expect this code to be rewritten pretty soon anyway, feel free to make the warning go away in any way you deem appropriate and let's not waste any more time discussing this.
From: "Mark Andrews" <marka@isc.org>
To: bind9-confidential@isc.org
Subject: Re: [ISC-Bugs #46841] New Defects reported by Coverity Scan for BIND
Date: Thu, 11 Jan 2018 23:22:09 +1100
Think of it like testing if a switch on a enum has a case for possible enum element. Now apply that same thinking to a array which is sized using a enum. > On 11 Jan 2018, at 11:13 pm, Michał Kępień via RT <bind9-confidential@isc.org> wrote: > >> Coverity is trying each enum value and the final index value is out of range of the array indexes give C is zero based. > > But the flagged code is not even an array _access_, it is an array > _declaration_. > >> We could also just mark these as intentional and ignore them. > > This is what I would be more inclined to do. I still do not understand > how using [<enum> + 1] for the array size would help, but given that I > expect this code to be rewritten pretty soon anyway, feel free to make > the warning go away in any way you deem appropriate and let's not waste > any more time discussing this. > > > -- > Ticket History: https://bugs.isc.org/Ticket/Display.html?id=46841 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Thank you for this, it does shed some light on these warnings. So it complains that if I declare an array the way I do and then, somewhere else, I attempt to access the element at index NS_QUERY_HOOKS_COUNT (which I never do, but Coverity does not know that), it will be out-of-bounds? If that is the case, I would just size the arrays using the original enum value (NS_QUERY_HOOKS_COUNT) + 1, i.e. without renaming the last enum value.
commit f4c1681dad5bf3b019b71da255fe2c7d89394c86 (HEAD -> v9_12, origin/v9_12) Author: Mark Andrews <marka@isc.org> Date: Mon Jan 15 12:02:41 2018 +1100 silence coverity false positive. [RT #46841] (cherry picked from commit fa22351a7cc6f6d250569d5e192a6d86018645b6)