On Mon, Feb 05, 2024 at 05:29:53PM -0800, Eric Biggers wrote:
From: Alfred Piccioni alpic@google.com
commit f1bb47a31dff6d4b34fb14e99850860ee74bb003 upstream. [Please apply to 5.4-stable and 4.19-stable. The upstream commit failed to apply to these kernels. This patch resolves the conflicts.]
Some ioctl commands do not require ioctl permission, but are routed to other permissions such as FILE_GETATTR or FILE_SETATTR. This routing is done by comparing the ioctl cmd to a set of 64-bit flags (FS_IOC_*).
However, if a 32-bit process is running on a 64-bit kernel, it emits 32-bit flags (FS_IOC32_*) for certain ioctl operations. These flags are being checked erroneously, which leads to these ioctl operations being routed to the ioctl permission, rather than the correct file permissions.
This was also noted in a RED-PEN finding from a while back - "/* RED-PEN how should LSM module know it's handling 32bit? */".
This patch introduces a new hook, security_file_ioctl_compat(), that is called from the compat ioctl syscall. All current LSMs have been changed to support this hook.
Reviewing the three places where we are currently using security_file_ioctl(), it appears that only SELinux needs a dedicated compat change; TOMOYO and SMACK appear to be functional without any change.
Cc: stable@vger.kernel.org Fixes: 0b24dcb7f2f7 ("Revert "selinux: simplify ioctl checking"") Signed-off-by: Alfred Piccioni alpic@google.com Reviewed-by: Stephen Smalley stephen.smalley.work@gmail.com [PM: subject tweak, line length fixes, and alignment corrections] Signed-off-by: Paul Moore paul@paul-moore.com Signed-off-by: Eric Biggers ebiggers@google.com
Now queued up, thanks.
greg k-h