The FSGEOMETRY_V1 ioctl (and its compat equivalent) calls out to xfs_fs_geometry() with a version number of 3. This code path does not fill in the logsunit member of the passed xfs_fsop_geom_t, leading to the leaking of four bytes of uninitialized stack data to potentially unprivileged callers. Since all other members are filled in all code paths and there are no padding bytes in this structure, it's safe to avoid an expensive memset() in favor of just clearing this one field. https://patchwork.kernel.org/patch/546491/ Acknowledgements: Red Hat would like to thank Dan Rosenberg for reporting this issue.
Upstream commit: http://git.kernel.org/linus/3a3675b7f23f83ca8c67c9c2b6edf707fd28d1ba
There's a bug in this commit, see "[PATCH] xfs: zero proper structure size for geometry calls" on the xfs list. But it is probably not going to affect x86_64 due to luck and padding...
(In reply to comment #4) > There's a bug in this commit, see "[PATCH] xfs: zero proper structure size for > geometry calls" on the xfs list. But it is probably not going to affect x86_64 > due to luck and padding... Thanks for the heads-up! http://www.spinics.net/lists/xfs/msg03801.html
(In reply to comment #5) > (In reply to comment #4) > > There's a bug in this commit, see "[PATCH] xfs: zero proper structure size for > > geometry calls" on the xfs list. But it is probably not going to affect x86_64 > > due to luck and padding... > > Thanks for the heads-up! > > http://www.spinics.net/lists/xfs/msg03801.html Version 3. http://www.spinics.net/lists/xfs/msg03806.html
(In reply to comment #6) > > Version 3. http://www.spinics.net/lists/xfs/msg03806.html Now in upstream http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=af24ee9ea8d532e16883251a6684dfa1be8eec29
If I understand this correctly then, both commits are needed. 3a3675b7f23f83ca8c67c9c2b6edf707fd28d1ba and af24ee9ea8d532e16883251a6684dfa1be8eec29 Is this correct?
(In reply to comment #8) > If I understand this correctly then, both commits are needed. > 3a3675b7f23f83ca8c67c9c2b6edf707fd28d1ba > and > af24ee9ea8d532e16883251a6684dfa1be8eec29 > > Is this correct? That is correct.
Due to padding on 64-bit arches, rhel may actually be fine, since we only ship xfs with x86_64. Nothing wrong with including the 2nd patch but if it causes lots of last-minute exception work, we may be ok without it.
(In reply to comment #10) > Due to padding on 64-bit arches, rhel may actually be fine, since we only ship > xfs with x86_64. > > Nothing wrong with including the 2nd patch but if it causes lots of last-minute > exception work, we may be ok without it. We ship XFS on the real-time kernel on both x86 and x86_64.
Statement: This issue did not affect the version of Linux kernel as shipped with Red Hat Enterprise Linux 4 as it did not have support for the XFS file system. This has been addressed in Red Hat Enterprise Linux 5, 6, and Red Hat Enterprise MRG via https://rhn.redhat.com/errata/RHSA-2011-0927.html, https://rhn.redhat.com/errata/RHSA-2011-0498.html, and https://rhn.redhat.com/errata/RHSA-2011-0500.html.
This issue has been addressed in following products: MRG for RHEL-5 Via RHSA-2011:0500 https://rhn.redhat.com/errata/RHSA-2011-0500.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:0498 https://rhn.redhat.com/errata/RHSA-2011-0498.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2011:0927 https://rhn.redhat.com/errata/RHSA-2011-0927.html