Hi, On Fri, Aug 23, 2019 at 09:26:12PM +0200, Salvatore Bonaccorso wrote: > Hi Linus, > > On Fri, Aug 23, 2019 at 09:28:42AM -0700, Linus Torvalds wrote: > > On Thu, Aug 22, 2019 at 8:55 PM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > > > > > > ...which is clearly caused by xfs_setattr_nonsize failing to unlock the > > > ILOCK after the xfs_qm_vop_chown_reserve call fails. Add the missing > > > unlock. > > > > Thanks for the quick fix. > > > > I assume there's no real embargo on this, and we can just add it asap > > to the xfs tree and mark it for stable, rather than do anything > > outside the usual development path? > > > > The security list rules do allow for a 5-working-day delay, but this > > being "just" a local DoS thing I expect nobody really will argue for > > it. > > > > Anybody? > > Agreed, there is no real embargo on this, it is public anyway on the > xfs list and actually we just wanted to be on the safe side by asking > or bringing it to security@k.o. > > Thanks for the quick fix. Not changing my mind on the above, given the fixing commit is public. But thinking a bit more on it, I guess this should not considered local DoS only. If the filesystem is exosed then a remote user might trigger it serverside. The issue could be reproduced on a NFS exported XFS as well. Just export the filesystem rw to another host via NFS and mount it there. A local user on the client could then trigger the issue on the server as well. Regards, Salvatore
