From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tvrtko Ursulin Subject: Re: Potentially unbounded allocations in seq_read? Date: Wed, 11 Dec 2013 17:59:57 +0000 Message-ID: <1386784797.6066.63.camel@tursulin-linux.isw.intel.com> References: <1386781481.6066.55.camel@tursulin-linux.isw.intel.com> <20131211174909.GW10323@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: Andrew Morton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Al Viro Return-path: In-Reply-To: <20131211174909.GW10323@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2013-12-11 at 17:49 +0000, Al Viro wrote: > On Wed, Dec 11, 2013 at 05:04:41PM +0000, Tvrtko Ursulin wrote: > > Hi all, > > > > It seems that the buffer allocation in seq_read can double in size > > indefinitely, at least I've seen that in practice with /proc//smaps > > (attempting to double m->size to 4M on a read of 1000 bytes). This > > produces an ugly WARN_ON_ONCE, which should perhaps be avoided? (given > > that it can be triggered by userspace at will) > > An entry in /proc//smaps that did not fit into 2Mb? Seriously? > How in hell has that happened? If you can trigger that at will, please > post the reproducer. Yeah, no, wrong assumption. It was not about the size but the number of reads. For example: open("/proc/3131/smaps", O_RDONLY|O_LARGEFILE) = 3 fstat64(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0 brk(0xf9019000) = 0xf9019000 read(3, "be483000-be4ab000 rw-s 00000000 "..., 4096) = 4054 write(1, "be483000-be4ab000 rw-s 00000000 "..., 4054) = 4054 read(3, "be5c3000-be5c5000 rw-s 10da3f000"..., 4096) = 3656 write(1, "be5c3000-be5c5000 rw-s 10da3f000"..., 3656) = 3656 read(3, "be6b1000-be6b2000 rw-s 10da48000"..., 4096) = 3661 write(1, "be6b1000-be6b2000 rw-s 10da48000"..., 3661) = 3661 read(3, "be6b9000-be6ba000 rw-s 10da38000"..., 4096) = 3599 write(1, "be6b9000-be6ba000 rw-s 10da38000"..., 3599) = 3599 read(3, "be6d6000-be7b6000 rw-s 10d889000"..., 4096) = 3599 write(1, "be6d6000-be7b6000 rw-s 10d889000"..., 3599) = 3599 read(3, "be884000-be885000 rw-s 10d85c000"..., 4096) = 3661 write(1, "be884000-be885000 rw-s 10d85c000"..., 3661) = 3661 read(3, "be88d000-be8de000 rw-p 00000000 "..., 4096) = 4007 write(1, "be88d000-be8de000 rw-p 00000000 "..., 4007) = 4007 read(3, "bea29000-bea4d000 r-xp 00000000 "..., 4096) = 4057 write(1, "bea29000-bea4d000 r-xp 00000000 "..., 4057) = 4057 read(3, "beab3000-bead0000 r--p 00000000 "..., 4096) = 2092 write(1, "beab3000-bead0000 r--p 00000000 "..., 2092) = 2092 read(3, 0xf9017030, 4096) = -1 ENOMEM (Out of memory) Regards, Tvrtko