lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 11 Nov 2015 02:56:47 +0000 From: Al Viro <viro@...IV.linux.org.uk> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Sasha Levin <sasha.levin@...cle.com>, Andrey Ryabinin <ryabinin.a.a@...il.com>, Matthew Wilcox <willy@...ux.intel.com>, Chuck Ebbert <cebbert.lkml@...il.com>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Jens Axboe <axboe@...nel.dk>, Dan Williams <dan.j.williams@...el.com> Subject: Re: fs: out of bounds on stack in iov_iter_advance On Tue, Nov 10, 2015 at 06:21:47PM -0800, Linus Torvalds wrote: > Al, looking at the most recent linux-next, most of the vfs commits > there seem to be committed in the last day or two. I'm getting the > feeling that that is all 4.5 material by now. > > Should I just take the iov patch as-is, since apparently no vfs pull > request is happening this merge cycle? And no, I'm not taking > "developed during the second week of the merge window, and sent in the > last few days of it". I'm done with that. s/developed/rebased/, actually, but... point taken. Mea culpa, and what to do with those patches is for you to decide; some of those are simply -stable fodder and probably ought to go one-by-one at any point you would consider convenient, some are of the "remove stale comment" variety (obviously can sit around until the next cycle, or go in one-by-one at any point - the things like - - /* WARNING: probably going away soon, do not use! */ in inode_operations; the comment used to be about the method removed last cycle and should've been gone with it; etc.) There's a large pile not in those two classes - xattr+richacl stuff. I'm more confident about the first part, but strictly speaking neither qualifies as fixes. FWIW, the stuff that had been _developed_ during the merge window is not there - a patch series around the descriptor bitmaps. Doesn't change the situation; I'd fucked up this cycle ;-/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists