Possible Data Race in core.go

[ZuhairORZaki]

Bug Description

In file: core.go, there is a possible case of data race. In line 2100, variable c.standby is written to without any kind of locking mechanism. And in line 2088, function call c.postUnseal starts a call chain that leads to starting a goroutine with function Core.emitMetricsActiveNode. The new goroutine eventually invokes the function Core.Standby which reads the same variable c.standby using a read lock c.stateLock.RLock().

	// File: core.go, Line: 2088
	err := c.postUnseal(ctx, ctxCancel, standardUnsealStrategy{})
	// Function Core:unsealInternal invokes function Core:postUnseal.

	// File: core.go, Line: 2780
	err := unsealer.unseal(ctx, c.logger, c)
	// Function Core:postUnseal invokes function standardUnsealStrategy:unseal.

	// File: core.go, Line: 2537
	go c.emitMetricsActiveNode(c.metricsCh)
	// Function standardUnsealStrategy:unseal invokes function 
	// Core:emitMetricsActiveNode in a new goroutine.

	// File: core_metrics.go, Line: 356
	standby, _ := c.Standby()
	// Function Core:emitMetricsActiveNode invokes function Core:Standby.

	// File: ha.go, Line: 86
	c.stateLock.RLock()
	standby := c.standby
	c.stateLock.RUnlock()
	// In function Core:Standby, variable standby is read.

Since two separate goroutines access the same memory location without proper synchronization, it will cause a data race condition.

To Reproduce

The bug was detected using static analysis. We did not reproduce the bug by executing source code.

Expected behavior

The bug was detected using static analysis, Here expected behavior would be accessing the shared variable with proper locking mechanism.

Sponsorship and Support:
This work is done by the security researchers from OpenRefactory under the Project Clean Beach initiative. The researchers are proactively scanning critical open source projects and finding previously undetected bugs in them.

The bug is found by running the iCR tool by OpenRefactory and then manually triaging the results.