Processed: found 953108 in 2.24-11
Processing commands for cont...@bugs.debian.org: > found 953108 2.24-11 Bug #953108 [src:glibc] glibc: CVE-2020-10029 Marked as found in versions glibc/2.24-11. > thanks Stopping processing here. Please contact me if you need assistance. -- 953108: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953108 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: found 953108 in 2.24-11+deb9u4
Processing commands for cont...@bugs.debian.org: > found 953108 2.24-11+deb9u4 Bug #953108 [src:glibc] glibc: CVE-2020-10029 Marked as found in versions glibc/2.24-11+deb9u4. > thanks Stopping processing here. Please contact me if you need assistance. -- 953108: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953108 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt
On 2020-03-04 09:33, Matthias Klose wrote: > Package: src:glibc > Version: 2.30-0experimental2 > Severity: important > Tags: sid bullseye patch > > The __glibc_has_include macro needs to be restored until GCC is rebuilt. At I am fine reverting temporarily that commit. But it fixes a real issue, so the problem has to be fixed on the gcc side before the bullseye release. > least on s390x, you get a non-wrorking compiler, which at least cannot glibc > anymore. The macro is still referenced in the include-fixed directory. Do you have more details in the issue? The include-fixed directory only contains limits.h and syslimits.h and none of them have a reference to __glibc_has_include. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#953108: glibc: CVE-2020-10029
Source: glibc Version: 2.29-10 Severity: important Tags: security upstream Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=25487 Hi, The following vulnerability was published for glibc. CVE-2020-10029[0]: | The GNU C Library (aka glibc or libc6) before 2.32 could overflow an | on-stack buffer during range reduction if an input to an 80-bit long | double function contains a non-canonical bit pattern, a seen when | passing a 0x5d41414141414141 value to sinl on x86 targets. This is | related to sysdeps/ieee754/ldbl-96/e_rem_pio2l.c. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-10029 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10029 [1] https://sourceware.org/bugzilla/show_bug.cgi?id=25487 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt
* Matthias Klose: > On 3/4/20 9:33 AM, Florian Weimer wrote: >> * Matthias Klose: >> >>> The __glibc_has_include macro needs to be restored until GCC is rebuilt. At >>> least on s390x, you get a non-wrorking compiler, which at least cannot glibc >>> anymore. The macro is still referenced in the include-fixed directory. >>> >>> Seen with the 2.31 branch, but I see that this is also backported to 2.30. >> >> This is a bug in the gcc package. It must not run fixincludes, to >> avoid producing mutually incompatible headers because only a subset of >> them is rewritten. > > Is this something which should be done upstream? Or just don't include any > fixed header in the GCC packages? Distributions should never run fixincludes for this reason. This is a hack for installing compilers as non-root on proprietary systems, where you can't fix the headers. Other distributions routinely backport compiler compatibility fixes into glibc (even into stable releases), and I think this is the way it has to be done. > Anyway, either glibc or GCC has to be fixed to avoid a non-working compiler. If I recall correctly, the header is broken anyway because linux is rewritten into __linux__, due to a fixincludes bug. It should be possible to hide the header by having a file with an #include directive with an absolute path in a directory used during the build.
Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt
On 3/4/20 9:33 AM, Florian Weimer wrote: > * Matthias Klose: > >> The __glibc_has_include macro needs to be restored until GCC is rebuilt. At >> least on s390x, you get a non-wrorking compiler, which at least cannot glibc >> anymore. The macro is still referenced in the include-fixed directory. >> >> Seen with the 2.31 branch, but I see that this is also backported to 2.30. > > This is a bug in the gcc package. It must not run fixincludes, to > avoid producing mutually incompatible headers because only a subset of > them is rewritten. Is this something which should be done upstream? Or just don't include any fixed header in the GCC packages? Anyway, either glibc or GCC has to be fixed to avoid a non-working compiler.
Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt
Package: src:glibc Version: 2.30-0experimental2 Severity: important Tags: sid bullseye patch The __glibc_has_include macro needs to be restored until GCC is rebuilt. At least on s390x, you get a non-wrorking compiler, which at least cannot glibc anymore. The macro is still referenced in the include-fixed directory. Seen with the 2.31 branch, but I see that this is also backported to 2.30. Index: b/misc/sys/cdefs.h === --- a/misc/sys/cdefs.h +++ b/misc/sys/cdefs.h @@ -412,6 +412,14 @@ # define __glibc_has_attribute(attr) 0 #endif +#ifdef __has_include +/* Do not use a function-like macro, so that __has_include can inhibit + macro expansion. */ +# define __glibc_has_include __has_include +#else +# define __glibc_has_include(header) 0 +#endif + #if (!defined _Noreturn \ && (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) < 201112 \ && !__GNUC_PREREQ (4,7))
