I understand the point in the 1706920, but I'm afraid that the patch itself would not be directly related for the bug. My point: It surely may catch a most serious failure, but not many failures (if we need to check here).

The bug addressed about do health test for input (entropy source) to RBG.
IIUC, as of today, it now means that it's done by a procedure defined by SP 800-90B. https://csrc.nist.gov/publications/detail/sp/800-90b/final
(Please correct me if I am wrong.)

But the patch in question looks like merely testing if same input was about to be fed. I wonder where the patch comes from (the origin and the rationale).

BACKGROUND: I am selling RNG device at shop.fsf.org, and I implemented something like SP 800-90B (draft, at that time).

Some work for kernel:

For kernel, Stephan has patch:
https://patchwork.kernel.org/project/linux-crypto/patch/4277128.MvlblST01X@positron.chronox.de/

Last year, we had:
https://lwn.net/Articles/832027/

From the FIPS Certs draft for RHEL 8.5, I have the following sentence:

The module performs the DRBG health tests as defined in section 11.3 of [SP800-90A].

Referencing the following document:

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf

I think this related to the section "11.3.4 Testing the Reseed Function", where we test the seeding function

The 90A does not have much more information about this, but the SP 800 90B has the section "4.4.1 Repetition Count Test ", which describes basically what is done in the proposed patch with all its limitations.

I was trying to find some more clarification in FIPS 140-2 IG notes, but without any success so far.

The patch was written by Tomas Mraz around 2019-06, initially just simple check of new-hash/old-hash in drbg_get_entropy, but then rewritten to the current implementation, unfortunately without much trace in the commits/logs/comments/mails. The only note I found is that this was based on openssl implementation and was compliant for 140-2 but might not be in the future.

Given that we are going to need the 140-3 here, I will try to get some clarification from Stephan if 1) we need some changes for 140-3, 2) Some background why it it is acceptable.

I think it will have something to do with the fact the random number generator is chained and based on the kernel JENT, which will be a difference from your hardware using "just" noise.