Bug 215504 - limits -s 0 limits causes limits process to segfault
Summary: limits -s 0 limits causes limits process to segfault
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: needs-patch
Depends on:
Blocks:
 
Reported: 2016-12-23 05:29 UTC by Enji Cooper
Modified: 2022-07-26 14:43 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Enji Cooper freebsd_committer freebsd_triage 2016-12-23 05:29:30 UTC
# limits -s 0 limits
Segmentation fault (core dumped)
# whoami
root
# gdb limits limits.core
GNU gdb (GDB) 7.11.1 [GDB v7.11.1 for FreeBSD]
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from limits...Reading symbols from /usr/src/svn/usr.bin/limits/limits.debug...done.
done.
[New LWP 100106]
Core was generated by `limits -s 0 limits'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000800ab40a0 in setrlimit () from /lib/libc.so.7
(gdb) bt
#0  0x0000000800ab40a0 in setrlimit () from /lib/libc.so.7
Backtrace stopped: Cannot access memory at address 0x7fffffffe8e8
Comment 1 Mark Johnston freebsd_committer freebsd_triage 2016-12-24 23:16:53 UTC
Presumably this is because you asked limits to execute with a stack size of 0? Looking at kern_proc_setrlimit(), a request to decrease the current stack limit will cause the kernel to render inaccessible any pages beyond the new limit, so with a new size of 0 we'll crash upon returning from setrlimit(). (It also looks as though kern_proc_setrlimit() assumes that stacks grow down.)