* XFS security fix never sent to -stable?
@ 2013-12-06 0:35 Kees Cook
2013-12-06 14:43 ` Dwight Engen
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: Kees Cook @ 2013-12-06 0:35 UTC (permalink / raw)
To: Dwight Engen
Cc: LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH
Hi,
It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add
capability check to free eofblocks ioctl") is a security fix that was
never sent to -stable? From what I can see, it was introduced in 3.8
by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add
XFS_IOC_FREE_EOFBLOCKS ioctl").
I don't see this in the 3.8.y tree. Should it be added there and newer?
Thanks,
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: XFS security fix never sent to -stable? 2013-12-06 0:35 XFS security fix never sent to -stable? Kees Cook @ 2013-12-06 14:43 ` Dwight Engen 2013-12-06 15:06 ` Brian Foster 2013-12-09 12:15 ` Luis Henriques 2013-12-09 23:30 ` Dave Chinner 2 siblings, 1 reply; 37+ messages in thread From: Dwight Engen @ 2013-12-06 14:43 UTC (permalink / raw) To: Kees Cook; +Cc: LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH On Thu, 5 Dec 2013 16:35:50 -0800 Kees Cook <keescook@google.com> wrote: > Hi, > > It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add > capability check to free eofblocks ioctl") is a security fix that was > never sent to -stable? From what I can see, it was introduced in 3.8 > by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > XFS_IOC_FREE_EOFBLOCKS ioctl"). > > I don't see this in the 3.8.y tree. Should it be added there and > newer? I believe that would be appropriate, but would defer to Brian as the original author of the eofblocks change. > Thanks, > > -Kees > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-06 14:43 ` Dwight Engen @ 2013-12-06 15:06 ` Brian Foster 0 siblings, 0 replies; 37+ messages in thread From: Brian Foster @ 2013-12-06 15:06 UTC (permalink / raw) To: Dwight Engen, Kees Cook; +Cc: LKML, Dave Chinner, Gao feng, Ben Myers, Greg KH On 12/06/2013 09:43 AM, Dwight Engen wrote: > On Thu, 5 Dec 2013 16:35:50 -0800 > Kees Cook <keescook@google.com> wrote: > >> Hi, >> >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add >> capability check to free eofblocks ioctl") is a security fix that was >> never sent to -stable? From what I can see, it was introduced in 3.8 >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add >> XFS_IOC_FREE_EOFBLOCKS ioctl"). >> >> I don't see this in the 3.8.y tree. Should it be added there and >> newer? > > I believe that would be appropriate, but would defer to Brian as the > original author of the eofblocks change. > I have no objection to proposing this for stable. The fix is straightforward and isolated enough. Brian >> Thanks, >> >> -Kees >> > ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-06 0:35 XFS security fix never sent to -stable? Kees Cook 2013-12-06 14:43 ` Dwight Engen @ 2013-12-09 12:15 ` Luis Henriques 2013-12-09 13:17 ` Josh Boyer 2013-12-09 23:30 ` Dave Chinner 2 siblings, 1 reply; 37+ messages in thread From: Luis Henriques @ 2013-12-09 12:15 UTC (permalink / raw) To: Kees Cook Cc: Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > Hi, > > It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add > capability check to free eofblocks ioctl") is a security fix that was > never sent to -stable? From what I can see, it was introduced in 3.8 > by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > XFS_IOC_FREE_EOFBLOCKS ioctl"). > > I don't see this in the 3.8.y tree. Should it be added there and newer? Thanks Kees, I'm queuing it for the 3.11 kernel. Cheers, -- Luis ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-09 12:15 ` Luis Henriques @ 2013-12-09 13:17 ` Josh Boyer 2013-12-09 23:55 ` Dave Chinner 0 siblings, 1 reply; 37+ messages in thread From: Josh Boyer @ 2013-12-09 13:17 UTC (permalink / raw) To: Luis Henriques Cc: Kees Cook, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques <luis.henriques@canonical.com> wrote: > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: >> Hi, >> >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add >> capability check to free eofblocks ioctl") is a security fix that was >> never sent to -stable? From what I can see, it was introduced in 3.8 >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add >> XFS_IOC_FREE_EOFBLOCKS ioctl"). >> >> I don't see this in the 3.8.y tree. Should it be added there and newer? > > Thanks Kees, I'm queuing it for the 3.11 kernel. There's also this one: http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 It fixes CVE-2013-6382 josh ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-09 13:17 ` Josh Boyer @ 2013-12-09 23:55 ` Dave Chinner 0 siblings, 0 replies; 37+ messages in thread From: Dave Chinner @ 2013-12-09 23:55 UTC (permalink / raw) To: Josh Boyer Cc: Luis Henriques, Greg KH, Brian Foster, Kees Cook, Dwight Engen, LKML, stable, xfs, Ben Myers, Gao feng, Dave Chinner [cc xfs list, cc stable@vger.kernel.org] On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: > On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques > <luis.henriques@canonical.com> wrote: > > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > >> Hi, > >> > >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add > >> capability check to free eofblocks ioctl") is a security fix that was > >> never sent to -stable? From what I can see, it was introduced in 3.8 > >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > >> XFS_IOC_FREE_EOFBLOCKS ioctl"). > >> > >> I don't see this in the 3.8.y tree. Should it be added there and newer? > > > > Thanks Kees, I'm queuing it for the 3.11 kernel. > > There's also this one: > > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 > > It fixes CVE-2013-6382 First I've heard about it there being a CVE for that bug. Since when has it been considered best practice to publish CVEs without first (or ever) directly contacting the relevant upstream developers? But, regardless of how broken I think the CVE process is, commit 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be picked up by the stable kernels. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-09 23:55 ` Dave Chinner 0 siblings, 0 replies; 37+ messages in thread From: Dave Chinner @ 2013-12-09 23:55 UTC (permalink / raw) To: Josh Boyer Cc: Luis Henriques, Kees Cook, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH, xfs, stable [cc xfs list, cc stable@vger.kernel.org] On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: > On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques > <luis.henriques@canonical.com> wrote: > > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > >> Hi, > >> > >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add > >> capability check to free eofblocks ioctl") is a security fix that was > >> never sent to -stable? From what I can see, it was introduced in 3.8 > >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > >> XFS_IOC_FREE_EOFBLOCKS ioctl"). > >> > >> I don't see this in the 3.8.y tree. Should it be added there and newer? > > > > Thanks Kees, I'm queuing it for the 3.11 kernel. > > There's also this one: > > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 > > It fixes CVE-2013-6382 First I've heard about it there being a CVE for that bug. Since when has it been considered best practice to publish CVEs without first (or ever) directly contacting the relevant upstream developers? But, regardless of how broken I think the CVE process is, commit 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be picked up by the stable kernels. Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-09 23:55 ` Dave Chinner @ 2013-12-10 7:56 ` Greg KH -1 siblings, 0 replies; 37+ messages in thread From: Greg KH @ 2013-12-10 7:56 UTC (permalink / raw) To: Dave Chinner Cc: Josh Boyer, Luis Henriques, Brian Foster, Dave Chinner, Dwight Engen, LKML, stable, xfs, Ben Myers, Gao feng, Kees Cook On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote: > [cc xfs list, cc stable@vger.kernel.org] > > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: > > On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques > > <luis.henriques@canonical.com> wrote: > > > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > > >> Hi, > > >> > > >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add > > >> capability check to free eofblocks ioctl") is a security fix that was > > >> never sent to -stable? From what I can see, it was introduced in 3.8 > > >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > > >> XFS_IOC_FREE_EOFBLOCKS ioctl"). > > >> > > >> I don't see this in the 3.8.y tree. Should it be added there and newer? > > > > > > Thanks Kees, I'm queuing it for the 3.11 kernel. > > > > There's also this one: > > > > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 > > > > It fixes CVE-2013-6382 > > First I've heard about it there being a CVE for that bug. Since when > has it been considered best practice to publish CVEs without first > (or ever) directly contacting the relevant upstream developers? > > But, regardless of how broken I think the CVE process is, commit > 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be > picked up by the stable kernels. I don't see that commit in Linus's tree, is it not there yet? thanks, greg k-h _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-10 7:56 ` Greg KH 0 siblings, 0 replies; 37+ messages in thread From: Greg KH @ 2013-12-10 7:56 UTC (permalink / raw) To: Dave Chinner Cc: Josh Boyer, Luis Henriques, Kees Cook, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, xfs, stable On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote: > [cc xfs list, cc stable@vger.kernel.org] > > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: > > On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques > > <luis.henriques@canonical.com> wrote: > > > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > > >> Hi, > > >> > > >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add > > >> capability check to free eofblocks ioctl") is a security fix that was > > >> never sent to -stable? From what I can see, it was introduced in 3.8 > > >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > > >> XFS_IOC_FREE_EOFBLOCKS ioctl"). > > >> > > >> I don't see this in the 3.8.y tree. Should it be added there and newer? > > > > > > Thanks Kees, I'm queuing it for the 3.11 kernel. > > > > There's also this one: > > > > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 > > > > It fixes CVE-2013-6382 > > First I've heard about it there being a CVE for that bug. Since when > has it been considered best practice to publish CVEs without first > (or ever) directly contacting the relevant upstream developers? > > But, regardless of how broken I think the CVE process is, commit > 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be > picked up by the stable kernels. I don't see that commit in Linus's tree, is it not there yet? thanks, greg k-h ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-10 7:56 ` Greg KH @ 2013-12-10 13:15 ` Josh Boyer -1 siblings, 0 replies; 37+ messages in thread From: Josh Boyer @ 2013-12-10 13:15 UTC (permalink / raw) To: Greg KH Cc: Luis Henriques, Brian Foster, Dave Chinner, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Ben Myers, Gao feng, Kees Cook On Tue, Dec 10, 2013 at 2:56 AM, Greg KH <gregkh@linuxfoundation.org> wrote: > On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote: >> [cc xfs list, cc stable@vger.kernel.org] >> >> On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: >> > On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques >> > <luis.henriques@canonical.com> wrote: >> > > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: >> > >> Hi, >> > >> >> > >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add >> > >> capability check to free eofblocks ioctl") is a security fix that was >> > >> never sent to -stable? From what I can see, it was introduced in 3.8 >> > >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add >> > >> XFS_IOC_FREE_EOFBLOCKS ioctl"). >> > >> >> > >> I don't see this in the 3.8.y tree. Should it be added there and newer? >> > > >> > > Thanks Kees, I'm queuing it for the 3.11 kernel. >> > >> > There's also this one: >> > >> > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 >> > >> > It fixes CVE-2013-6382 >> >> First I've heard about it there being a CVE for that bug. Since when >> has it been considered best practice to publish CVEs without first >> (or ever) directly contacting the relevant upstream developers? >> >> But, regardless of how broken I think the CVE process is, commit >> 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be >> picked up by the stable kernels. > > I don't see that commit in Linus's tree, is it not there yet? Not yet. Ben said it's applied but I'm not sure where that is. josh _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-10 13:15 ` Josh Boyer 0 siblings, 0 replies; 37+ messages in thread From: Josh Boyer @ 2013-12-10 13:15 UTC (permalink / raw) To: Greg KH Cc: Dave Chinner, Luis Henriques, Kees Cook, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, xfs, stable@vger.kernel.org On Tue, Dec 10, 2013 at 2:56 AM, Greg KH <gregkh@linuxfoundation.org> wrote: > On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote: >> [cc xfs list, cc stable@vger.kernel.org] >> >> On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: >> > On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques >> > <luis.henriques@canonical.com> wrote: >> > > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: >> > >> Hi, >> > >> >> > >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add >> > >> capability check to free eofblocks ioctl") is a security fix that was >> > >> never sent to -stable? From what I can see, it was introduced in 3.8 >> > >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add >> > >> XFS_IOC_FREE_EOFBLOCKS ioctl"). >> > >> >> > >> I don't see this in the 3.8.y tree. Should it be added there and newer? >> > > >> > > Thanks Kees, I'm queuing it for the 3.11 kernel. >> > >> > There's also this one: >> > >> > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 >> > >> > It fixes CVE-2013-6382 >> >> First I've heard about it there being a CVE for that bug. Since when >> has it been considered best practice to publish CVEs without first >> (or ever) directly contacting the relevant upstream developers? >> >> But, regardless of how broken I think the CVE process is, commit >> 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be >> picked up by the stable kernels. > > I don't see that commit in Linus's tree, is it not there yet? Not yet. Ben said it's applied but I'm not sure where that is. josh ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-10 13:15 ` Josh Boyer @ 2013-12-10 14:31 ` Eric Sandeen -1 siblings, 0 replies; 37+ messages in thread From: Eric Sandeen @ 2013-12-10 14:31 UTC (permalink / raw) To: Josh Boyer, Greg KH Cc: Luis Henriques, Brian Foster, Kees Cook, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Ben Myers, Gao feng, Dave Chinner On 12/10/13, 7:15 AM, Josh Boyer wrote: > On Tue, Dec 10, 2013 at 2:56 AM, Greg KH <gregkh@linuxfoundation.org> wrote: >> On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote: >>> [cc xfs list, cc stable@vger.kernel.org] >>> >>> On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: >>>> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques >>>> <luis.henriques@canonical.com> wrote: >>>>> On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: >>>>>> Hi, >>>>>> >>>>>> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add >>>>>> capability check to free eofblocks ioctl") is a security fix that was >>>>>> never sent to -stable? From what I can see, it was introduced in 3.8 >>>>>> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add >>>>>> XFS_IOC_FREE_EOFBLOCKS ioctl"). >>>>>> >>>>>> I don't see this in the 3.8.y tree. Should it be added there and newer? >>>>> >>>>> Thanks Kees, I'm queuing it for the 3.11 kernel. >>>> >>>> There's also this one: >>>> >>>> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 >>>> >>>> It fixes CVE-2013-6382 >>> >>> First I've heard about it there being a CVE for that bug. Since when >>> has it been considered best practice to publish CVEs without first >>> (or ever) directly contacting the relevant upstream developers? >>> >>> But, regardless of how broken I think the CVE process is, commit >>> 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be >>> picked up by the stable kernels. >> >> I don't see that commit in Linus's tree, is it not there yet? > > Not yet. Ben said it's applied but I'm not sure where that is. xfs git tree: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=071c529eb672648ee8ca3f90944bcbcc730b4c06 -Eric > josh _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-10 14:31 ` Eric Sandeen 0 siblings, 0 replies; 37+ messages in thread From: Eric Sandeen @ 2013-12-10 14:31 UTC (permalink / raw) To: Josh Boyer, Greg KH Cc: Luis Henriques, Brian Foster, Dave Chinner, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Ben Myers, Gao feng, Kees Cook On 12/10/13, 7:15 AM, Josh Boyer wrote: > On Tue, Dec 10, 2013 at 2:56 AM, Greg KH <gregkh@linuxfoundation.org> wrote: >> On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote: >>> [cc xfs list, cc stable@vger.kernel.org] >>> >>> On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: >>>> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques >>>> <luis.henriques@canonical.com> wrote: >>>>> On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: >>>>>> Hi, >>>>>> >>>>>> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add >>>>>> capability check to free eofblocks ioctl") is a security fix that was >>>>>> never sent to -stable? From what I can see, it was introduced in 3.8 >>>>>> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add >>>>>> XFS_IOC_FREE_EOFBLOCKS ioctl"). >>>>>> >>>>>> I don't see this in the 3.8.y tree. Should it be added there and newer? >>>>> >>>>> Thanks Kees, I'm queuing it for the 3.11 kernel. >>>> >>>> There's also this one: >>>> >>>> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 >>>> >>>> It fixes CVE-2013-6382 >>> >>> First I've heard about it there being a CVE for that bug. Since when >>> has it been considered best practice to publish CVEs without first >>> (or ever) directly contacting the relevant upstream developers? >>> >>> But, regardless of how broken I think the CVE process is, commit >>> 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be >>> picked up by the stable kernels. >> >> I don't see that commit in Linus's tree, is it not there yet? > > Not yet. Ben said it's applied but I'm not sure where that is. xfs git tree: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=071c529eb672648ee8ca3f90944bcbcc730b4c06 -Eric > josh ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-10 14:31 ` Eric Sandeen @ 2013-12-10 15:57 ` Ben Myers -1 siblings, 0 replies; 37+ messages in thread From: Ben Myers @ 2013-12-10 15:57 UTC (permalink / raw) To: Eric Sandeen Cc: Josh Boyer, Luis Henriques, Greg KH, Brian Foster, Dave Chinner, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Gao feng, Kees Cook Hi, On Tue, Dec 10, 2013 at 08:31:23AM -0600, Eric Sandeen wrote: > On 12/10/13, 7:15 AM, Josh Boyer wrote: > > On Tue, Dec 10, 2013 at 2:56 AM, Greg KH <gregkh@linuxfoundation.org> wrote: > >> On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote: > >>> [cc xfs list, cc stable@vger.kernel.org] > >>> > >>> On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: > >>>> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques > >>>> <luis.henriques@canonical.com> wrote: > >>>>> On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > >>>>>> Hi, > >>>>>> > >>>>>> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add > >>>>>> capability check to free eofblocks ioctl") is a security fix that was > >>>>>> never sent to -stable? From what I can see, it was introduced in 3.8 > >>>>>> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > >>>>>> XFS_IOC_FREE_EOFBLOCKS ioctl"). > >>>>>> > >>>>>> I don't see this in the 3.8.y tree. Should it be added there and newer? > >>>>> > >>>>> Thanks Kees, I'm queuing it for the 3.11 kernel. > >>>> > >>>> There's also this one: > >>>> > >>>> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 > >>>> > >>>> It fixes CVE-2013-6382 > >>> > >>> First I've heard about it there being a CVE for that bug. Since when > >>> has it been considered best practice to publish CVEs without first > >>> (or ever) directly contacting the relevant upstream developers? > >>> > >>> But, regardless of how broken I think the CVE process is, commit > >>> 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be > >>> picked up by the stable kernels. > >> > >> I don't see that commit in Linus's tree, is it not there yet? > > > > Not yet. Ben said it's applied but I'm not sure where that is. > > xfs git tree: > > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=071c529eb672648ee8ca3f90944bcbcc730b4c06 I'll send a pull request containing this commit this afternoon. Thanks, Ben _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-10 15:57 ` Ben Myers 0 siblings, 0 replies; 37+ messages in thread From: Ben Myers @ 2013-12-10 15:57 UTC (permalink / raw) To: Eric Sandeen Cc: Josh Boyer, Greg KH, Luis Henriques, Brian Foster, Kees Cook, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Gao feng, Dave Chinner Hi, On Tue, Dec 10, 2013 at 08:31:23AM -0600, Eric Sandeen wrote: > On 12/10/13, 7:15 AM, Josh Boyer wrote: > > On Tue, Dec 10, 2013 at 2:56 AM, Greg KH <gregkh@linuxfoundation.org> wrote: > >> On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote: > >>> [cc xfs list, cc stable@vger.kernel.org] > >>> > >>> On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: > >>>> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques > >>>> <luis.henriques@canonical.com> wrote: > >>>>> On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > >>>>>> Hi, > >>>>>> > >>>>>> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add > >>>>>> capability check to free eofblocks ioctl") is a security fix that was > >>>>>> never sent to -stable? From what I can see, it was introduced in 3.8 > >>>>>> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > >>>>>> XFS_IOC_FREE_EOFBLOCKS ioctl"). > >>>>>> > >>>>>> I don't see this in the 3.8.y tree. Should it be added there and newer? > >>>>> > >>>>> Thanks Kees, I'm queuing it for the 3.11 kernel. > >>>> > >>>> There's also this one: > >>>> > >>>> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 > >>>> > >>>> It fixes CVE-2013-6382 > >>> > >>> First I've heard about it there being a CVE for that bug. Since when > >>> has it been considered best practice to publish CVEs without first > >>> (or ever) directly contacting the relevant upstream developers? > >>> > >>> But, regardless of how broken I think the CVE process is, commit > >>> 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be > >>> picked up by the stable kernels. > >> > >> I don't see that commit in Linus's tree, is it not there yet? > > > > Not yet. Ben said it's applied but I'm not sure where that is. > > xfs git tree: > > http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs.git;a=commitdiff;h=071c529eb672648ee8ca3f90944bcbcc730b4c06 I'll send a pull request containing this commit this afternoon. Thanks, Ben ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-10 7:56 ` Greg KH @ 2013-12-17 13:58 ` Luis Henriques -1 siblings, 0 replies; 37+ messages in thread From: Luis Henriques @ 2013-12-17 13:58 UTC (permalink / raw) To: Greg KH Cc: Josh Boyer, Brian Foster, Dave Chinner, Dwight Engen, LKML, stable, xfs, Ben Myers, Gao feng, Kees Cook On Mon, Dec 09, 2013 at 11:56:21PM -0800, Greg Kroah-Hartman wrote: > On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote: > > [cc xfs list, cc stable@vger.kernel.org] > > > > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: > > > On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques > > > <luis.henriques@canonical.com> wrote: > > > > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > > > >> Hi, > > > >> > > > >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add > > > >> capability check to free eofblocks ioctl") is a security fix that was > > > >> never sent to -stable? From what I can see, it was introduced in 3.8 > > > >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > > > >> XFS_IOC_FREE_EOFBLOCKS ioctl"). > > > >> > > > >> I don't see this in the 3.8.y tree. Should it be added there and newer? > > > > > > > > Thanks Kees, I'm queuing it for the 3.11 kernel. > > > > > > There's also this one: > > > > > > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 > > > > > > It fixes CVE-2013-6382 > > > > First I've heard about it there being a CVE for that bug. Since when > > has it been considered best practice to publish CVEs without first > > (or ever) directly contacting the relevant upstream developers? > > > > But, regardless of how broken I think the CVE process is, commit > > 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be > > picked up by the stable kernels. > > I don't see that commit in Linus's tree, is it not there yet? This commit is now in Linus's: 31978b5 xfs: underflow bug in xfs_attrlist_by_handle() Cheers, -- Luis _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-17 13:58 ` Luis Henriques 0 siblings, 0 replies; 37+ messages in thread From: Luis Henriques @ 2013-12-17 13:58 UTC (permalink / raw) To: Greg KH Cc: Dave Chinner, Josh Boyer, Kees Cook, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, xfs, stable On Mon, Dec 09, 2013 at 11:56:21PM -0800, Greg Kroah-Hartman wrote: > On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote: > > [cc xfs list, cc stable@vger.kernel.org] > > > > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: > > > On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques > > > <luis.henriques@canonical.com> wrote: > > > > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > > > >> Hi, > > > >> > > > >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add > > > >> capability check to free eofblocks ioctl") is a security fix that was > > > >> never sent to -stable? From what I can see, it was introduced in 3.8 > > > >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > > > >> XFS_IOC_FREE_EOFBLOCKS ioctl"). > > > >> > > > >> I don't see this in the 3.8.y tree. Should it be added there and newer? > > > > > > > > Thanks Kees, I'm queuing it for the 3.11 kernel. > > > > > > There's also this one: > > > > > > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 > > > > > > It fixes CVE-2013-6382 > > > > First I've heard about it there being a CVE for that bug. Since when > > has it been considered best practice to publish CVEs without first > > (or ever) directly contacting the relevant upstream developers? > > > > But, regardless of how broken I think the CVE process is, commit > > 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be > > picked up by the stable kernels. > > I don't see that commit in Linus's tree, is it not there yet? This commit is now in Linus's: 31978b5 xfs: underflow bug in xfs_attrlist_by_handle() Cheers, -- Luis ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-09 23:55 ` Dave Chinner @ 2013-12-10 13:20 ` Josh Boyer -1 siblings, 0 replies; 37+ messages in thread From: Josh Boyer @ 2013-12-10 13:20 UTC (permalink / raw) To: Dave Chinner Cc: Luis Henriques, Greg KH, Brian Foster, Kees Cook, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Ben Myers, Gao feng, Dave Chinner On Mon, Dec 9, 2013 at 6:55 PM, Dave Chinner <david@fromorbit.com> wrote: > [cc xfs list, cc stable@vger.kernel.org] > > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: >> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques >> <luis.henriques@canonical.com> wrote: >> > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: >> >> Hi, >> >> >> >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add >> >> capability check to free eofblocks ioctl") is a security fix that was >> >> never sent to -stable? From what I can see, it was introduced in 3.8 >> >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add >> >> XFS_IOC_FREE_EOFBLOCKS ioctl"). >> >> >> >> I don't see this in the 3.8.y tree. Should it be added there and newer? >> > >> > Thanks Kees, I'm queuing it for the 3.11 kernel. >> >> There's also this one: >> >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 >> >> It fixes CVE-2013-6382 > > First I've heard about it there being a CVE for that bug. Since when > has it been considered best practice to publish CVEs without first > (or ever) directly contacting the relevant upstream developers? We got a Fedora bug for it, and there are similar RHEL bugs open. I had assumed you would be informed either via upstream or through those. The CVE request was submitted by Kees here: http://seclists.org/oss-sec/2013/q4/330 josh _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-10 13:20 ` Josh Boyer 0 siblings, 0 replies; 37+ messages in thread From: Josh Boyer @ 2013-12-10 13:20 UTC (permalink / raw) To: Dave Chinner Cc: Luis Henriques, Kees Cook, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH, xfs, stable@vger.kernel.org On Mon, Dec 9, 2013 at 6:55 PM, Dave Chinner <david@fromorbit.com> wrote: > [cc xfs list, cc stable@vger.kernel.org] > > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: >> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques >> <luis.henriques@canonical.com> wrote: >> > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: >> >> Hi, >> >> >> >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add >> >> capability check to free eofblocks ioctl") is a security fix that was >> >> never sent to -stable? From what I can see, it was introduced in 3.8 >> >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add >> >> XFS_IOC_FREE_EOFBLOCKS ioctl"). >> >> >> >> I don't see this in the 3.8.y tree. Should it be added there and newer? >> > >> > Thanks Kees, I'm queuing it for the 3.11 kernel. >> >> There's also this one: >> >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 >> >> It fixes CVE-2013-6382 > > First I've heard about it there being a CVE for that bug. Since when > has it been considered best practice to publish CVEs without first > (or ever) directly contacting the relevant upstream developers? We got a Fedora bug for it, and there are similar RHEL bugs open. I had assumed you would be informed either via upstream or through those. The CVE request was submitted by Kees here: http://seclists.org/oss-sec/2013/q4/330 josh ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-10 13:20 ` Josh Boyer @ 2013-12-11 1:03 ` Dave Chinner -1 siblings, 0 replies; 37+ messages in thread From: Dave Chinner @ 2013-12-11 1:03 UTC (permalink / raw) To: Josh Boyer Cc: Luis Henriques, Greg KH, Brian Foster, Kees Cook, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Ben Myers, Gao feng, Dave Chinner On Tue, Dec 10, 2013 at 08:20:07AM -0500, Josh Boyer wrote: > On Mon, Dec 9, 2013 at 6:55 PM, Dave Chinner <david@fromorbit.com> > wrote: > > [cc xfs list, cc stable@vger.kernel.org] > > > > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: > >> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques > >> <luis.henriques@canonical.com> wrote: > >> > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > >> >> Hi, > >> >> > >> >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c > >> >> ("xfs: add capability check to free eofblocks ioctl") is a > >> >> security fix that was never sent to -stable? From what I can > >> >> see, it was introduced in 3.8 by > >> >> 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > >> >> XFS_IOC_FREE_EOFBLOCKS ioctl"). > >> >> > >> >> I don't see this in the 3.8.y tree. Should it be added there > >> >> and newer? > >> > > >> > Thanks Kees, I'm queuing it for the 3.11 kernel. > >> > >> There's also this one: > >> > >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 > >> > >> It fixes CVE-2013-6382 > > > > First I've heard about it there being a CVE for that bug. Since > > when has it been considered best practice to publish CVEs > > without first (or ever) directly contacting the relevant > > upstream developers? > > We got a Fedora bug for it, and there are similar RHEL bugs open. > I had assumed you would be informed either via upstream or > through those. I've not been cc'd on any of those bugs internally at RH, so I don't have visibility of the problems unless someone specifically adds me to those bugs. As it is, raising fedora/RHEL bugs is not informing upstream - it is a distro process for tracking the distro issue through to closure. > The CVE request was submitted by Kees here: > http://seclists.org/oss-sec/2013/q4/330 Ugh, no, I'm not going to subscribe to a high noise list where the only way I might be informed of a CVE being raised is by following links to git commit IDs.... Upstream is not magically informed about CVEs, and relying on upstream developers to scan or poll *anything* just to find if a CVE on their subsystem has been released is not reliable and does not scale. If anyone raises a CVE against a kernel subsystem, then the relevant list in the MAINTAINERS file for that subsystem should be on the cc list of any discussion about the CVE, and on the announcement of the CVE. Security processes are not something that should be hidden away in it's own private corner - if there's a problem upstream needs to take action on, then direct contact with upstream is necessary. We need to know about security issues - even ones that are classified post-commit as security issues - so we are operating with full knowledge of the issues in our code and the impact of our fixes.... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-11 1:03 ` Dave Chinner 0 siblings, 0 replies; 37+ messages in thread From: Dave Chinner @ 2013-12-11 1:03 UTC (permalink / raw) To: Josh Boyer Cc: Luis Henriques, Kees Cook, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH, xfs, stable@vger.kernel.org On Tue, Dec 10, 2013 at 08:20:07AM -0500, Josh Boyer wrote: > On Mon, Dec 9, 2013 at 6:55 PM, Dave Chinner <david@fromorbit.com> > wrote: > > [cc xfs list, cc stable@vger.kernel.org] > > > > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: > >> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques > >> <luis.henriques@canonical.com> wrote: > >> > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > >> >> Hi, > >> >> > >> >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c > >> >> ("xfs: add capability check to free eofblocks ioctl") is a > >> >> security fix that was never sent to -stable? From what I can > >> >> see, it was introduced in 3.8 by > >> >> 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > >> >> XFS_IOC_FREE_EOFBLOCKS ioctl"). > >> >> > >> >> I don't see this in the 3.8.y tree. Should it be added there > >> >> and newer? > >> > > >> > Thanks Kees, I'm queuing it for the 3.11 kernel. > >> > >> There's also this one: > >> > >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 > >> > >> It fixes CVE-2013-6382 > > > > First I've heard about it there being a CVE for that bug. Since > > when has it been considered best practice to publish CVEs > > without first (or ever) directly contacting the relevant > > upstream developers? > > We got a Fedora bug for it, and there are similar RHEL bugs open. > I had assumed you would be informed either via upstream or > through those. I've not been cc'd on any of those bugs internally at RH, so I don't have visibility of the problems unless someone specifically adds me to those bugs. As it is, raising fedora/RHEL bugs is not informing upstream - it is a distro process for tracking the distro issue through to closure. > The CVE request was submitted by Kees here: > http://seclists.org/oss-sec/2013/q4/330 Ugh, no, I'm not going to subscribe to a high noise list where the only way I might be informed of a CVE being raised is by following links to git commit IDs.... Upstream is not magically informed about CVEs, and relying on upstream developers to scan or poll *anything* just to find if a CVE on their subsystem has been released is not reliable and does not scale. If anyone raises a CVE against a kernel subsystem, then the relevant list in the MAINTAINERS file for that subsystem should be on the cc list of any discussion about the CVE, and on the announcement of the CVE. Security processes are not something that should be hidden away in it's own private corner - if there's a problem upstream needs to take action on, then direct contact with upstream is necessary. We need to know about security issues - even ones that are classified post-commit as security issues - so we are operating with full knowledge of the issues in our code and the impact of our fixes.... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-11 1:03 ` Dave Chinner @ 2013-12-11 1:10 ` Josh Boyer -1 siblings, 0 replies; 37+ messages in thread From: Josh Boyer @ 2013-12-11 1:10 UTC (permalink / raw) To: Dave Chinner Cc: Luis Henriques, Greg KH, Brian Foster, Kees Cook, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Ben Myers, Gao feng, Dave Chinner On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote: > On Tue, Dec 10, 2013 at 08:20:07AM -0500, Josh Boyer wrote: >> On Mon, Dec 9, 2013 at 6:55 PM, Dave Chinner <david@fromorbit.com> >> wrote: >> > [cc xfs list, cc stable@vger.kernel.org] >> > >> > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: >> >> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques >> >> <luis.henriques@canonical.com> wrote: >> >> > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: >> >> >> Hi, >> >> >> >> >> >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c >> >> >> ("xfs: add capability check to free eofblocks ioctl") is a >> >> >> security fix that was never sent to -stable? From what I can >> >> >> see, it was introduced in 3.8 by >> >> >> 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add >> >> >> XFS_IOC_FREE_EOFBLOCKS ioctl"). >> >> >> >> >> >> I don't see this in the 3.8.y tree. Should it be added there >> >> >> and newer? >> >> > >> >> > Thanks Kees, I'm queuing it for the 3.11 kernel. >> >> >> >> There's also this one: >> >> >> >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 >> >> >> >> It fixes CVE-2013-6382 >> > >> > First I've heard about it there being a CVE for that bug. Since >> > when has it been considered best practice to publish CVEs >> > without first (or ever) directly contacting the relevant >> > upstream developers? >> >> We got a Fedora bug for it, and there are similar RHEL bugs open. >> I had assumed you would be informed either via upstream or >> through those. > > I've not been cc'd on any of those bugs internally at RH, so I don't > have visibility of the problems unless someone specifically adds me > to those bugs. As it is, raising fedora/RHEL bugs is not informing > upstream - it is a distro process for tracking the distro issue > through to closure. Agreed. We should probably fix the bug thing anyway though. >> The CVE request was submitted by Kees here: >> http://seclists.org/oss-sec/2013/q4/330 > > Ugh, no, I'm not going to subscribe to a high noise list where the > only way I might be informed of a CVE being raised is by following > links to git commit IDs.... > > Upstream is not magically informed about CVEs, and relying on > upstream developers to scan or poll *anything* just to find if a > CVE on their subsystem has been released is not reliable and > does not scale. If anyone raises a CVE against a kernel subsystem, > then the relevant list in the MAINTAINERS file for that subsystem > should be on the cc list of any discussion about the CVE, and on the > announcement of the CVE. > > Security processes are not something that should be hidden away in > it's own private corner - if there's a problem upstream needs to > take action on, then direct contact with upstream is necessary. We > need to know about security issues - even ones that are classified > post-commit as security issues - so we are operating with full > knowledge of the issues in our code and the impact of our fixes.... Agreed. I'm going to interpret your comments at being directed to the general audience because otherwise you're just shooting the messenger :). josh _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-11 1:10 ` Josh Boyer 0 siblings, 0 replies; 37+ messages in thread From: Josh Boyer @ 2013-12-11 1:10 UTC (permalink / raw) To: Dave Chinner Cc: Luis Henriques, Kees Cook, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH, xfs, stable@vger.kernel.org On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote: > On Tue, Dec 10, 2013 at 08:20:07AM -0500, Josh Boyer wrote: >> On Mon, Dec 9, 2013 at 6:55 PM, Dave Chinner <david@fromorbit.com> >> wrote: >> > [cc xfs list, cc stable@vger.kernel.org] >> > >> > On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote: >> >> On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques >> >> <luis.henriques@canonical.com> wrote: >> >> > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: >> >> >> Hi, >> >> >> >> >> >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c >> >> >> ("xfs: add capability check to free eofblocks ioctl") is a >> >> >> security fix that was never sent to -stable? From what I can >> >> >> see, it was introduced in 3.8 by >> >> >> 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add >> >> >> XFS_IOC_FREE_EOFBLOCKS ioctl"). >> >> >> >> >> >> I don't see this in the 3.8.y tree. Should it be added there >> >> >> and newer? >> >> > >> >> > Thanks Kees, I'm queuing it for the 3.11 kernel. >> >> >> >> There's also this one: >> >> >> >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654 >> >> >> >> It fixes CVE-2013-6382 >> > >> > First I've heard about it there being a CVE for that bug. Since >> > when has it been considered best practice to publish CVEs >> > without first (or ever) directly contacting the relevant >> > upstream developers? >> >> We got a Fedora bug for it, and there are similar RHEL bugs open. >> I had assumed you would be informed either via upstream or >> through those. > > I've not been cc'd on any of those bugs internally at RH, so I don't > have visibility of the problems unless someone specifically adds me > to those bugs. As it is, raising fedora/RHEL bugs is not informing > upstream - it is a distro process for tracking the distro issue > through to closure. Agreed. We should probably fix the bug thing anyway though. >> The CVE request was submitted by Kees here: >> http://seclists.org/oss-sec/2013/q4/330 > > Ugh, no, I'm not going to subscribe to a high noise list where the > only way I might be informed of a CVE being raised is by following > links to git commit IDs.... > > Upstream is not magically informed about CVEs, and relying on > upstream developers to scan or poll *anything* just to find if a > CVE on their subsystem has been released is not reliable and > does not scale. If anyone raises a CVE against a kernel subsystem, > then the relevant list in the MAINTAINERS file for that subsystem > should be on the cc list of any discussion about the CVE, and on the > announcement of the CVE. > > Security processes are not something that should be hidden away in > it's own private corner - if there's a problem upstream needs to > take action on, then direct contact with upstream is necessary. We > need to know about security issues - even ones that are classified > post-commit as security issues - so we are operating with full > knowledge of the issues in our code and the impact of our fixes.... Agreed. I'm going to interpret your comments at being directed to the general audience because otherwise you're just shooting the messenger :). josh ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-11 1:10 ` Josh Boyer @ 2013-12-11 2:00 ` Dave Chinner -1 siblings, 0 replies; 37+ messages in thread From: Dave Chinner @ 2013-12-11 2:00 UTC (permalink / raw) To: Josh Boyer Cc: Luis Henriques, Greg KH, Brian Foster, Kees Cook, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Ben Myers, Gao feng, Dave Chinner On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote: > On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote: > > Security processes are not something that should be hidden away in > > it's own private corner - if there's a problem upstream needs to > > take action on, then direct contact with upstream is necessary. We > > need to know about security issues - even ones that are classified > > post-commit as security issues - so we are operating with full > > knowledge of the issues in our code and the impact of our fixes.... > > Agreed. I'm going to interpret your comments at being directed to the > general audience because otherwise you're just shooting the messenger > :). Right, they are not aimed at you - they are aimed at those on the security side of the fence. I'm tired of learning about CVEs in XFS code through chinese whispers and/or luck. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-11 2:00 ` Dave Chinner 0 siblings, 0 replies; 37+ messages in thread From: Dave Chinner @ 2013-12-11 2:00 UTC (permalink / raw) To: Josh Boyer Cc: Luis Henriques, Kees Cook, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH, xfs, stable@vger.kernel.org On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote: > On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote: > > Security processes are not something that should be hidden away in > > it's own private corner - if there's a problem upstream needs to > > take action on, then direct contact with upstream is necessary. We > > need to know about security issues - even ones that are classified > > post-commit as security issues - so we are operating with full > > knowledge of the issues in our code and the impact of our fixes.... > > Agreed. I'm going to interpret your comments at being directed to the > general audience because otherwise you're just shooting the messenger > :). Right, they are not aimed at you - they are aimed at those on the security side of the fence. I'm tired of learning about CVEs in XFS code through chinese whispers and/or luck. Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-11 2:00 ` Dave Chinner @ 2013-12-11 2:12 ` Greg KH -1 siblings, 0 replies; 37+ messages in thread From: Greg KH @ 2013-12-11 2:12 UTC (permalink / raw) To: Dave Chinner Cc: Josh Boyer, Luis Henriques, Brian Foster, Dave Chinner, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Ben Myers, Gao feng, Kees Cook On Wed, Dec 11, 2013 at 01:00:07PM +1100, Dave Chinner wrote: > On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote: > > On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote: > > > Security processes are not something that should be hidden away in > > > it's own private corner - if there's a problem upstream needs to > > > take action on, then direct contact with upstream is necessary. We > > > need to know about security issues - even ones that are classified > > > post-commit as security issues - so we are operating with full > > > knowledge of the issues in our code and the impact of our fixes.... > > > > Agreed. I'm going to interpret your comments at being directed to the > > general audience because otherwise you're just shooting the messenger > > :). > > Right, they are not aimed at you - they are aimed at those on the > security side of the fence. I'm tired of learning about CVEs in XFS > code through chinese whispers and/or luck. CVEs for the kernel are almost always "assigned" after the problem is fixed, or when people "notice" something was changed upstream. At that point, there's no need for the original committer to be notified, as there's nothing to do. Anyway, I understand your frustration about CVEs, I don't like them much either, but some people do, so let them deal with them, and don't give them a second thought. greg k-h _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-11 2:12 ` Greg KH 0 siblings, 0 replies; 37+ messages in thread From: Greg KH @ 2013-12-11 2:12 UTC (permalink / raw) To: Dave Chinner Cc: Josh Boyer, Luis Henriques, Kees Cook, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, xfs, stable@vger.kernel.org On Wed, Dec 11, 2013 at 01:00:07PM +1100, Dave Chinner wrote: > On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote: > > On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote: > > > Security processes are not something that should be hidden away in > > > it's own private corner - if there's a problem upstream needs to > > > take action on, then direct contact with upstream is necessary. We > > > need to know about security issues - even ones that are classified > > > post-commit as security issues - so we are operating with full > > > knowledge of the issues in our code and the impact of our fixes.... > > > > Agreed. I'm going to interpret your comments at being directed to the > > general audience because otherwise you're just shooting the messenger > > :). > > Right, they are not aimed at you - they are aimed at those on the > security side of the fence. I'm tired of learning about CVEs in XFS > code through chinese whispers and/or luck. CVEs for the kernel are almost always "assigned" after the problem is fixed, or when people "notice" something was changed upstream. At that point, there's no need for the original committer to be notified, as there's nothing to do. Anyway, I understand your frustration about CVEs, I don't like them much either, but some people do, so let them deal with them, and don't give them a second thought. greg k-h ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-11 2:00 ` Dave Chinner @ 2013-12-11 2:45 ` Kees Cook -1 siblings, 0 replies; 37+ messages in thread From: Kees Cook @ 2013-12-11 2:45 UTC (permalink / raw) To: Dave Chinner Cc: Josh Boyer, Luis Henriques, Greg KH, Brian Foster, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Ben Myers, Gao feng, Dave Chinner, Dan Carpenter On Tue, Dec 10, 2013 at 6:00 PM, Dave Chinner <david@fromorbit.com> wrote: > On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote: >> On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote: >> > Security processes are not something that should be hidden away in >> > it's own private corner - if there's a problem upstream needs to >> > take action on, then direct contact with upstream is necessary. We >> > need to know about security issues - even ones that are classified >> > post-commit as security issues - so we are operating with full >> > knowledge of the issues in our code and the impact of our fixes.... >> >> Agreed. I'm going to interpret your comments at being directed to the >> general audience because otherwise you're just shooting the messenger >> :). > > Right, they are not aimed at you - they are aimed at those on the > security side of the fence. I'm tired of learning about CVEs in XFS > code through chinese whispers and/or luck. Mostly I try to shield anyone not interested in CVEs from the boring process, and try to focus on just getting things marked as needing to go into stable. I don't think anyone needs to read the oss-security list if they don't want to. In this case, the fix Dan sent was part of a larger collection of security issues reported by Nico. I think the communication error here was Dan accidentally forgetting to add the Cc: stable tag. But beyond that, it was sent to the xfs list and Cc: to security, so I'm not sure it's fair to say it was hidden away. :) Besides the missing Cc: stable tag, what should future patch senders do to call attention to an issue being a security problem at the time it is being reported? -Kees -- Kees Cook Chrome OS Security _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-11 2:45 ` Kees Cook 0 siblings, 0 replies; 37+ messages in thread From: Kees Cook @ 2013-12-11 2:45 UTC (permalink / raw) To: Dave Chinner Cc: Josh Boyer, Luis Henriques, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH, xfs, stable@vger.kernel.org, Dan Carpenter On Tue, Dec 10, 2013 at 6:00 PM, Dave Chinner <david@fromorbit.com> wrote: > On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote: >> On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote: >> > Security processes are not something that should be hidden away in >> > it's own private corner - if there's a problem upstream needs to >> > take action on, then direct contact with upstream is necessary. We >> > need to know about security issues - even ones that are classified >> > post-commit as security issues - so we are operating with full >> > knowledge of the issues in our code and the impact of our fixes.... >> >> Agreed. I'm going to interpret your comments at being directed to the >> general audience because otherwise you're just shooting the messenger >> :). > > Right, they are not aimed at you - they are aimed at those on the > security side of the fence. I'm tired of learning about CVEs in XFS > code through chinese whispers and/or luck. Mostly I try to shield anyone not interested in CVEs from the boring process, and try to focus on just getting things marked as needing to go into stable. I don't think anyone needs to read the oss-security list if they don't want to. In this case, the fix Dan sent was part of a larger collection of security issues reported by Nico. I think the communication error here was Dan accidentally forgetting to add the Cc: stable tag. But beyond that, it was sent to the xfs list and Cc: to security, so I'm not sure it's fair to say it was hidden away. :) Besides the missing Cc: stable tag, what should future patch senders do to call attention to an issue being a security problem at the time it is being reported? -Kees -- Kees Cook Chrome OS Security ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-11 2:45 ` Kees Cook @ 2013-12-11 4:17 ` Dave Chinner -1 siblings, 0 replies; 37+ messages in thread From: Dave Chinner @ 2013-12-11 4:17 UTC (permalink / raw) To: Kees Cook Cc: Josh Boyer, Luis Henriques, Greg KH, Brian Foster, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Ben Myers, Gao feng, Dave Chinner, Dan Carpenter On Tue, Dec 10, 2013 at 06:45:54PM -0800, Kees Cook wrote: > On Tue, Dec 10, 2013 at 6:00 PM, Dave Chinner <david@fromorbit.com> wrote: > > On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote: > >> On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote: > >> > Security processes are not something that should be hidden away in > >> > it's own private corner - if there's a problem upstream needs to > >> > take action on, then direct contact with upstream is necessary. We > >> > need to know about security issues - even ones that are classified > >> > post-commit as security issues - so we are operating with full > >> > knowledge of the issues in our code and the impact of our fixes.... > >> > >> Agreed. I'm going to interpret your comments at being directed to the > >> general audience because otherwise you're just shooting the messenger > >> :). > > > > Right, they are not aimed at you - they are aimed at those on the > > security side of the fence. I'm tired of learning about CVEs in XFS > > code through chinese whispers and/or luck. > > Mostly I try to shield anyone not interested in CVEs from the boring > process, and try to focus on just getting things marked as needing to > go into stable. I don't think anyone needs to read the oss-security > list if they don't want to. Which is how is should be. ;) All I want is some kind of notification when a CVE raised for an XFS issue. It may be telling us something we already known, but if: a) it has not yet been pushed upstream; or b) it was not marked for stable kernels at commit time; or c) don't have a fix for it yet then it's an indication that we need to pay a little more attention to this class of problem when we review similar fixes. > In this case, the fix Dan sent was part of a larger collection of > security issues reported by Nico. I think the communication error here > was Dan accidentally forgetting to add the Cc: stable tag. But beyond > that, it was sent to the xfs list and Cc: to security, so I'm not sure > it's fair to say it was hidden away. :) Right - this falls into the above category a) because of that. There didn't appear to be any urgency because of the level of exposure of the problem (i.e. need CAP_SYS_ADMIN to trip over it) and the fact it's been like this for the past 10 years.... > Besides the missing Cc: stable tag, what should future patch senders > do to call attention to an issue being a security problem at the time > it is being reported? Well, it may not be known at the time it's considered a security issue, so I think that the best thing to do is make sure that when a CVE is actually raise a note is sent to the relevant list just to indicate 'CVE 1024-3267 has been raised for commit abcd1234 ("xfs: knabgraddle the frobnozzle")'. At least that way everyone - including XFS users - that there is an issue that they might want to look out for and plan to upgrade their stable kernels in the not-to-distant future... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-11 4:17 ` Dave Chinner 0 siblings, 0 replies; 37+ messages in thread From: Dave Chinner @ 2013-12-11 4:17 UTC (permalink / raw) To: Kees Cook Cc: Josh Boyer, Luis Henriques, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH, xfs, stable@vger.kernel.org, Dan Carpenter On Tue, Dec 10, 2013 at 06:45:54PM -0800, Kees Cook wrote: > On Tue, Dec 10, 2013 at 6:00 PM, Dave Chinner <david@fromorbit.com> wrote: > > On Tue, Dec 10, 2013 at 08:10:51PM -0500, Josh Boyer wrote: > >> On Tue, Dec 10, 2013 at 8:03 PM, Dave Chinner <david@fromorbit.com> wrote: > >> > Security processes are not something that should be hidden away in > >> > it's own private corner - if there's a problem upstream needs to > >> > take action on, then direct contact with upstream is necessary. We > >> > need to know about security issues - even ones that are classified > >> > post-commit as security issues - so we are operating with full > >> > knowledge of the issues in our code and the impact of our fixes.... > >> > >> Agreed. I'm going to interpret your comments at being directed to the > >> general audience because otherwise you're just shooting the messenger > >> :). > > > > Right, they are not aimed at you - they are aimed at those on the > > security side of the fence. I'm tired of learning about CVEs in XFS > > code through chinese whispers and/or luck. > > Mostly I try to shield anyone not interested in CVEs from the boring > process, and try to focus on just getting things marked as needing to > go into stable. I don't think anyone needs to read the oss-security > list if they don't want to. Which is how is should be. ;) All I want is some kind of notification when a CVE raised for an XFS issue. It may be telling us something we already known, but if: a) it has not yet been pushed upstream; or b) it was not marked for stable kernels at commit time; or c) don't have a fix for it yet then it's an indication that we need to pay a little more attention to this class of problem when we review similar fixes. > In this case, the fix Dan sent was part of a larger collection of > security issues reported by Nico. I think the communication error here > was Dan accidentally forgetting to add the Cc: stable tag. But beyond > that, it was sent to the xfs list and Cc: to security, so I'm not sure > it's fair to say it was hidden away. :) Right - this falls into the above category a) because of that. There didn't appear to be any urgency because of the level of exposure of the problem (i.e. need CAP_SYS_ADMIN to trip over it) and the fact it's been like this for the past 10 years.... > Besides the missing Cc: stable tag, what should future patch senders > do to call attention to an issue being a security problem at the time > it is being reported? Well, it may not be known at the time it's considered a security issue, so I think that the best thing to do is make sure that when a CVE is actually raise a note is sent to the relevant list just to indicate 'CVE 1024-3267 has been raised for commit abcd1234 ("xfs: knabgraddle the frobnozzle")'. At least that way everyone - including XFS users - that there is an issue that they might want to look out for and plan to upgrade their stable kernels in the not-to-distant future... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-11 4:17 ` Dave Chinner @ 2013-12-11 8:27 ` Dan Carpenter -1 siblings, 0 replies; 37+ messages in thread From: Dan Carpenter @ 2013-12-11 8:27 UTC (permalink / raw) To: Dave Chinner Cc: Josh Boyer, Luis Henriques, Greg KH, Brian Foster, Dave Chinner, Dwight Engen, LKML, stable@vger.kernel.org, xfs, Ben Myers, Gao feng, Kees Cook I wasn't really expecting it to get a CVE since it requires CAP_SYS_ADMIN but I should have added the CC to stable. Sorry about that. regards, dan carpenter _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-11 8:27 ` Dan Carpenter 0 siblings, 0 replies; 37+ messages in thread From: Dan Carpenter @ 2013-12-11 8:27 UTC (permalink / raw) To: Dave Chinner Cc: Kees Cook, Josh Boyer, Luis Henriques, Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH, xfs, stable@vger.kernel.org I wasn't really expecting it to get a CVE since it requires CAP_SYS_ADMIN but I should have added the CC to stable. Sorry about that. regards, dan carpenter ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-06 0:35 XFS security fix never sent to -stable? Kees Cook @ 2013-12-09 23:30 ` Dave Chinner 2013-12-09 12:15 ` Luis Henriques 2013-12-09 23:30 ` Dave Chinner 2 siblings, 0 replies; 37+ messages in thread From: Dave Chinner @ 2013-12-09 23:30 UTC (permalink / raw) To: Kees Cook Cc: Greg KH, Brian Foster, Dwight Engen, LKML, xfs, Ben Myers, Gao feng, Dave Chinner [CC the xfs list. Kees - I shouldn't have to remind you to do this. ] On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > Hi, > > It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add > capability check to free eofblocks ioctl") is a security fix that was > never sent to -stable? From what I can see, it was introduced in 3.8 > by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > XFS_IOC_FREE_EOFBLOCKS ioctl"). > > I don't see this in the 3.8.y tree. Should it be added there and newer? Well, it's not really a security problem at all, given that it only affects speculative preallocation beyond EOF. i.e. it affects filesystem metadata that does not yet index any user data. Indeed, the kernel already does exactly what this ioctl does every 5 minutes without user intervention. i.e. it's simply a maintenance task we need to execute periodically or on demand as a result of other events (e.g. from a userspace daemon that is listen to quota exhaustion messages). So apart from allowing a user to burn some CPU with the ioctl doing nothing but scanning, there's little in way of a security problem being exposed on kernels prior to 3.12 here. The reason for the cap check? Turning off this ioctl in containers restricted by user name spaces. i.e. new functionality added to XFS in 3.12 introduced curiously vague and difficult to explain new inode access restrictions, so we took the "be safe by default" route and only allowed the init namespace access to the ioctl.... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-09 23:30 ` Dave Chinner 0 siblings, 0 replies; 37+ messages in thread From: Dave Chinner @ 2013-12-09 23:30 UTC (permalink / raw) To: Kees Cook Cc: Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH, xfs [CC the xfs list. Kees - I shouldn't have to remind you to do this. ] On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: > Hi, > > It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add > capability check to free eofblocks ioctl") is a security fix that was > never sent to -stable? From what I can see, it was introduced in 3.8 > by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add > XFS_IOC_FREE_EOFBLOCKS ioctl"). > > I don't see this in the 3.8.y tree. Should it be added there and newer? Well, it's not really a security problem at all, given that it only affects speculative preallocation beyond EOF. i.e. it affects filesystem metadata that does not yet index any user data. Indeed, the kernel already does exactly what this ioctl does every 5 minutes without user intervention. i.e. it's simply a maintenance task we need to execute periodically or on demand as a result of other events (e.g. from a userspace daemon that is listen to quota exhaustion messages). So apart from allowing a user to burn some CPU with the ioctl doing nothing but scanning, there's little in way of a security problem being exposed on kernels prior to 3.12 here. The reason for the cap check? Turning off this ioctl in containers restricted by user name spaces. i.e. new functionality added to XFS in 3.12 introduced curiously vague and difficult to explain new inode access restrictions, so we took the "be safe by default" route and only allowed the init namespace access to the ioctl.... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? 2013-12-09 23:30 ` Dave Chinner @ 2013-12-11 2:36 ` Kees Cook -1 siblings, 0 replies; 37+ messages in thread From: Kees Cook @ 2013-12-11 2:36 UTC (permalink / raw) To: Dave Chinner Cc: Greg KH, Brian Foster, Dwight Engen, LKML, xfs, Ben Myers, Gao feng, Dave Chinner On Mon, Dec 9, 2013 at 3:30 PM, Dave Chinner <david@fromorbit.com> wrote: > [CC the xfs list. Kees - I shouldn't have to remind you to do this. ] > > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: >> Hi, >> >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add >> capability check to free eofblocks ioctl") is a security fix that was >> never sent to -stable? From what I can see, it was introduced in 3.8 >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add >> XFS_IOC_FREE_EOFBLOCKS ioctl"). >> >> I don't see this in the 3.8.y tree. Should it be added there and newer? > > Well, it's not really a security problem at all, given that it only > affects speculative preallocation beyond EOF. i.e. it affects > filesystem metadata that does not yet index any user data. > > Indeed, the kernel already does exactly what this ioctl does every 5 > minutes without user intervention. i.e. it's simply a maintenance > task we need to execute periodically or on demand as a result of > other events (e.g. from a userspace daemon that is listen to quota > exhaustion messages). > > So apart from allowing a user to burn some CPU with the ioctl doing > nothing but scanning, there's little in way of a security problem > being exposed on kernels prior to 3.12 here. > > The reason for the cap check? Turning off this ioctl in containers > restricted by user name spaces. i.e. new functionality added to XFS > in 3.12 introduced curiously vague and difficult to explain new > inode access restrictions, so we took the "be safe by default" route > and only allowed the init namespace access to the ioctl.... Right, it wasn't clear from the commit, and it looked troublesome, but it's function wasn't obvious, so that's why I asked. -Kees -- Kees Cook Chrome OS Security _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: XFS security fix never sent to -stable? @ 2013-12-11 2:36 ` Kees Cook 0 siblings, 0 replies; 37+ messages in thread From: Kees Cook @ 2013-12-11 2:36 UTC (permalink / raw) To: Dave Chinner Cc: Dwight Engen, LKML, Brian Foster, Dave Chinner, Gao feng, Ben Myers, Greg KH, xfs On Mon, Dec 9, 2013 at 3:30 PM, Dave Chinner <david@fromorbit.com> wrote: > [CC the xfs list. Kees - I shouldn't have to remind you to do this. ] > > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote: >> Hi, >> >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add >> capability check to free eofblocks ioctl") is a security fix that was >> never sent to -stable? From what I can see, it was introduced in 3.8 >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add >> XFS_IOC_FREE_EOFBLOCKS ioctl"). >> >> I don't see this in the 3.8.y tree. Should it be added there and newer? > > Well, it's not really a security problem at all, given that it only > affects speculative preallocation beyond EOF. i.e. it affects > filesystem metadata that does not yet index any user data. > > Indeed, the kernel already does exactly what this ioctl does every 5 > minutes without user intervention. i.e. it's simply a maintenance > task we need to execute periodically or on demand as a result of > other events (e.g. from a userspace daemon that is listen to quota > exhaustion messages). > > So apart from allowing a user to burn some CPU with the ioctl doing > nothing but scanning, there's little in way of a security problem > being exposed on kernels prior to 3.12 here. > > The reason for the cap check? Turning off this ioctl in containers > restricted by user name spaces. i.e. new functionality added to XFS > in 3.12 introduced curiously vague and difficult to explain new > inode access restrictions, so we took the "be safe by default" route > and only allowed the init namespace access to the ioctl.... Right, it wasn't clear from the commit, and it looked troublesome, but it's function wasn't obvious, so that's why I asked. -Kees -- Kees Cook Chrome OS Security ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2013-12-17 13:59 UTC | newest] Thread overview: 37+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-12-06 0:35 XFS security fix never sent to -stable? Kees Cook 2013-12-06 14:43 ` Dwight Engen 2013-12-06 15:06 ` Brian Foster 2013-12-09 12:15 ` Luis Henriques 2013-12-09 13:17 ` Josh Boyer 2013-12-09 23:55 ` Dave Chinner 2013-12-09 23:55 ` Dave Chinner 2013-12-10 7:56 ` Greg KH 2013-12-10 7:56 ` Greg KH 2013-12-10 13:15 ` Josh Boyer 2013-12-10 13:15 ` Josh Boyer 2013-12-10 14:31 ` Eric Sandeen 2013-12-10 14:31 ` Eric Sandeen 2013-12-10 15:57 ` Ben Myers 2013-12-10 15:57 ` Ben Myers 2013-12-17 13:58 ` Luis Henriques 2013-12-17 13:58 ` Luis Henriques 2013-12-10 13:20 ` Josh Boyer 2013-12-10 13:20 ` Josh Boyer 2013-12-11 1:03 ` Dave Chinner 2013-12-11 1:03 ` Dave Chinner 2013-12-11 1:10 ` Josh Boyer 2013-12-11 1:10 ` Josh Boyer 2013-12-11 2:00 ` Dave Chinner 2013-12-11 2:00 ` Dave Chinner 2013-12-11 2:12 ` Greg KH 2013-12-11 2:12 ` Greg KH 2013-12-11 2:45 ` Kees Cook 2013-12-11 2:45 ` Kees Cook 2013-12-11 4:17 ` Dave Chinner 2013-12-11 4:17 ` Dave Chinner 2013-12-11 8:27 ` Dan Carpenter 2013-12-11 8:27 ` Dan Carpenter 2013-12-09 23:30 ` Dave Chinner 2013-12-09 23:30 ` Dave Chinner 2013-12-11 2:36 ` Kees Cook 2013-12-11 2:36 ` Kees Cook
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.