| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thread safe initialisation was fixed in ticket #2380, but there is
still race condition in reinitialisation.
If caches is invalidated with command sss_cache -U (-G or -E) then
client code will need to reinitialize fast memory cache.
Let say we have two threads. The 1st thread find out that memory cache
should be reinitialized; therefore the fast memory cached is unmapped
and context destroyed. In the same time, 2nd thread tried to check
header of memory cache whether it is initialized and valid. As a result
of previously unmapped memory the 2nd thread access
out of bound memory (SEGFAULT).
The destroying of fast memory cache cannot be done any time. We need
to be sure that there isn't any other thread which uses mmaped memory.
The new counter of active threads was added for this purpose. The state
of fast memory cache was converted from boolean to three value state
(UNINITIALIZED, INITIALIZED, RECYCLED)
UNINITIALIZED
- the fast memory cache need to be initialized.
- if there is a problem with initialisation the state will not change
- after successful initialisation, the state will change to INITIALIZED
INITIALIZED
- if the cahe was invalidated or there is any other problem was
detected in memory cache header the state will change to RECYCLED
and memory cache IS NOT destroyed.
RECYCLED
- nothing will be done is there are any active threads which may use
the data from mmaped memory
- if there aren't active threads the fast memory cahe is destroyed and
state is changed to UNINITIALIZED.
https://fedorahosted.org/sssd/ticket/2445
Reviewed-by: Michal Židek <mzidek@redhat.com>
(cherry picked from commit 6a60e29468fc6b4043a4dc52d3aab73e8465db70)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Memory leak can happen with long living clients where there are records with
colliding hashes; usually LDAP servers with many users or groups.
Function sss_nss_mc_get_record allocates memory that is stored into "rec",
with next iteration variable rec is overriden with new record and old
one is lost and cannot be freed.
Example code flow:
src/sss_client/nss_mc_group.c:133: alloc_arg: "sss_nss_mc_get_record" allocates memory that is stored into "rec".
src/sss_client/nss_mc_common.c:216:13: alloc_fn: Storage is returned from allocation function "malloc".
src/sss_client/nss_mc_common.c:216:13: var_assign: Assigning: "copy_rec" = "malloc(rec_len)".
src/sss_client/nss_mc_common.c:225:9: noescape: Resource "copy_rec" is not freed or pointed-to in function "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.]
src/sss_client/nss_mc_common.c:239:5: var_assign: Assigning: "*_rec" = "copy_rec".
src/sss_client/nss_mc_group.c:163: noescape: Resource "rec" is not freed or pointed-to in "sss_nss_mc_next_slot_with_hash".
src/sss_client/nss_mc_common.c:294:60: noescape: "sss_nss_mc_next_slot_with_hash(struct sss_mc_rec *, uint32_t)" does not free or save its pointer parameter "rec".
src/sss_client/nss_mc_group.c:133: overwrite_var: Overwriting "rec" in call to "sss_nss_mc_get_record" leaks the storage that "rec" points to.
src/sss_client/nss_mc_common.c:239:5: write_notnull_to_parm: Assigning: "*_rec" = "copy_rec".
Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Sumit Bose <sbose@redhat.com>
(cherry picked from commit 9d876108620931e0941a115adf60bfd8d67459d9)
|
| |
|
|
|
| |
Removes off by one error when using macro MC_SIZE_TO_SLOTS
and adds new macro MC_SLOT_WITHIN_BOUNDS.
|
| |
|
|
|
| |
We had pattern in client code with 3 conditions
that can be replaced with one.
|
| |
|
|
|
|
|
|
| |
data->name value must be checked to prevent segfaults in
case of corrupted memory cache.
resolves:
https://fedorahosted.org/sssd/ticket/2018
|
| |
|
|
|
|
|
| |
This patch prevents jumping outside of allocated memory in
case of corrupted slot or name_ptr values. It is not proper
solution, just hotfix until we find out what is the root cause
of ticket https://fedorahosted.org/sssd/ticket/2018
|
| | |
|
| |
|
