* Petter Reinholdtsen:
> [Florian Weimer]
>> That's not very different from /etc/machine-id, isn't it?
>
> Ah, thank you very much for bringing this systemd setting to my
> attention. I was not aware of it.
>
> I agree that it seem very similar in purpose
* Petter Reinholdtsen:
> Something like this should work, I guess:
>
> if [ ! -f /etc/hostid ]; then
>if [ -e /sys/class/dmi/id/product_uuid ]; then
>sethostidfromuuid $(cat /sys/class/dmi/id/product_uuid)
>else
> dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null
>
* Aurelien Jarno:
> On 2016-09-27 13:44, Florian Weimer wrote:
>> * Aurelien Jarno:
>>
>> > Hmm, rsync doesn't use libpthread, so that clearly rules out a
>> > libpthread issue. That said, all the example you gave fail to allocate
>> > the memory c
* Fernando Santagata:
>> Usually it manifests in premature OOM killer invocations, but maybe
>> something the reporter's system configuration changes that (perhaps it
>> runs with vm.overcommit_memory=2?).
>
> That's it. I found this in /var/log/kern.log at the time I run a program
> that crashed:
* Aurelien Jarno:
> Hmm, rsync doesn't use libpthread, so that clearly rules out a
> libpthread issue. That said, all the example you gave fail to allocate
> the memory correctly, either through malloc (glibc) or mmap (kernel)
> which returns -ENOMEM. This points to either a kernel issue, or a
> l
* Fernando Santagata:
> One month ago everything worked fine on my Debian sid computer.
> After an update/dist-upgrade cycle in which libc6 was updated I
> started noticing some malfunctions.
Did you upgrade the kernel at the same time?
tags 824429 upstream
forwarded 824429 https://sourceware.org/bugzilla/show_bug.cgi?id=20617
thanks
* Christoph Biedl:
> It might be questionable whether this is a bug in glibc at all. But at
> least it's surprising behaviour.
>
> The reproducer below calls mbstowcs two times, first time with
> an
On 03/09/2016 05:30 PM, Mike Frysinger wrote:
would it be so terrible to properly marshall this data ?
Ximin Luo and I discussed this and I wonder if it is possible to read
out the libc.so.6 build ID if it is present. It should indirectly call
all the layout dependencies and be reasonably e
* Aurelien Jarno:
> On 2016-02-26 13:31, Carlos O'Donell wrote:
>> On Fri, Feb 26, 2016 at 7:46 AM, Fabian Niepelt
>> wrote:
>> > This is the correct output, the older one contains a test I thought was
>> > in an endless loop but succeeded after a few minutes.
>>
>> The glibc maintainers for de
Package: libc6
Version: 2.19-18+deb8u1
Please backport this upstream hardening patch to jessie (wheezy does
not have this feature yet):
https://sourceware.org/bugzilla/show_bug.cgi?id=19018
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f586e1328681b400078c995a0bb6ad301ef73549
Also rec
* Samuel Thibault:
> Hello,
>
> Florian Weimer, le Thu 06 Aug 2015 07:15:01 +0200, a écrit :
>> retitle 717544 CVE-2013-2207: Remove pt_chown
>> thanks
>>
>> Can we please make another attempt at removing pt_chown, either
>> completely or by removing the SU
retitle 717544 CVE-2013-2207: Remove pt_chown
thanks
Can we please make another attempt at removing pt_chown, either
completely or by removing the SUID bit? The current devpts file
system is set up in such a way that this is not necessary. Fedora and
Red Hat Enterprise Linux 7 already ship witho
I would like to send a few security-related backports frpm upstream
your way. On the security side, we won't do a DSA for any of those
(probably; I still haven't got a complete handle on what's missing).
But it's certainly wheezy-updates material.
Should I just send the patches, or do you want di
* Matthew Grant:
> From my investigations this can only be enabled by recompiling each bit
> of software to set the RES_USE_DNSSEC flag in _res.options, as well as
> RES_USE_EDNS0. (Please see racoon bug #679483). The enablement method
> is from openssh 6.0p1, openbsd-compat/getrrsetbyname.c
Th
ffects subsequent va_arg invocations in
the caller.
> Does this break C89 and C90?
Some systems have got __va_copy. There's probably an autoconf test
for this.
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-9
* Andrew Buckeridge:
> int vfprint(int fdout, const char *fmt, va_list ap)
> {
> int i=NONSTDBUF;
> i=vfnprint(fdout, i, fmt, ap);
> if(i<-1)
> i=vfnprint(fdout, 1-i, fmt, ap);
> return i;
> }
va_copy seems to be missin
I would like to make an upload of eglibc to address DSA-2122-2 (the
first round of patches for the $ORIGIN/LD_AUDIT issue does not cover
all corner cases, unfortunately). The changes match those in
2.7-18lenny7, which are based almost verbatim on the upstream patches
(except for whitespace changes
* Debian FTP Masters:
> Reject Reasons:
> source only uploads are not supported.
>
> Notes:
> Mapping stable-security to proposed-updates.
Ahem. Should I upload a newer version to stable-proposed-updates, or
is this a spurious error message?
--
To UNSUBSCRIBE, email to debian-glibc-requ...@li
* Aurelien Jarno:
> I have just committed the fix, I am planning to do an upload soon to
> unstable. Do you think we should also fix it in stable? via a security
> release?
FYI, I have uploaded eglibc 2.11.2-6+squeeze1 to testing-security.
--
To UNSUBSCRIBE, email to debian-glibc-requ...@list
> Package: locales
>
> Now there are TWO experimental packages.
> # apt-cache policy locales
> locales:
> Installed: 2.10.2-5
> Candidate: 2.11-0exp4
> Version table:
> 2.11-0exp4 0
> 990 http://ftp.tw.debian.org experimental/main Packages
> 2.11-0exp2 0
> 990 http:/
* Mark Kamichoff:
> Hi -
>
>> The problem is that the DNS server of your ISP does not conform to the
>> RFC and only answer to the query with a void answer. It never
>> answer to the A query, so the glibc resolver can only conclude the
>> whole query has no answer.
>
> Just a thought, many D
* Simon Phipps:
> On Nov 18, 2008, at 03:52, Ben Hutchings wrote:
>
>> Many of the functions in portmap.c seem to correspond to
>> rpcbind (usr/src/cmd/rpcbind) in OpenSolaris:
>
> Is it just the function prototypes that are derived, or is there
> derived source defining them too?
>From our portm
* Simon Phipps:
> On Nov 5, 2008, at 23:23, Michael Banck wrote:
>>
>> - portmap.c
>>
>> /*
>> @(#)portmap.c 2.3 88/08/11 4.0 RPCSRC
>> static char sccsid[] = "@(#)portmap.c 1.32 87/08/06 Copyr 1984 Sun
>> Micro";
>> */
>>
>> This is portmap-6.0, from http://neil.brown.name/portmap/
>
> Is this
reopen 491809
thanks
* Pierre Habouzit:
> Kaminsky agrees confirm the issue, so I can say for sure that the
> glibc isn't vulnerable to the attack he describes, as it needs a
> resolver that caches additionnal RRs, which the glibc doesn't do.
> As of attacks that would use non randomized sou
* Aurelien Jarno:
>> Currently, there is no suitable patch to backport. I hope that improved
>> port randomization will be available shortly.
>
> You mean a patch for the kernel?
Yes, one for the kernel, and one for the transaction ID generation in
the libc resolver, too.
(Oh, and "shortly" ==
* Aurelien Jarno:
> IMHO, the UDP randomization commit has to be backported to the etch
> kernel. The advantage of this solution, is that it potentially fixes
> other bugs/vulnerabilities in other protocols/programs using UDP.
Currently, there is no suitable patch to backport. I hope that improv
* brian m. carlson:
> The glibc stub resolver is vulnerable to CVE-2008-1447, according to DSA
> 1605. Since the vast majority of network-using programs use glibc as a
> resolver, this vulnerability affects virtually any network-using
> program, hence the severity. libc6 should not be released w
* Thibaut VARENE:
> I'm not sure I understand this correctly though: what's needed right
> now is a debian-packaged etch-supported kernel (ie, 2.6.18 if my memory
> serves me right?) that works on hppa? Is it any different that the
> kernel package shipped with etch? (I suspect it is since the lat
* Colin Watson:
>> [*] 1.0.0.0 isn't even a valid IP address, is it?
>
> Depends on the situation. You wouldn't want to give a host that
> address,
Why not? Subnet zero is no longer reserved. The whole /8 is currently
not assigned, but that's a different matter.
> but it might be quite reasona
Package: libc6
Version: 2.6.1-5
On hppa, GNU libc does not support mutexes which can span multiple
address spaces. The following test program prints
pthread_condattr_setpshared(&condattr, PTHREAD_PROCESS_SHARED)
pthread_mutexattr_setpshared(&mutexattr, PTHREAD_PROCESS_SHARED)
indicating that th
* Anthony Towns:
> Updating the proposed standard has not been tried.
Just to give you an idea of the time scale involved: moving RFC 3484
to HISTORIC (which is the most likely result, at least for the Rule 9
part) will take at least a year.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
reopen 444597
thanks
* Tanaka Akira:
> Do you mean 0x7fff is -1 ?
>
> I don't think so.
>
> -1 is 0x, not 0x7fff.
Oops, you a right. This is a real bug, then.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
* Clint Adams:
> On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
>> glibc is the only implementation I know of that does this.
>
> I have heard, though not confirmed first-hand, that modern
> versions of FreeBSD, Windows, and Solaris do as well.
FreeBSD 6.2-RELEASE doesn't do it. An
* Anthony Towns:
> I don't agree with making a decision to go against an IETF standard
RFC 3484 is not an IETF standard.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
* Tim:
> Is there anything I can do to debug this directly on my system? I don't
> see anything in my system logs, which I didn't really expect to.
strace output might help to diagnose this.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL
severity 419012 normal
tags 419012 - security
reassign 419012 valgrind
thanks
* Tobias Schlemmer:
> valgrind reports jumps depending on uninitialized valuse in
> /lib/ld-2.5.so. I found this bug using some gfortran 4.2, but I get it
> also using the standard gcc package (version 4:4.1.1-15).
Th
* Sven Luther:
> Yes, i use localtime / getoftime / time from the signal handler, yes, i guess
> that is causing the problem i m seeing. Need to find another way to find the
> time from a handler.
> maybe using the timer_create thingy, but it is also undocumented.
timer_gettime is async-signal-s
* Sven Luther:
> On Thu, Apr 05, 2007 at 08:46:08AM +0200, Florian Weimer wrote:
>> * Sven Luther:
>>
>> > As said, i see this on both an x86 box and my powerbook, but the complete
>> > code
>> > is more involved, having a pselect, as well as a SIGALRM
* Sven Luther:
> As said, i see this on both an x86 box and my powerbook, but the complete code
> is more involved, having a pselect, as well as a SIGALRM handler, which both
> trigger the localtime_r, as well as a postgresql access and files access.
localtime_r is not async-signal-safe, so this
* Fabio Pugliese Ornellas:
> However, the bigger group name has 26 char only (as you can see on
> previous mesage)... still under 32. Should work, right?
You're hitting the total number of groups limit.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Con
* Daniel Jacobowitz:
>>> Statically linked executables simply do not support NPTL. If
>>> possible, a link-time warning should be generated, perhaps even an
>>> error.
>
> Actually, I don't know that this is correct.
Several mailing list postings strongly suggest that this is upstream's
position
* Alex Pennace:
> Is it the case that NPTL's design critera explicitly excluded static
> linking, or is that facility a work in progress?
libc as a whole doesn't really support static linking anymore. For
instance, gethostbyaddr and friends only work with the exact libc
version you linked static
* Alex Pennace:
> A program that is statically linked to NPTL will fail at runtime when
> calling raise(3) (and, by extension, abort(3)):
Statically linked executables simply do not support NPTL. If
possible, a link-time warning should be generated, perhaps even an
error.
--
To UNSUBSCRIBE,
* Dave Love:
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
>> The current code tries to honor TTLs. It might be sufficient to set a
>> zero (or very low) TTL for entries coming from /etc/hosts.
>
> Does `current' mean in the latest Debian package?
Yes.
>
* Dave Love:
> Yes, please turn off the default persistent caching of hosts (at
> least). I think this should also be done upstream. It can lead to
> lockout of logins in an obscure fashion -- at least it did on Fedora
> systems running what appears to be the same version of nscd with the
> same
reassign 326832 valgrind
thanks
* Justin Pryzby:
> valgrind reports 13 instances of "Conditional jump or move depends on
> uninitialised value(s)" using the new libc6 in testing, for a trivial
> program which just calls exit(0). This is valgrind-2.4.0-3.
This means that the valgrind suppression
* Vesselin Peev:
> I'm thinking of submitting a wish about better handling,
You could reuse this bug report (downgrade it to wishlist, reassign if
necessary).
> if possible with the mudflap architecture, of internal data
> allocated by libc. Proper handling should of course include no
> "unacces
* Vesselin Peev:
>> This is not a problem, unless this number grows with each
>> gethostbyname invocation. The underlying programming pattern which
>> causes this is quite common and perfectly harmless (if you get the
>> threading issues right, of coruse).
>
> Just tested it in a loop, the leaks
* Vesselin Peev:
> #include
> int main()
> {
> gethostbyname("www.google.com");
> return 0;
> }
> number of leaked objects: 49
This is not a problem, unless this number grows with each
gethostbyname invocation. The underlying programming pattern which
causes this is quite common an
* Teddy Hogeborn:
> In "(libc)Socket-Level Options", SO_RCVBUF is documented as having a
> type "size_t". In Linux, it is of type "int". The man page socket(7)
> does not say what type it is. The same goes for SO_SNDBUF.
According to the kernel and Stevens, it's an indeed an int. So the
docum
* Tom Parker:
> Calling getgrnam() with a NULL argument, with group in
> /etc/nsswitch.conf set to 'compat' can cause a segfault in
> __nscd_getgrnam_r due to a lack of a check for a NULL string before
> doing strlen().
Is there any standard that defines the behavior of getgrnam(NULL)?
--
To U
Andrew Suffield <[EMAIL PROTECTED]> writes:
> On Fri, Aug 22, 2003 at 06:39:47AM +, Brian M. Carlson wrote:
>> Sun RPC is a product of Sun Microsystems, Inc. and is
>> provided for unrestricted use provided that this legend is
>> included on all tape media and as
sage. You have to link against libm, by
invoking gcc with the "-lm" parameter.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898
sage. You have to link against libm, by
invoking gcc with the "-lm" parameter.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898
--
To UNSUBSCRIBE, ema
Herbert Xu <[EMAIL PROTECTED]> writes:
> Florian Weimer <[EMAIL PROTECTED]> wrote:
>>
>> The slowdown is a price to be paid, otherwise we would need a
>> different set of almost all shared libraries for linking with
>> multi-threading programs. I think w
e paid, otherwise we would need a
different set of almost all shared libraries for linking with
multi-threading programs. I think we already had this situation, and
it wasn't nice at all.
With proper TLS, the function call we go away some day (at least on
Linux/x86).
--
Florian Weimer
orthy
information from /proc without kernel modification).
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a s
101 - 157 of 157 matches
Mail list logo
