A question:

Are there applications that use the affected glibc version and were used 
for mission-critical (or possibly life endangering) calculations?  If 
so, all of the results of such calculations (including any done at 
Fermilab, CERN, or HEP for data analysis, detector calibration and 
modeling, etc.) are suspect.  Are these users even deeply aware of the 
issue and the need to redo work?

On 2/11/21 6:34 AM, ~Stack~ wrote:
> On 2/11/21 2:25 AM, Akemi Yagi wrote:
>> On Wed, Feb 10, 2021 at 11:59 PM Dietrich, Stefan
>> <[log in to unmask]> wrote:
>>>
>>> Hi,
>>>
>>> you might be running into this issue: 
>>> bugzilla.redhat.com/show_bug.cgi?id=1925204
>>>
>>> This has been introduced with glibc-2.17-322.el7_9 and has been fixed 
>>> in glibc-2.17-323.el7_9.
>>> CentOS 7 already ships the updated version, on SL7 the version seems 
>>> to be not yet available.
>>>
>>> Regards,
>>> Stefan
>>
>> Looks like the glibc-2.17-323.el7_9 update (RHBA-2021:0439) is not a
>> security fix. SL usually publishes non-security updates on Tuesdays.
>> Unless the devs decide to make it an exception, the update will be out
>> on next Tue, Feb 16.
>>
>> Akemi
>>
> 
> Awesome! Thank you both. I think you are absolutely onto something. This 
> also may explain why I can't get it to work reliably on my upstream 
> vendor OS. Even though they are all the same coreutils version, I've got 
> different versions of glibc running on them (we have a rolling update 
> cycle for certain environments to help catch upgrade errors). Some are 
> older and some are newer. The one having the problem is the same version.
> 
> I didn't even think to check glibc.
> 
> I will wait till next Tuesday. Thank you!