Yes, it's a seccomp issue that needs to be fixed on the container host.
There's a generic kludge here:
https://github.com/opencontainers/runc/pull/2750
Recent docker/podman version be okay as well, but the fix (logically,
not explicitly) depends on other package updates too (e.g., libseccomp).
M
Patches have been proposed for that, but were rejected:
[PATCH] syscalls: Document OCI seccomp filter interactions & workaround
https://lore.kernel.org/linux-api/87lfer2c0b@oldenburg2.str.redhat.com/
[RFC PATCH] Linux: Add seccomp probing to faccessat2
https://sourceware.org/pipermail/libc-al
This is a valgrind bug: https://bugs.kde.org/show_bug.cgi?id=431157
** Bug watch added: KDE Bug Tracking System #431157
https://bugs.kde.org/show_bug.cgi?id=431157
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launch
To paper over the faccessat2 issue, a libseccomp update is enough *if*
the container runtime already knows about the faccessat2 system call and
mentions it in its profiles. But with the current design, every new
system call will need similar updates to several components (not just
libseccomp) just
* Kyle Huey:
> This is a problem for porting rr (https://rr-project.org/) to AArch64.
> The old-style exclusive load/store atomics are inherently non-
> deterministic and cannot be handled by rr. And not replacing ld.so with
> an LSE version means every program contains code that can execute the
>
** Bug watch added: Sourceware.org Bugzilla #27008
https://sourceware.org/bugzilla/show_bug.cgi?id=27008
** Also affects: glibc via
https://sourceware.org/bugzilla/show_bug.cgi?id=27008
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a me
Fixed for glibc 2.33 via:
commit 84ba719b260551918965d0a433914de683087645
Author: Florian Weimer
Date: Fri Dec 4 09:13:43 2020 +0100
elf: Add endianness markup to ld.so.cache (bug 27008)
Use a reserved byte in the new format cache header to indicate whether
the file is in
Note that you may also have to take measures to increase available stack
size and avoid lazy binding for libgcc_s, for increased backwards
compatibility on AVX-512 systems.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.l
Regarding:
$ gcc -o strstr strstr.c
Do you compile for i386 or amd64?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1797335
Title:
strstr() on ubuntu18.04 8 times slower than on ubuntu16
To manag
Yes, but to be absolutely certain, the `strstr` binary you created is a
64-bit binary?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1797335
Title:
strstr() on ubuntu18.04 8 times slower than on ubu
Would you please pipe the problematic output through xxd (or another
hexdumper), so that we can see the individual bytes? Thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1803327
Title:
iconv
Please remove the first xxd from the pipe.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1803327
Title:
iconv no longer transforms UTF8 to CP1252 as it used to under Ubuntu
16.04 LTS.
To manage n
This is exactly what I get: no transliteration happens because none is
needed. I do not see a bug here.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1803327
Title:
iconv no longer transforms UTF8
Your iutput shows the bytes 0xE0 0xEA 0xFC, which corresponds to the
characters you listed. So the intended bytes are printed.
Maybe you changed terminal emulators, and this leads to the observed
difference in behavior?
--
You received this bug notification because you are a member of Ubuntu
Bu
Only crashes on startup have been reported, so flagging as security-.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/50363
Title:
libc6-amd64 on edgy (2.4-1ubuntu4) fails on samba
To manage notifica
No, the race condition is in your stack size test (which is written
incorrectly), not in the stack creation.
However, this code is inherently race-prone anyway:
pthread_attr_t attr;
pthread_setattr_default_np(&attr)
std::thread t(...);
You just need something else in the process using std::thre
This file describes the interface of the libmvec library. There is no
port for s390x yet, which is why there is nothing there on s390x. Its
contents will depend on what has been implemented, too.
The file is architecture-specific and really should be in multiarch
subdirectory.
--
You received th
Yes, this is deliberate behavior for execve with an AT_SECURE
transition. Environmental parameters such as the path to the executable
are not trustworthy in that case.
For safe use of Java with capabilities you will have to use a
restricted, custom launcher. I don't think such a thing exists today
> - somehow make libseccomp handle "unknown" syscalls, and perhaps
> allow them (instead of blocking)? (not exactly sure how it's
> handling these, so I'd have to read up on that); probably that's the
> same (similar) as changing our "whitelist" to a "blacklist" (which
> could weaken security)
Blo
You misunderstood what the manpage intends to say. Over time, two
pathnames can refer to different files. Essentially, the return value
depends on the file, not on the pathname. If you delete a file and
recreate the file, it is no longer the same file.
--
You received this bug notification bec
I believe the expectations actually is that the function result depends
on file system contents.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1767097
Title:
ftok() returns different result for same
This is a QEMU bug. It does not implement vfork with proper semantics
and runs both the parent and child in parallel. It is expected that the
parent blocks until the fate of the child process is decided (successful
execve or exit).
--
You received this bug notification because you are a member
Upstream bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11787
** Bug watch added: Sourceware.org Bugzilla #11787
https://sourceware.org/bugzilla/show_bug.cgi?id=11787
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bu
Can you reproduce this with any NODELETE object (linked with -z nodelete
in place of librt)? Then this is probably this upstream bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=20839
** Bug watch added: Sourceware.org Bugzilla #20839
https://sourceware.org/bugzilla/show_bug.cgi?id=20839
-
Fixed for glibc 2.31.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1842730
Title:
glibc: dlopen crash after a previously failed call to dlopen
To manage notifications about this bug go to:
https:/
I think I have a patch for this.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1842730
Title:
glibc: dlopen crash after a previously failed call to dlopen
To manage notifications about this bug go
Patch posted: https://gnutoolchain-gerrit.osci.io/r/c/glibc/+/471
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1842730
Title:
glibc: dlopen crash after a previously failed call to dlopen
To manage
I assume the code in another_thread attempts to obtain the size of the
current thread. But the code just reads back the default stack size,
which may have changed due to the set_default_thread_stack_size call.
One way to obtain the size of the current thread stack is this call:
if(int err
Please note that the manual pages come from the Linux man-pages project,
not glibc. I posted a patch: https://lore.kernel.org/linux-
man/87zh4vdc7d@oldenburg2.str.redhat.com/T/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:
Reported to linuxppc-dev: https://lists.ozlabs.org/pipermail/linuxppc-
dev/2021-January/223194.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1907298
Title:
glibc 2.32-0ubuntu5 ADT test failure
FD_SET fortification was implemented in glibc 2.15.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/386558
Title:
RLIMIT_NOFILE > FD_SETSIZE seems to cause select() to corrupt the
stack
To manage n
The manual pages are maintained by the Linux man-pages project. I
submitted a patch: https://lore.kernel.org/linux-
man/87zh4vdc7d@oldenburg2.str.redhat.com/T/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
I believe this is related to the kind of NSS modules which are active on
the system. I believe it's related how the way errno is (not) set. I'm
not sure if this is a bug in the NSS framework, in the NSS module, or
simply a case of incorrect test expectations.
--
You received this bug notification
Is this a native s390x build, or something qemu-user? Thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1886814
Title:
posix_spawn usage in gnu make causes failures on s390x
To manage notificat
(In reply to Szabolcs Nagy from comment #16)
> (In reply to Kees Cook from comment #14)
> > So I'd like to bring this back up and reiterate the issue: there is no
> > benefit to the early truncation, and it actively breaks lots of existing
> > software (which is why Debian and Ubuntu have had this
Daniel, are the patches in comment 17 compatible with the (non-standard)
Intel __regcall calling convention>
https://sourceware.org/bugzilla/show_bug.cgi?id=21265
** Bug watch added: Sourceware.org Bugzilla #21265
https://sourceware.org/bugzilla/show_bug.cgi?id=21265
--
You received this bug
Upstream bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23202
There are three issues here: The kernel implementation in 4.17 was
buggy: pkey_set and pkey_get weren't implement in glibc, and the misc
/tst-pkeys has some incorrect test expectations.
** Bug watch added: Sourceware.org Bugzilla
Sorry for being unclear. What I was trying to say is this: The patches
you posted do not look like the XSAVE/XRSTOR patches for the dynamic
linker trampoline, but they appear to be based on an earlier attempt to
fix this. I'm worried that these patches clobber registers which are
used by existing
** Summary changed:
- SIGSEGV on internal_getent nss_files/files-XXX.c:251
+ NSS is unreliable in statically linked binaries
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1613067
Title:
NSS is unre
This is a known issue related to HZ kernel settings. I think Andreas
Schwab posted a patch for it; someone needs to review it and backport it
to the 2.26 branch.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
Looks like this issue
https://sourceware.org/bugzilla/show_bug.cgi?id=21336#c16
Quoting:
The announcement of CVE-2015-7547 said:
“
- Always malloc the second response buffer if needed.
- Requires fix for sourceware bug 16574 to avoid memory leak.
commit d668061994a7486a3ba9c7d5e7882d85
This is not a bug. The header file was removed as part of this upstream
commit:
commit a992f506ff7162da2afa5a6151cc6f15949ceef4
Author: Zack Weinberg
Date: Thu Dec 1 19:24:13 2016 -0500
Remove __need macros from signal.h.
--
You received this bug notification because you are a member of
I filed a glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=22273
However, I do not know if that bug is the root cause of the issue
reported here.
** Bug watch added: Sourceware.org Bugzilla #22273
https://sourceware.org/bugzilla/show_bug.cgi?id=22273
--
You received this bug notifi
Do you have packet captures which demonstrate the problem? We will need
the data exchanged between the host which performs the DNS lookup and
the recursive resolvers configured in resolv.conf.
We are pretty sure that the stub resolver is tolerant to unknown DNS
record types, so the behavior you r
Thanks. I have difficulties reproducing this.
Have you set options in /etc/resolv.conf? What's the contents of your
/etc/nsswitch.conf file, particularly the “hosts” line?
It's odd that the DO bit is set on the query. Ordinarily, the glibc
stub resolver would not send such queries without appl
“resolve” before “dns” in /etc/nsswitch.conf means you are using
systemd-resolved, not the glibc stub resolver, so this does not look
like a glibc bug anymore.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/
Do you have strace output for the getcwd system call before the failure?
That would be helpful.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1746995
Title:
regression in 2.23-0ubuntu10: rsync in gl
I believe systemd-resolved is still active on the system. It's just not
queried over whatever interface nss_resolved uses, but over DNS, via the
stub resolver at 127.0.0.53. If the systemd-resolved has bad data, it
will probably return bad data on the DNS interface as well.
--
You received this
This is a valgrind bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1462258
https://bugs.kde.org/show_bug.cgi?id=381289
** Bug watch added: Red Hat Bugzilla #1462258
https://bugzilla.redhat.com/show_bug.cgi?id=1462258
** Bug watch added: KDE Bug Tracking System #381289
https://bugs.kde.org
I think what Romain is asking is to rebase along release/2.27/master,
and not a different upstream version. If you don't do that, you have to
evaluate each upstream commit individually for backporting.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
Is it possible that this is a result of running ldconfig early, before
the `.dpkg-new` files have been renamed into place? If yes, can you stop
doing that? If not, we could perhaps teach ldconfig to ignore .dpkg-new
files. See _dl_is_dso in elf/dl-is_dso.h.
This may have been a result of the upst
Just to be clear, this is a container host bug which needs to be fixed.
glibc works fine on real Linux kernels with and without clone3 support.
There is *supposed* to be a generic fix for this in docker and runc, but
that broke temporarily upstream when support for other system calls
(with higher
The ldconfig aspect is just a guess on my part. Assuming that
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2.dpkg-new was not created by
renaming of /lib/x86_64-linux-gnu/ld-linux-x86-64.so, it is unclear to
me how a process would end up using it—it has to be listed in
/etc/ld.so.cache for that to happ
To me, the clue is the ETXTBSY for ld-linux-x86-64.so.2.dpkg-new (with
the suffix). I can't quite see how this could become used without a
reference from /etc/ld.so.cache. And I think according to the ldconfig
heuristic, ld-linux-x86-64.so.2.dpkg-new is considered a newer version
than ld-linux-x86-
Would you be able to share packet capture (tcpdump -s 0 -w CAPTURE-FILE,
and then the output of CAPTURE-FILE)? Thanks.
As far as I can tell, “getent ahosts large-a.t.enyo.de” results in DNS
activity that matches the preconditions in your description, but I don't
observe a crash (even with Ubuntu
Thanks for the update. A packet capture could still be useful, and also
a backtrace (with symbols) from the crash.
We have an upstream test case which is supposed to cover various packet
sizes, and I am going to try to adopt it to cover this. The code itself
is pretty much impenetrable. We have be
I tried to replicate it with this patch to the test suite:
diff --git a/resolv/tst-bug18665-tcp.c b/resolv/tst-bug18665-tcp.c
index 9b1ff0fbd8..e8e0d12bb7 100644
--- a/resolv/tst-bug18665-tcp.c
+++ b/resolv/tst-bug18665-tcp.c
@@ -47,6 +47,41 @@ response (const struct resolv_response_context *ctx,
libdl.a is empty, it exists only to make -ldl work. This is a curiosity
in some Cmake-based build systems. We had to do some rebuilds to make
those legacy file references go away, for example:
https://bugzilla.redhat.com/show_bug.cgi?id=1977878
** Bug watch added: Red Hat Bugzilla #1977878
htt
Doesn't Electron need regular security updates for its browser engine?
If true, these projects really need to figure out how to rebuild
regularly against current Electron versions.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:
resulting in zeroed-out computed cache values.
This patch reintroduces the old way of cache computation as a
fail-safe option to handle these exceptions.
Fixed 'level4_cache_size' value through handle_amd().
Reviewed-by: Premachandra Mallappa
Tested-by: Florian W
(In reply to Koichiro Iwao from comment #15)
> Hi,
>
> This causes segfault on bhvye hypervisor running on Ryzen processors.
>
> FreeBSD folks are also investigating the issue from hypervisor's side but I
> would like to let you know that this caused an issue because of the change
> to keep you
61 matches
Mail list logo
