<p dir="ltr">On 8 Nov 2014 07:01, "Rob Landley" <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br>
><br>
> getline() returns an arbitrarily long line. In theory _megabytes_ long, which<br>
> it mallocs. Could this be a denial of service attack? If you do<br>
> "grep blah /dev/zero" and it produces endless amounts of input that never<br>
> has a newline in it, it just keeps mallocing until it runs out of memory,<br>
> thrashing memory as it copies existing data to a longer and longer buffer,<br>
> evicting everything else (even if you don't have swap it'll thrash for a while<br>
> evicting and then faulting back in executable pages from shared libraries<br>
> and ELF executables)...<br>
><br>
> The thing is, I dunno what to _do_ about that. Arbitrary line length limits<br>
> could screw up real world uses. (I think practically we've got about 2<br>
> gigabyte line limits because I tend to use ints to index stuff.) It's<br>
> possible that various libc implementations will have their own internal<br>
> limits...<br>
><br>
> (Requiring input to be mmap()able isn't necessarily an improvement because<br>
> then you can't operate on a pipe and "diff -u <(sort file1) <(sort file2)" is<br>
> something I do reasonably often, _and_ because on 32 bit systems it limits<br>
> the size of files it can deal with to the userspace virtual address range<br>
> which is maybe 2 gigabytes.)<br>
><br>
> Yeah, this is why the kernel has an out of memory killer, but if anybody<br>
> has ideas for _not_ hitting that which don't impact potential legitimate<br>
> uses, I'm open to suggestions...<br>
><br>
> Rob</p>
<p dir="ltr">I don't know if this is an issue. If a user can run "grep blah /dev/zero" then they have shell access anyway, what's to stop them compiling a C program that allocates memory in a loop?<br></p>
<p dir="ltr">Rob </p>