A malformed SG_IO ioctl issued for a SCSI device in the Linux kernel leads to a local kernel data leak manifesting in up to approx. 1000 memory pages copied to the userspace. The problem has limited scope, as non-privileged users usually have no permissions to access SCSI device files. References: http://seclists.org/oss-sec/2018/q2/168 An upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a45b599ad808c3c982fdcdc12b0b8611c2f92824 https://marc.info/?l=linux-scsi&m=152933023515279&w=2 (suggested but not approved at the time of this writing)
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1589688]
This was fixed for Fedora with the 4.16.12 stable updates.
(In reply to Pedro Sampaio from comment #0) > A malformed SG_IO ioctl issued for a SCSI device in the Linux kernel leads > to a local kernel data leak manifesting in up to approx. 1000 memory pages > copied to the userspace. The problem has limited scope, as non-privileged > users usually have no permissions to access SCSI device files. ^^^^^^^ The allocation will be zeroed if the user doesn't have the right capabilities: if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO)) gfp_mask |= __GFP_ZERO; The justification for this as a security issue was that documentation guided users to chmod the sg device to be world writeable. That isn't enough to cause a data leak. I'd say this is not a security issue at all. If you have CAP_SYS_ADMIN or CAP_SYS_RAWIO, it's game over already. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=a45b599ad808c3c982fdcdc12b0b8611c2f92824 And this patch was poorly done, IMO. Here's the follow-up I sent upstream: https://marc.info/?l=linux-scsi&m=152933023515279&w=2
(In reply to Jeff Moyer from comment #7) > The justification for this as a security issue was that documentation guided > users to chmod the sg device to be world writeable. That isn't enough to > cause a data leak. Indeed, thank you Jeff for mentioning this. So a data leak is possible only when a user is granted CAP_SYS_ADMIN or CAP_SYS_RAWIO (not in the namespaces) and it is not root. Which makes an attack surface and a security impact quite small. We are going to adjust a security impact of this flaw to Low.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2018:2948 https://access.redhat.com/errata/RHSA-2018:2948