An issue was discovered in GNOME GLib before 2.66.8. When g_file_replace() is used with G_FILE_CREATE_REPLACE_DESTINATION to replace a path that is a dangling symlink, it incorrectly also creates the target of the symlink as an empty file, which could conceivably have security relevance if the symlink is attacker-controlled. (If the path is a symlink to a file that already exists, then the contents of that file correctly remain unchanged.) References: https://gitlab.gnome.org/GNOME/glib/-/issues/2325
Created glib tracking bugs for this issue: Affects: epel-7 [bug 1938293] Affects: fedora-all [bug 1938292] Created glib2 tracking bugs for this issue: Affects: fedora-all [bug 1938294] Created mingw-glib2 tracking bugs for this issue: Affects: fedora-all [bug 1938295]
Upstream patches: https://gitlab.gnome.org/GNOME/glib/-/commit/c80528f17ba25ea7d7089946926b93a98bd1479e [2.67.x] https://gitlab.gnome.org/GNOME/glib/-/commit/01c5468e10707cbf78e6e83bbcf1ce9c866f2885 [2.66.x]
Marking all Hosted* as "notaffected" as this appears to be limited to GNOME which is not present.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:4385 https://access.redhat.com/errata/RHSA-2021:4385
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-28153
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2022:8418 https://access.redhat.com/errata/RHSA-2022:8418