On Wed, Jul 24, 2024 at 2:24 AM Gabriel Krisman Bertazi gabriel@krisman.be wrote:
cel@kernel.org writes:
From: Chuck Lever chuck.lever@oracle.com
Gabriel says:
9709bd548f11 just enabled a new feature - which seems against stable rules. Considering that "anything is a CVE", we really need to be cautious about this kind of stuff in stable kernels.
Is it possible to drop 9709bd548f11 from stable instead?
The revert wasn't clean, but adjusting it to fit was straightforward. This passes NFSD CI, and adds no new failures to the fanotify ltp tests.
Reported-by: Gabriel Krisman Bertazi gabriel@krisman.be Signed-off-by: Chuck Lever chuck.lever@oracle.com
fs/notify/fanotify/fanotify_user.c | 4 ---- include/linux/fanotify.h | 6 +----- 2 files changed, 1 insertion(+), 9 deletions(-)
Gabriel, is this what you were thinking?
Thanks Chuck.
This looks good to me as a way to disable it in stable and prevent userspace from trying to use it. Up to fanotify maintainers to decide whether to bring the rest of the series or merge this,
First of all, the "rest of the series" is already queued for 5.10.y.
I too was a bit surprised from willingness of stable tree maintainers to allow backports of entire features along with Chuck's nfsd backports. I understand the logic, I was just not aware when this shift in stable ideology had happened.
But having backported the entire fanotify 6.1 code as is to 5.15 and 5.10 I see no reason to make an exception for FAN_FS_ERROR. Certainly not because two patches were left out of 5.10.y (and are now queued).
I think that the benefits of fanotify code parity across 6.1 5.15 5.10 outweigh the risk of regressions introduced by this specific feature.
So please do not revert.
Thanks, Amir.