In kernel's fanotify, if the copy_info_records_to_user() call in copy_event_to_user() fails, it'll erroneously call put_unused_fd(fd) + fput(f) on a file that was already populated by fd_install(). The erroneous code path, however, is only reachable by privileged users, as one needs to pass the "!FAN_GROUP_FLAG(group, FANOTIFY_UNPRIV)" test which won't if one isn't already capable(CAP_SYS_ADMIN), i.e. has the CAP_SYS_ADMIN capability in the _init_ user namespace, which basically means root. The bug was introduced by commit f644bc449b37 ("fanotify: fix copy_event_to_user() fid error clean up"), which is Linux v5.13. Reference: minipli (OSS-Security)
Marking Services notaffected per kernel analysis.
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2054336]
commit ee12595147ac1fbfb5bcb23837e26dd58d94b15d Author: Dan Carpenter <dan.carpenter> Date: Fri Jan 28 22:57:01 2022 +0300 fanotify: Fix stale file descriptor in copy_event_to_user() This code calls fd_install() which gives the userspace access to the fd. Then if copy_info_records_to_user() fails it calls put_unused_fd(fd) but that will not release it and leads to a stale entry in the file descriptor table. Generally you can't trust the fd after a call to fd_install(). The fix is to delay the fd_install() until everything else has succeeded. Fortunately it requires CAP_SYS_ADMIN to reach this code so the security impact is less. Fixes: f644bc449b37 ("fanotify: fix copy_event_to_user() fid error clean up") Link: https://lore.kernel.org/r/20220128195656.GA26981@kili Signed-off-by: Dan Carpenter <dan.carpenter> Reviewed-by: Mathias Krause <minipli> Signed-off-by: Jan Kara <jack>
This was fixed for Fedora with the 5.16.6 stable kernel update.
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-1998