On 2024/03/02 14:46, Theo de Raadt wrote:
> Is this a situation where two libc's are being loaded into the address
> space? And the 2nd one is refused for pinsyscalls & msyscall, etc etc.
It seems the most likely cause. Console output from running with
LD_DEBUG set in the environment would probab
On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> On 2024/03/02 14:46, Theo de Raadt wrote:
> > Is this a situation where two libc's are being loaded into the address
> > space? And the 2nd one is refused for pinsyscalls & msyscall, etc etc.
>
> It seems the most likely cause. C
> Date: Sun, 3 Mar 2024 13:19:36 +
> From: Lucas Gabriel Vuotto
>
> On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> > On 2024/03/02 14:46, Theo de Raadt wrote:
> > > Is this a situation where two libc's are being loaded into the address
> > > space? And the 2nd one is ref
On 2024/03/03 13:19, Lucas Gabriel Vuotto wrote:
> On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> > On 2024/03/02 14:46, Theo de Raadt wrote:
> > > Is this a situation where two libc's are being loaded into the address
> > > space? And the 2nd one is refused for pinsyscalls &
On 2024/03/03 14:29, Stuart Henderson wrote:
> On 2024/03/03 13:19, Lucas Gabriel Vuotto wrote:
> > On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> > > On 2024/03/02 14:46, Theo de Raadt wrote:
> > > > Is this a situation where two libc's are being loaded into the address
> > >
> aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
> (without a specific version number). ld.so is picking the latest and
> loading it, but libc.so.98.0 was already loaded, so we hit msyscall
> error.
Time to explain the msyscall thing a bit.
msyscall(2) will go away after
Stuart Henderson wrote:
> > aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
> > (without a specific version number). ld.so is picking the latest and
> > loading it, but libc.so.98.0 was already loaded, so we hit msyscall
> > error.
>
> oh, it's not ld.so which is picking
> Date: Sun, 3 Mar 2024 14:35:09 +
> From: Stuart Henderson
>
> On 2024/03/03 14:29, Stuart Henderson wrote:
> > On 2024/03/03 13:19, Lucas Gabriel Vuotto wrote:
> > > On Sun, Mar 03, 2024 at 11:58:51AM +, Stuart Henderson wrote:
> > > > On 2024/03/02 14:46, Theo de Raadt wrote:
> > > > >
It almost feels as if libc.so equivelancy should be closer to
_dl_find_shlib(),
(in particular, meaning searchpath[0] in _dl_find_shlib() coming
from lpath in _dl_load_shlib()
Is testing for this in loader.c not the right place, and that
code should be moved to a deeper place, reached by more var
On 2024/03/03 07:59, Theo de Raadt wrote:
> Does it work if this is modified to just ask for "libc.so"?
Yes. Conservative approach just doing this for libc:
Index: Makefile
===
RCS file: /cvs/ports/lang/python/3.10/Makefile,v
retriev
On 2024/03/03 15:21, Stuart Henderson wrote:
> On 2024/03/03 07:59, Theo de Raadt wrote:
> > Does it work if this is modified to just ask for "libc.so"?
>
> Yes. Conservative approach just doing this for libc:
oh, we need to update the installed list-of-changes file too,
and diff updated to inclu
Stuart Henderson wrote:
> +allow dlopen() to search for libc rather than parsing ldconfig -r to
> +decide on a version number.
> +
> +(would this make sense for all libraries? I'm not sure exactly what
> +parameters this might be called with, whether it's just a bare name or
> +could have a path/
> From: "Theo de Raadt"
> Date: Sun, 03 Mar 2024 08:20:33 -0700
>
> It almost feels as if libc.so equivelancy should be closer to
> _dl_find_shlib(),
>
> (in particular, meaning searchpath[0] in _dl_find_shlib() coming
> from lpath in _dl_load_shlib()
>
> Is testing for this in loader.c not the
Mark Kettenis wrote:
> > From: "Theo de Raadt"
> > Date: Sun, 03 Mar 2024 08:20:33 -0700
> >
> > It almost feels as if libc.so equivelancy should be closer to
> > _dl_find_shlib(),
> >
> > (in particular, meaning searchpath[0] in _dl_find_shlib() coming
> > from lpath in _dl_load_shlib()
> >
`stretch~~
Hello,
I don't know what to think of it. It does not make much sense
to me at the moment. If I'm not mistaken kernel crashes
here at line 156:
119 chacha20poly1305_encrypt(
120 uint8_t *dst,
121 const uint8_t *src,
122 const size_t src_len,
123 const uint8_t *a
16 matches
Mail list logo
