Add an API for alerting internal libc routines to the presence of
"unsafe" paths post-chroot, and use it in ftpd. [11:07]
Fix a buffer overflow in telnetd. [11:08]
Make pam_ssh ignore unpassphrased keys unless the "nullok" option is
specified. [11:09]
Add sanity checking of service names in pam_start. [11:10]
Approved by: so (cperciva)
Approved by: re (bz)
Security: FreeBSD-SA-11:06.bind
Security: FreeBSD-SA-11:07.chroot
Security: FreeBSD-SA-11:08.telnetd
Security: FreeBSD-SA-11:09.pam_ssh
Security: FreeBSD-SA-11:10.pam
messy way, so as to not disrupt other yp programs: just add casts to
convert the incompatible enums, as the numerical values are the same
(either by accident, design, or the phase of the moon at that time).
MFC after: 1 week
from the dispatcher would also acquire bind lock in read mode, which
is the supported operation. plt is explicitely designed to allow safe
multithreaded updates, so the shared lock do not cause problems.
The error in r228435 is that it allows read lock acquisition after the
write lock for the bind block. If we dlopened the shared object that
contains IRELATIVE or jump slot which target is STT_GNU_IFUNC, then
possible recursive plt resolve from the dispatcher would cause it.
Postpone the resolution for irelative/ifunc right before initializers
are called, and drop bind lock around calls to dispatcher. Use
initlist to iterate over the objects instead of the ->next, due to
drop of the bind lock in iteration.
For i386/reloc.c:reloc_iresolve(), fix calculation of the dispatch
function address for dso, by taking into account possible non-zero
relocbase.
MFC after: 3 weeks
rtld on 386 and amd64. This adds runtime bits neccessary for the use
of the dispatch functions from the dynamically-linked executables and
shared libraries.
To allow use of external references from the dispatch function, resolution
of the R_MACHINE_IRESOLVE relocations in PLT is postponed until GOT entries
for PLT are prepared, and normal resolution of the GOT entries is finished.
Similar to how it is done by GNU, IRELATIVE relocations are resolved in
advance, instead of normal lazy handling for PLT.
Move the init_pltgot() call before the relocations for the object are
processed.
MFC after: 3 weeks
relocations are processed, since tls initialization section might be
itself subject for relocations. Only set up of the block is postponed,
the tls block offsets are allocated before relocation processing, since
TLS-related relocations may need offsets ready.
Reported by: ale
PR: threads/161344
Reviewed by: kan
MFC after: 1 week
executable) after r190885. The whole region for the dso is mmaped with
MAP_NOCORE flag, doing only mprotect(2) over .bss prevented it from
writing .bss to core files.
Revert the optimization of using mprotect(2) to establish .bss, overlap
the section with mmap(2).
Reported by: attilio
Reviewed by: attilio, emaste
Approved by: re (bz)
MFC after: 2 weeks
functions. The _rtld_error() function might be called early during the rtld
bootstrap, in which case function pointers are not yet functional on ia64
due to required relocations not yet performed.
Reported, reviewed and tested by: marcel
Approved by: re (bz)
function (a hook necessary for gdb support), is inlined, but since the
function contains no code, no calls to it are generated. When gdb is
debugging a dynamically linked program, this causes backtraces to be
corrupted.
Fix it by marking the function __noinline, and inserting an empty asm
statement, that pretends to clobber memory. This forces the compiler to
emit calls to r_debug_state() throughout rtld.c.
Approved by: re (kib)
C runtime services, like printf(). Unfortunately, the multithread-safeness
measures in the libc do not work in rtld environment.
Rip the kernel printf() implementation and use it in the rtld instead of
libc version. This printf does not require any shared global data and thus
is mt-safe. Systematically use rtld_printf() and related functions, remove
the calls to err(3).
Note that stdio is still pulled from libc due to libmap implementaion using
fopen(). This is safe but unoptimal, and can be changed later.
Reported and tested by: pgj
Diagnosed and reviewed by: kan (previous version)
Approved by: re (bz)
from NetBSD, with some slight changes:
=========================================================================================
http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/tftpd/tftpd.8?only_with_tag=MAIN#rev1.22
Revision 1.22 or diffs], Fri Jan 8 21:05:14 2010 UTC (18 months, 2 weeks ago) by christos
Patrick Welche <prlw1@cam.ac.uk>
- add -p pathsep option
- make wrap to zero work, but produce a warning
While here:
- fix gcc warnings, in particular variable clobbered warnings
(compiling with fewer warnings does not really fix the problem)
=========================================================================================
These wording changes clarify the default rollover behavior
as a "kludge". Also, the block numbers and octet counts for 65535 blocks
and 32767 blocks are more accurate than the existing documented numbers.
Requested by: Pawan Gupta <pawang at juniper dot net>
Obtained from: Juniper Networks
Approved by: re (kib)
the block counter would rollover to 0 if a file larger
than 65535 blocks was transferred. With the default block size
of 512 octets per block, this is a file size of approximately 32 megabytes.
The new TFTP server code would report an error and stop transferring
the file if a file was larger than 65535 blocks.
This patch restores the old TFTP server's behavior to the new
TFTP server code. If a TFTP client transfers a file larger
than 65535 blocks, and does *not* specify the "rollover" option,
then automatically rollover the block counter to 0 every time
we reach 65535 blocks.
This restores interoperability with the FreeBSD 6 TFTP client.
Without this change, if a FreeBSD 6 TFTP client tried to
retrieve a file larger than 65535 blocks from a FreeBSD 9 TFTP server
, the transfer would fail.
The same file could be retrieved successfully if the same FreeBSD 6
TFTP client was used against a FreeBSD 6 TFTP server.
Approved by: re (kib)
Tested by: Pawan Gupta <pawang at juniper dot net>,
Obtained from: Juniper Networks
tftp implementation. The synchnet() function
was converted to a no-op when the new TFTP implementation
was committed to FreeBSD. However, this function, as it was
in the older code, is needed
in order to synchronize between the tftpd server and tftp clients,
which may be buggy.
Specifically, we had a buggy TFTP client which would send
TFTP ACK packets for non-TFTP packets, which would cause
the count of packets to get out of whack, causing transfers
to fail with the new TFTPD implementation.
Obtained from: Juniper Networks
Submitted by: Santhanakrishnan Balraj <sbalraj at juniper dot net>
- Remove unneeded linking against libmd. libulog depends on this
library, but the ulog-helper tool itself does not.
- Change the comment at the top to mention utmpx instead of utmp, wtmp
and lastlog.
- Simply use user_from_uid() to translate to a username string.
- Put variable declarations together.
The second close(2) call resulted in heisenbugs in some multi-threaded
applications where e.g. dlopen(3) call in one thread could close a file
descriptor for a file having been opened in other thread concurrently.
My litmus test for this issue was an openoffice.org build.
Reviewed by: jhb
MFC after: 2 weeks
- Emitt an error when encountering an unsupported and in case of the
kernel also for unaligned relocations.
- Fix R_SPARC_LOX10 relocations. Apparently these are hardly ever used.
- Add the _RF_X committed in r212998 also to the tables in the sparc64
reloc.c in order reduce differences between the kernel and the userland
source. This results in no functional change though.
- Fix further inconsistencies in the abbreviations of the names of the
relocations.
- Further whitespace fixes.
Obtained from: NetBSD [1]
values for resolved symbols relative to relocbase instead of sections
so detect this case and handle as appropriate, which allows using
kernel modules linked with affected versions of binutils. Actually I
think this is a bug in binutils but given that apparently nobody
complained for nearly six years and powerpc has basically the same
workaround I decided to put it in for the sparc64 kernel, too.
- Fix R_SPARC_HIX22 relocations. Apparently these are hardly ever used.
Instead of aborting in locate_dependency(), propagate the error to
caller. The rtld startup function does the right thing with an error
from rtld_verify_versions(), depending on the mode of operation.
Reported by: maho
In collaboration with: kan
MFC after: 1 week
Place elements on DAG lists in breadth-first order. This allows us to
walk pre-built list in all cases where breadth-first dependency chain
enumeration is required.
Fix dlsym on special handle obtained by dlopen(NULL, ...) to do what
comment claims it does. Take advantage of recently added symlook_global
function to iterate over main objects and global DAGs lists properly in
search of a symbol. Since rtld itself provides part of the global
namespace, search rtld_obj too.
Remove recursion from init_dag and symlook_needed functions. Use
symlook_needed for ELF filtee processing only and change lookup order
used in the function to match the order used by Solaris runtime linker
under same circumstances. While there, fix weak symbol handling in the
loop so that we return the first weak symbol definition if no strong one
was found, instead of the last one.
Reviewed by: kib
MFC after: 1 month
one. Search global objects, together with main object and
dependencies, for the requested symbol.
Move the common code from symlook_default() into new helper
symlook_global(), and use it both in symlook_global() and
get_program_var_addr().
Supply lock state to get_program_var_addr().
Reviewed by: kan
Tested by: Mykola Dzham <i levsha me>
by kernel, and parse PT_GNU_STACK phdr from linked and loaded dsos.
If the loaded dso requires executable stack, as specified by PF_X bit
of p_flags of PT_GNU_STACK phdr, but current stack protection does not
permit execution, the __pthread_map_stacks_exec symbol is looked up
and called. It should be implemented in libc or threading library and
change the protection mode of all thread stacks to be executable.
Provide a private interface _rtld_get_stack_prot() to export the stack
access mode as calculated by rtld.
Reviewed by: kan
3DNow, MMX and floating point instructions in rtld-elf.
Otherwise, _rtld_bind() (and whatever it calls) could possibly clobber
function arguments that are passed in SSE/3DNow/MMX/FP registers,
usually floating point values. This can happen, for example, when clang
generates SSE code for memset() or memcpy() calls.
One symptom of this is sshd dying early on amd64 with "PRNG not seeded",
which is ultimately caused by libcrypto.so.6 calling RAND_add() with a
double parameter. That parameter is passed via %xmm0, which gets wiped
out by an SSE memset() in _rtld_bind().
Reviewed by: kib, kan
the caller. Currently, checkuser() does not differentiate between the
failure to open the file and the absence of a user in the file. Check
to see if there was an error opening the file. If there are any errors,
terminate the connection. Currently, the only exception to this rule
is ENOENT, since there is nothing that says the /etc/ftpuser
and /etc/ftpchroot has to exist.
MFC after: 3 weeks
C function, the caller's stack frame must have room to store all of the
arguments to that function. While here, fix stack frame alignment issues.
Without this change, the compiler will save r3 and r4 into the caller's
stack frame before calling setjmp() in _rtld_bind(). These would then
overwrite arguments to the newly-bound function, causing eventual failures.
filters are implemented.
Filtees are loaded on demand, unless LD_LOADFLTR environment variable
is set or -z loadfltr was specified during the linking. This forces
rtld to upgrade read-locked rtld_bind_lock to write lock when it
encounters an object with filter during symbol lookup.
Consolidate common arguments of the symbol lookup functions in the
SymLook structure. Track the state of the rtld locks in the
RtldLockState structure. Pass local RtldLockState through the rtld
symbol lookup calls to allow lock upgrades.
Reviewed by: kan
Tested by: Mykola Dzham <i levsha me>, nwhitehorn (powerpc)
dlclose() call may unload the object of the outer call prematurely
because objects are unreferenced before _fini() calls.
Fix this by unreferencing objects after calling objlist_call_fini() in
dlclose(). Therefore objlist_call_fini() now calls the fini function if
the reference count of an object is 1. In addition we must restart the
list_fini traversal after every _fini() call because another dlclose()
call might have modified the reference counts.
Add an XXX comment to objlist_call_fini() about possible race with
dlopen().
PR: 133246, 149464
Reviewed by: kan, kib
loaded as a dependency and marked -z nodlopen, object' DAG is already
initialized by load_needed_objects(). Due to this, the init_dag() call
from dlopen() does not increment refcount for the object [1].
Change init_dag() to not increment DAG refcount. Require explicit calls
to ref_dag() to increment, and assert that ref_dag() and unref_dag()
are called for root that has dag initialized. To fix the noted issue,
unconditionally call both init_dag() and ref_dag() in dlopen() for the
case when the object was already loaded, making it similar to the case
of newly loaded object.
Noted by: jh [1]
Reviewed by: jh, kan
MFC after: 6 days
dependency, then the dso never has its DAG initialized. Empty DAG
makes ref_dag() call in dlopen() a nop, and the dso refcount is off
by one.
Initialize the DAG on the first dlopen() call, using a boolean flag
to prevent double initialization.
From the PR (edited):
Assume we have a library liba.so, containing a function a(), and a
library libb.so, containing function b(). liba.so needs functionality
from libb.so, so liba.so links in libb.so.
An application doesn't know about the relation between these libraries,
but needs to call a() and b(). It dlopen()s liba.so and obtains a
pointer to a(), then it dlopen()s libb.so and obtains a pointer to b().
As soon as the application doesn't need a() anymore, it dlclose()s liba.so.
Expected result: the pointer to b() is still valid and can be called
Actual result: the pointer to b() has become invalid, even though the
application did not dlclose() the handle to libb.so. On calling b(), the
application crashes with a segmentation fault.
PR: misc/151861
Based on patch by: jh
Reviewed by: kan
Tested by: Arjan van Leeuwen <freebsd-maintainer opera com>
MFC after: 1 week
I've noticed various terminal emulators that need to obtain a sane
default termios structure use very complex `hacks'. Even though POSIX
doesn't provide any functionality for this, extend our termios API with
cfmakesane(3), which is similar to the commonly supported cfmakeraw(3),
except that it fills the termios structure with sane defaults.
Change all code in our base system to use this function, instead of
depending on <sys/ttydefaults.h> to provide TTYDEF_*.
With r169630 I disabled symbol versioning because it broke rtld. With
r211706 rtld got broken for ia64 & powerpc64. It was fixed for powerpc64
with r212497. In between, r211749 removed the exports table because the
version script handled the exports. But wait, symbol versioning was
disabled on ia64.
With exports controlled by the version script and symbol versioning
disabled, all symbols are exported and too many symbols bind to the
definition in rtld. Let's just say that waird things happen.
So, enable symbol versioning on ia64 and apply a work-around for the
SIGSEGV that triggered r169630 to begin with: when rtld relocates
itself, it comes across r_debug_state and for some reason can't find the
definition. This causes a failure, relocation aborts and null pointers
galore. The work-around is to ignore the missing definition when rtld
is relocating itself and keep going.
Maybe with the next binutils this will all go away. Maybe not, in
which case I still need to figure out why r_debug_state cannot be found.
BTW: r_debug_state is in the symbol map -- I don't think any other rtld
symbols that rtld references are in the symbol map...
where long PLT calls in multi-threaded environments could end up with
incorrect jmptab values. The second is that, after the addition of extended
PLT support, I forgot to update the PLT icache synchronization code to cover
the extended PLT instead of just the basic PLT.
MFC after: 10 days
also was inappropriate as it triggered for every EACCESS and ENOTFOUND, not
just the case the -n option is intended to deal with and thus really spammed
us with ~20 messages in the default configuration when booting a diskless
FreeBSD client, introduced with r207608 again.
MFC after: 1 week