An out-of-bounds stack writes on 64-bit architectures (caller has 4 bytes, callee writes 8 bytes), and seem to have gone unnoticed on little-endian architectures (although big-endian architectures must be broken). Refer: https://github.com/lurcher/unixODBC/pull/157
Created unixODBC tracking bugs for this issue: Affects: fedora-all [bug 2270029]
I've managed to establish communication with the upstream and discuss parts I was confused about. The result is: Neither Fedora, nor RHEL are affected. -- Justification: There are two files with very similar names: 'libodbcpsql.so' 'libodbcpsqlS.so' Despite having similar name, they are built from entirely different parts of the unixODBC sources and they have entirely different meaning. The first one is a 'main driver'. It utilizes the main ODBC API that covers the actual running of a connection to a database, this is called after connecting at run time via the driver manager. It's sources are in: 'Drivers/Postgre7.1' directory The second one is a 'setup driver'. A small API which is used by the GUI component: https://src.fedoraproject.org/rpms/unixODBC-gui-qt which we doesn't have in RHEL. All the (any) 'setup driver' does is edit the odbc.ini entries. It's sources are in: 'DRVConfig/PostgreSQL' directory. -- The vulnerable code is part of the 'main driver', and has nothing to do with the 'setup driver'. We build both (even though there's no logical need to build either). We delete the 'main driver' during the package build process: https://gitlab.com/redhat/centos-stream/rpms/unixODBC/-/blob/c9s/unixODBC.spec?ref_type=heads#L75 https://gitlab.com/redhat/centos-stream/rpms/unixODBC/-/blob/c8s/unixODBC.spec?ref_type=heads#L76 so it's neither packed nor shipped. We keep the 'setup driver'. It doesn't have any value in RHEL, as there isn't any GUI tool to use it with. It's a relic synced from Fedora, but harmless.