The root cause of this race is that drm_setmaster_ioctl can free an old *fpriv->master* in drm_new_set_master, while drm_mode_getresources holds a freed *fpriv->master *in drm_lease_held due to the absence of proper lock. References: https://www.openwall.com/lists/oss-security/2022/04/12/3
*** Bug 2073427 has been marked as a duplicate of this bug. ***
These are the 4 upstream patches that need to come back. 1f7ef07cfa14fb8557d1f1b7a14c76926142a4fb drm: add a locked version of drm_is_current_master 0b0860a3cf5eccf183760b1177a1dcdb821b0b66 drm: serialize drm_file.master with a new spinlock 56f0729a510f92151682ff6c89f69724d5595d6e drm: protect drm_master pointers in drm_lease.c 28be2405fb753927e18bc1a891617a430b2a0684 drm: use the lookup lock in drm_is_current_master
CVE-2022-1280 : Affected versions are unknown , but DRM lease infrastructure got introduced in 4.15rc1. So can we conclude that linux_kernel < 4.15rc1 are not affected?.
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2022:7933 https://access.redhat.com/errata/RHSA-2022:7933
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2022:8267 https://access.redhat.com/errata/RHSA-2022:8267
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-2022-1280