Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 Sep 2017 22:18:12 -0400
From: Rich Felker <>
Subject: Re: open issues

On Tue, Aug 29, 2017 at 10:06:52PM -0400, Rich Felker wrote:
> Updated lists after reviewing the list and pushing the changes that
> were easy to make/merge:

Further updates:

> Still pending due to nontrivial patch to review and/or need for
> testing:
> - getenv/setenv/putenv ub

Committed new version of the patches by Alexander Monakov.

> - mbsnrtowcs and mbsnrtowcs confuses byte and wchar counts

Committed patch by Mikhail Kremnyov.

> - oob reads in memmem (and signed << ub)

Committed Alexander Monakov's fix. I'm not sure it's my favorite but
upon rereading it was the version that I could easily say doesn't
change behavior (except for fixing the bug) and looks like it doesn't
change any performance characteristics.

> - fix nftw when called with paths ending in slash

Reviewed and I understand the issue and patch well now. I replied to
the thread with a possible simpler patch that just fixes the bug
without other behavioral change and raised a couple small issues about

> Pending due to waiting for updated patch incorporating feedback
> already given or resolving merge conflicts or similar:
> - handle whitespace before %% in scanf

Committed patch by Bartosz Brachaczek. Previously I thought a
different approach would be cleaner but it turned out not to be.

> - make dlsym and reloc time lookup consistent

Remains open.

> - newly created thread may run with signals blocked
>   < sergei> there seems to be a race condition in pthread_create.c between lines 134 and 298
>   < sergei> if line 298 is executed before 134 (assuming syscall returned 0), startlock will be overwritten with zero, the condition will be evaluated to false and __restore_sigs will not be executed
>   < sergei> the newly created thread will run with all signals blocked
>   < sergei> i have a patch that fixes the issue for me:

While I still don't like the original direct use of atomics, the
proposed patch (especially once a no-op change is removed from it) is
simple and fairly clearly fixes the bug. Committing something similar
with added comments.

> - missed underflow in fma
>   new fma, depends on a_clz_64

New proposal is pending review.

> Pending due to need for additional analysis to determine exactly
> what/where the bug is:
> - mips64 utime issue?
>   "tar binary can't fix the modification/access times on any extracted symbolic links,"

Still needs analysis.

> Pending due to open question about desired behavior:
> - getservbyport(_r) should not report numeric ports

Committed with corresponding change in opposite direction and added

> - mmap should not return EPERM when it means ENOMEM

Fixed in commit da438ee1fc516c41ba1790cef7be551a9e244397

> - GLOB_PERIOD is inconsistent with glibc

Fixed in commit 8c4be3e2209d2a1d3874b8bc2b474668fcbbbac6

> - ldso ctor dependency ordering and recursive dlopen fix

This is going to have to be a punt until next release cycle.

> Pending due to dependency of fix on larger change:
> - use-after-free in __unlock of pthread struct

Still need to decide what to do on this.

> Pending due to need to minor mechanical review:
> - fix syscall number differences compared to linux uapi

Committed new patch.

> Pending due to missing patch:
> - align arm hwcap.h with glibc (nsz)

Got patch and committed.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.