On Thu, May 14, 2026 at 01:08:26AM +0200, Stefano Brivio wrote:

On Wed, 13 May 2026 12:26:17 +0200 Laurent Vivier wrote:

...

Coverity flags the random() call in ndp_timer() with the dont_call checker, warning that it should not be used for security-related applications.

This is a false positive: random() is used here to jitter the interval between unsolicited Router Advertisements as required by RFC 4861, to prevent synchronisation between routers on a link. No cryptographic strength is needed.

Suppress the warning with an inline Coverity annotation.

Signed-off-by: Laurent Vivier --- ndp.c | 1 + 1 file changed, 1 insertion(+)

diff --git a/ndp.c b/ndp.c index 1f2bcb0cc7ea..614932ac5829 100644 --- a/ndp.c +++ b/ndp.c @@ -441,6 +441,7 @@ void ndp_timer(const struct ctx *c, const struct timespec *now) * again, it's close enough for our purposes. */ interval = min_rtr_adv_interval + + /* coverity[dont_call:FALSE] */

Sorry, I should have mentioned this to you explicitly, but we discussed this in the past and we decided against having explicit suppressions for warnings from Coverity Scan (at least, that would be my strong preference).

The reason is that I would like to avoid referring to trademarks as much as possible, as they might raise "interesting" legal questions, and at the same time we have very little control or visibility into how these suppressions evolve in future versions of the checker.

If this suppression format also works for the sort-of-public scan.coverity.com, that mitigates those later concerns somewhat. Still doesn't remove the kind of implicit endorsement of including a trademark, which I can understand why we'd want to avoid.

In this case, by the way, despite the fact that we use this to add some randomness to the timing of router advertisements as required by RFC 4861, I started wondering recently if an attacker (I'm mostly thinking about denials of service) could actually gain anything from making these intervals predictable.

If that's the case, perhaps we could just switch to getrandom() and be done with it.

Hm, maybe, yes. These announcements are infrequent enuogh that the extra cost of getrandom() shouldn't really be a problem. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson