From: Andrey Albershteyn aalbersh@redhat.com
[ Upstream commit d90ad28e8aa482e397150e22f3762173d918a724 ]
These syscalls call to vfs_fileattr_get/set functions which return ENOIOCTLCMD if filesystem doesn't support setting file attribute on an inode. For syscalls EOPNOTSUPP would be more appropriate return error.
Signed-off-by: Andrey Albershteyn aalbersh@kernel.org Reviewed-by: Jan Kara jack@suse.cz Reviewed-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Christian Brauner brauner@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
## ANSWER: YES
This commit should be backported to stable kernel trees (specifically 6.17.x).
## Extensive Analysis
### 1. Code Changes Analysis
The commit adds error code translation at two syscall boundaries in `fs/file_attr.c`:
**In `file_getattr` syscall (line 418):** ```c error = vfs_fileattr_get(filepath.dentry, &fa); +if (error == -ENOIOCTLCMD || error == -ENOTTY) + error = -EOPNOTSUPP; if (error) return error; ```
**In `file_setattr` syscall (line 484):** ```c error = vfs_fileattr_set(mnt_idmap(filepath.mnt), filepath.dentry, &fa); +if (error == -ENOIOCTLCMD || error == -ENOTTY) + error = -EOPNOTSUPP; mnt_drop_write(filepath.mnt); ```
These are minimal, surgical changes that translate internal kernel error codes to appropriate user-space error codes.
### 2. Semantic Analysis Tools Used
**Tools utilized:** - `mcp__semcode__find_function`: Located the syscalls and vfs functions - `mcp__semcode__find_callers`: Identified all callers of vfs_fileattr_get/set (5 and 4 callers respectively) - `Read`, `Grep`, `Bash`: Examined code and git history - Git history analysis: Traced the evolution of this fix
**Key findings from tool usage:**
**Call graph analysis:** - `vfs_fileattr_get` is called by: - `file_getattr` syscall (the fix location) - `ioctl_fsgetxattr`, `ioctl_getflags` (ioctl handlers) - `ovl_real_fileattr_get`, `ecryptfs_fileattr_get` (filesystem wrappers)
- `vfs_fileattr_set` is called by: - `file_setattr` syscall (the fix location) - `ioctl_fssetxattr`, `ioctl_setflags` (ioctl handlers) - `ovl_real_fileattr_set`, `ecryptfs_fileattr_set` (filesystem wrappers)
**Impact scope:** - The fix ONLY affects the two new syscalls - Does NOT affect existing ioctl interfaces (critical - this was why the earlier vfs-level fix was reverted) - overlayfs already converts -ENOIOCTLCMD to -ENOTTY internally (fs/overlayfs/inode.c:724)
### 3. Critical Bug Analysis
**Error code verification:** - `-ENOIOCTLCMD` (error 515) is defined in `include/linux/errno.h` - a **kernel-internal header** - It is **NOT** in `include/uapi/` directories (user-space API) - This confirms -ENOIOCTLCMD should **NEVER** reach user-space - it's a kernel implementation detail - `-ENOTTY` (error 25) is valid for user-space but semantically inappropriate for non-ioctl syscalls - `-EOPNOTSUPP` is the correct POSIX error for "operation not supported"
### 4. Historical Context Analysis
Git history reveals a carefully considered approach:
1. **v6.17-rc1 (June 2025)**: New syscalls introduced (commit be7efb2d20d67) 2. **v6.17-rc1 (June 2025)**: First fix attempt at vfs level (commit 474b155adf392) 3. **October 2025**: Vfs fix reverted due to regression in `ioctl_setflags()` (commit 4dd5b5ac089bb) - Problem: Filesystems use -EOPNOTSUPP to indicate unsupported flags - Vfs-level translation caused error code confusion for ioctls 4. **October 2025**: Current fix at syscall level (commit d90ad28e8aa48) - Merged in v6.18-rc2 - Does NOT affect ioctl behavior - Solves the problem without regressions
### 5. Backport Suitability Assessment
**STRONG YES indicators:**
✅ **Fixes real user-impacting bug**: Internal error codes leak to user- space ✅ **Minimal risk**: Only 4 lines changed, pure error code translation ✅ **Well-tested approach**: Previous vfs-level fix was reverted; this approach is proven safer ✅ **Affects recent feature**: Syscalls introduced in v6.17, so 6.17.x needs this fix ✅ **Active usage**: XFS already using these syscalls (commits 0239bd9fa445a, 8a221004fe528) ✅ **Reviewed by experts**: Jan Kara and Arnd Bergmann reviewed ✅ **No follow-up fixes or reverts**: The commit stands without issues ✅ **Stable tree precedent**: Related revert was already backported (commit 0cfb126205ecc)
**Current status:** - Fix merged in v6.18-rc2 - **NOT present** in current 6.17.5 stable tree (verified via `git merge-base`) - Syscalls present in 6.17.x but returning wrong error codes
### 6. Why No Explicit Stable Tag?
The commit lacks `Cc: stable@vger.kernel.org` or `Fixes:` tags, likely because: - The syscalls are brand new (only in v6.17) - Maintainers may have expected it to flow naturally to stable - Limited user-space adoption at the time meant low immediate impact
However, this doesn't diminish the need for backporting - it prevents the bug from becoming entrenched as applications start using these syscalls.
### 7. Compliance with Stable Tree Rules
✅ **Bug fix**: Yes - fixes ABI violation (internal error code exposure) ✅ **Important**: Yes - affects syscall interface correctness ✅ **Obvious and correct**: Yes - simple error code translation ✅ **Tested**: Yes - in mainline since v6.18-rc2 ✅ **Minimal**: Yes - only 4 lines ✅ **No new features**: Correct - only fixes existing functionality ✅ **No architectural changes**: Correct - localized syscall boundary fix
### Conclusion
This is an excellent backport candidate that fixes a genuine ABI bug (kernel-internal error codes leaking to user-space) in newly introduced syscalls. The fix is minimal, safe, well-reviewed, and specifically targets the 6.17.x stable tree where the bug exists. Backporting now prevents applications from depending on incorrect error codes.
fs/file_attr.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/fs/file_attr.c b/fs/file_attr.c index 460b2dd21a852..1dcec88c06805 100644 --- a/fs/file_attr.c +++ b/fs/file_attr.c @@ -416,6 +416,8 @@ SYSCALL_DEFINE5(file_getattr, int, dfd, const char __user *, filename, }
error = vfs_fileattr_get(filepath.dentry, &fa); + if (error == -ENOIOCTLCMD || error == -ENOTTY) + error = -EOPNOTSUPP; if (error) return error;
@@ -483,6 +485,8 @@ SYSCALL_DEFINE5(file_setattr, int, dfd, const char __user *, filename, if (!error) { error = vfs_fileattr_set(mnt_idmap(filepath.mnt), filepath.dentry, &fa); + if (error == -ENOIOCTLCMD || error == -ENOTTY) + error = -EOPNOTSUPP; mnt_drop_write(filepath.mnt); }