oss-security - RE: [External] : Possible AMD Zen2 CVE

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Tue, 19 Sep 2023 14:46:35 +0000
From: Casper Dik <casper.dik@...cle.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>,
        Steve
 Thompson <susurrus.of.qualia@...il.com>
Subject: RE: [External] : Possible AMD Zen2 CVE

I think you've run into an issue with gcc.

It does not always honor the order and it I have seen issues
where I was not able to get gcc to properly order the code unless
I was using some trick.  That particular trick, a smidgen of volatile
casts did not work.

The code in question:

#if defined BROKEN
      temp = ++obj.value;
#else
      ++obj.value;
#endif
      t1lock_release(&obj.lock);

In the "good" binary the "incw" of the obj.lock is after the "incq" of obj.value;
but in the "bad" binary you see the instructions correctly, incw before incq.

I had the problem with an Intel system running Solaris (hence  different
assembly output):

good:
     wr_thread+0xe7:         48 ff 05 8a 09 10  incq   +0x10098a(%rip)   <obj+0x8>
                            00 
    wr_thread+0xee:         66 ff 05 7b 09 10  incw   +0x10097b(%rip)   <obj>
                            00 

bad:
    wr_thread+0xee:         66 ff 05 8b 09 10  incw   +0x10098b(%rip)   <obj>
                            00 
    wr_thread+0xf5:         48 ff c0           incq   %rax
    wr_thread+0xf8:         48 89 05 89 09 10  movq   %rax,+0x100989(%rip)      <obj+0x8>
                            00 
    wr_thread+0xff:         48 89 05 9a 09 10  movq   %rax,+0x10099a(%rip) 

Casper

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.