from:"Florian Weimer"

[Touch-packages] [Bug 2016252]

2023-09-15 Thread Florian Weimer

Fixed for 2.39 via:

commit dcad5c8578130dec7f35fd5b0885304b59f9f543
Author: Sajan Karumanchi 
Date:   Tue Aug 1 15:20:55 2023 +

x86: Fix for cache computation on AMD legacy cpus.

Some legacy AMD CPUs and hypervisors have the _cpuid_ '0x8000_001D'
set to Zero, thus 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 Weimer 

It seems that we are still missing the backport to 2.37.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2016252

Title:
  qemu-system-x86_64 crashes inside nested VM

Status in GLibC:
  Confirmed
Status in glibc package in Ubuntu:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  Systemd package has autopkgtests
  the upstream-2 test cases use upstream systemd testsuite, i.e. make -C 
str/test/TEST-70-TPM2 setup run
  it launches a nested VM to do quick tests inside it.

  It appears that qemu-system-x86_64 crashes in such cases:

  TEST-70-TPM2 RUN: cryptenroll/cryptsetup with TPM2 devices
  + timeout --foreground 1800 /bin/qemu-system-x86_64 -smp 4 -net none -m 1024M 
-nographic -vga none -kernel /boot/vmlinuz-6.2.0-1003-lowlatency -drive 
format=raw,cache=unsafe,file=/var/tmp/systemd-test.G2RH6i/tpm2.img -device 
virtio-rng-pci,max-bytes=1024,period=1000 -chardev 
socket,id=chrtpm,path=/tmp/tmp.cRBa43SrLC/sock -tpmdev 
emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 -initrd 
/boot/initrd.img-6.2.0-1003-lowlatency -append 'root=LABEL=systemd_boot rw 
raid=noautodetect rd.luks=0 loglevel=2 init=/lib/systemd/systemd console=ttyS0 
SYSTEMD_UNIT_PATH=/usr/lib/systemd/tests/testdata/testsuite-70.units:/usr/lib/systemd/tests/testdata/units:
 systemd.unit=testsuite.target systemd.wants=testsuite-70.service oops=panic 
panic=1 softlockup_panic=1 systemd.wants=end.service'
  qemu-system-x86_64: ../../util/cacheflush.c:208: init_cache_info: Assertion 
`(isize & (isize - 1)) == 0' failed.
  timeout: the monitored command dumped core
  ..//test-functions: line 377: 152120 Aborted ( set -x; 
"${qemu_cmd[@]}" "${qemu_options[@]}" -append "${kernel_params[*]}" )
  E: qemu failed with exit code 134

  The important bit seems to be:

  qemu-system-x86_64: ../../util/cacheflush.c:208: init_cache_info:
  Assertion `(isize & (isize - 1)) == 0' failed.

  Which is an assert inside qemu source code.

  Is the systemd test suite VM setup doing something wrong, or is there
  something wrong in qemu?

To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/2016252/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers

2021-02-27 Thread Florian Weimer

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 to produce the ENOSYS error, which is not a sustainable
development model. Hence the runc pull request mentioned in comment 8.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1916485

Title:
  test -x fails inside shell scripts in containers

Status in glibc package in Ubuntu:
  Triaged
Status in libseccomp package in Ubuntu:
  Fix Committed
Status in glibc source package in Hirsute:
  Triaged
Status in libseccomp source package in Hirsute:
  Fix Committed

Bug description:
  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/#

  root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail

  The -f flag works, as does /usr/bin/test:
  # bash -c "test -f /usr/bin/gpg  || echo Fail"
  # bash -c "/usr/bin/test -x /usr/bin/gpg  || echo Fail"
  #

  [Original bug report]
  root@84b750e443f8:/# lsb_release -rd
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04
  root@84b750e443f8:/# dpkg -l gnupg apt
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name   Version Architecture Description
  
+++-==-===--==
  ii  apt2.1.20  amd64commandline package manager
  ii  gnupg  2.2.20-1ubuntu2 all  GNU privacy guard - a free 
PGP replacement

  Hi,
  for 3 days our CI pipelines to recreate Docker images fails for the Hirsute 
images. From comparison this seems to be caused by apt 2.1.20.

  The build fails with:

  0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of
  them is required for this operation

  The simple Dockerfile to reproduce the error - "docker build -t foo ."

  FROM amd64/ubuntu:hirsute
  MAINTAINER Florian Lohoff 

  USER root

  RUN apt-get update \
   && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \
    && curl https://syncthing.net/release-key.txt | apt-key add -

  Breaking it down it this seems to be an issue that there is new
  functionality in apt/apt-key e.g. security hardening that docker
  prohibits in its containers. Running this manually works only in an
  --privileged container.

  So adding keys in unpriviledged container or possibly kubernetes will
  not work anymore.

  Flo

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1916485/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers

2021-02-22 Thread Florian Weimer

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-alpha/2020-November/119955.html

We *really* need to clean this up properly, so that we are prepared if
we need to add a new system call as part of a security fix.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1916485

Title:
  test -x fails inside shell scripts in containers

Status in glibc package in Ubuntu:
  Triaged
Status in libseccomp package in Ubuntu:
  Fix Committed

Bug description:
  glibc regression causes test -x to fail inside scripts inside
  docker/podman, dash and bash are broken, mksh and zsh are fine:

  root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail
  root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail"
  Fail
  root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail"
  root@0df2ce5d7a46:/#

  root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail"
  root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail
  root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail"
  Fail

  The -f flag works, as does /usr/bin/test:
  # bash -c "test -f /usr/bin/gpg  || echo Fail"
  # bash -c "/usr/bin/test -x /usr/bin/gpg  || echo Fail"
  #

  [Original bug report]
  root@84b750e443f8:/# lsb_release -rd
  Description:  Ubuntu Hirsute Hippo (development branch)
  Release:  21.04
  root@84b750e443f8:/# dpkg -l gnupg apt
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ Name   Version Architecture Description
  
+++-==-===--==
  ii  apt2.1.20  amd64commandline package manager
  ii  gnupg  2.2.20-1ubuntu2 all  GNU privacy guard - a free 
PGP replacement

  Hi,
  for 3 days our CI pipelines to recreate Docker images fails for the Hirsute 
images. From comparison this seems to be caused by apt 2.1.20.

  The build fails with:

  0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of
  them is required for this operation

  The simple Dockerfile to reproduce the error - "docker build -t foo ."

  FROM amd64/ubuntu:hirsute
  MAINTAINER Florian Lohoff 

  USER root

  RUN apt-get update \
   && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \
    && curl https://syncthing.net/release-key.txt | apt-key add -

  Breaking it down it this seems to be an issue that there is new
  functionality in apt/apt-key e.g. security hardening that docker
  prohibits in its containers. Running this manually works only in an
  --privileged container.

  So adding keys in unpriviledged container or possibly kubernetes will
  not work anymore.

  Flo

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1916485/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1886814] Re: posix_spawn usage in gnu make causes failures on s390x

2020-07-08 Thread Florian Weimer

Is this a native s390x build, or something qemu-user? Thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to make-dfsg in Ubuntu.
https://bugs.launchpad.net/bugs/1886814

Title:
  posix_spawn usage in gnu make causes failures on s390x

Status in Ubuntu on IBM z Systems:
  New
Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in make-dfsg package in Ubuntu:
  New

Bug description:
  posix_spawn usage in gnu make causes failures on s390x

  Recently in gnu-make v4.3 https://paste.ubuntu.com/p/tYhbJFKN76/ it
  started to use posix_spawn, instead of fork()/exec().

  This has caused failure of an unrelated package flatpak-builder
  autopkgtests on s390x only, like so

echo Building
make: echo: Operation not permitted
make: *** [Makefile:2: all] Error 127

  Julian Klaude investigated this in-depth. His earlier research also
  indicated that this is a heisenbug, if one tries to print to stderr
  before printing to stdout, no issue occurs.

  We are configuring GNU make to be build with --disable-posix-spawn on
  s390x only. We passed these details to Debian https://bugs.debian.org
  /cgi-bin/bugreport.cgi?bug=964541 too.

  But I do wonder, if there is something different or incorrect about
  posix_spawn() implementation in either glibc, or linux kernel, on
  s390x. Or gnu-make's usage of posix_spawn().

  As otherise, using posix_spawn() in gnu-make works on other
  architectures, and flatpak-builder autopkgtests pass too.

  It seems very weird that stdout does not appear to be functional,
  unless stderr was opened/written to, from gnu-make execution compiled
  with posix-spawn feature.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1886814/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 305901]

2019-03-01 Thread Florian Weimer

(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 fix for 10 years 
> > now).
> > 
> > What is the _benefit_ of early truncation that justifies breaking so many
> > existing cases?

I wonder if the early truncation was introduced to avoid cases where
aliasing can be used to avoid fortify length checks.  But then again,
truncation might not effectively prevent that after all.  And we do not
seem to use strlen followed by strcpy in vfprintf.

I haven't looked at this in detail, though.

> ideally sprintf, snprintf and sprintf_chk would be able to share code and
> have identical behaviour (currently there is a lot of duplicated logic in
> glibc with a potential for inconsistent behaviour).

Not sure what you mean by this.  The core vfprintf engine is shared, of
course.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/305901

Title:
  Intrepid gcc -O2 breaks string appending with sprintf(), due to
  fortify source patch

Status in GLibC:
  Confirmed
Status in 4g8 package in Ubuntu:
  Invalid
Status in abiword package in Ubuntu:
  Invalid
Status in asterisk package in Ubuntu:
  Invalid
Status in atomicparsley package in Ubuntu:
  Invalid
Status in audacious-plugins package in Ubuntu:
  Invalid
Status in barnowl package in Ubuntu:
  Invalid
Status in billard-gl package in Ubuntu:
  Invalid
Status in binutils package in Ubuntu:
  Invalid
Status in blender package in Ubuntu:
  Invalid
Status in ctn package in Ubuntu:
  Invalid
Status in gcc-4.3 package in Ubuntu:
  Invalid
Status in glibc package in Ubuntu:
  Fix Released
Status in hypermail package in Ubuntu:
  Invalid
Status in mpeg4ip package in Ubuntu:
  Invalid
Status in nagios-plugins package in Ubuntu:
  Invalid
Status in owl package in Ubuntu:
  Invalid
Status in xmcd package in Ubuntu:
  Invalid
Status in 4g8 source package in Intrepid:
  Invalid
Status in abiword source package in Intrepid:
  Invalid
Status in asterisk source package in Intrepid:
  Invalid
Status in atomicparsley source package in Intrepid:
  Invalid
Status in audacious-plugins source package in Intrepid:
  Invalid
Status in barnowl source package in Intrepid:
  Invalid
Status in billard-gl source package in Intrepid:
  Invalid
Status in binutils source package in Intrepid:
  Invalid
Status in blender source package in Intrepid:
  Invalid
Status in ctn source package in Intrepid:
  Invalid
Status in gcc-4.3 source package in Intrepid:
  Invalid
Status in glibc source package in Intrepid:
  Fix Released
Status in hypermail source package in Intrepid:
  Invalid
Status in mpeg4ip source package in Intrepid:
  Invalid
Status in nagios-plugins source package in Intrepid:
  Invalid
Status in owl source package in Intrepid:
  Invalid
Status in xmcd source package in Intrepid:
  Invalid
Status in 4g8 source package in Jaunty:
  Invalid
Status in abiword source package in Jaunty:
  Invalid
Status in asterisk source package in Jaunty:
  Invalid
Status in atomicparsley source package in Jaunty:
  Invalid
Status in audacious-plugins source package in Jaunty:
  Invalid
Status in barnowl source package in Jaunty:
  Invalid
Status in billard-gl source package in Jaunty:
  Invalid
Status in binutils source package in Jaunty:
  Invalid
Status in blender source package in Jaunty:
  Invalid
Status in ctn source package in Jaunty:
  Invalid
Status in gcc-4.3 source package in Jaunty:
  Invalid
Status in glibc source package in Jaunty:
  Fix Released
Status in hypermail source package in Jaunty:
  Invalid
Status in mpeg4ip source package in Jaunty:
  Invalid
Status in nagios-plugins source package in Jaunty:
  Invalid
Status in owl source package in Jaunty:
  Invalid
Status in xmcd source package in Jaunty:
  Invalid

Bug description:
  Binary package hint: gcc-4.3

  In Hardy and previous releases, one could use statements such as
sprintf(buf, "%s %s%d", buf, foo, bar);
  to append formatted text to a buffer buf.  Intrepid’s gcc-4.3, which has 
fortify source turned on by default when compiling with -O2, breaks this 
pattern.  This introduced mysterious bugs into an application I was compiling 
(the BarnOwl IM client).

  Test case: gcc -O2 sprintf-test.c -o sprintf-test
  :
#include 
char buf[80] = "not ";
int main()
{
sprintf(buf, "%sfail", buf);
puts(buf);
return 0;
}
  This outputs "not fail" in Hardy, and "fail" in Intrepid.

  The assembly output shows that the bug has been introduced by
  replacing the sprintf(buf, "%sfail", buf) call with __sprintf_chk(buf,
  1, 80, "%sfail", buf).  A workaround is to disable fortify source (gcc
  -U_FOR

[Touch-packages] [Bug 1717015] Re: libc resolver stops searching domain search list after getting back NSEC record

2018-01-27 Thread Florian Weimer

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 bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1717015

Title:
  libc resolver stops searching domain search list after getting back
  NSEC record

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Suppose that:

  1. you have a "search" line in your /etc/resolv.conf file;
  2. it has two domains in it; and
  3. the first of the two domains does DNSSEC, including returning NSEC records 
for nonexisting hosts.

  In this situation, when you try to look up a host name in the second
  domain without specifying the domain part of the host name, the libc
  resolver will stop after it gets back the NSEC record and report that
  the host name doesn't exist, rather than moving on to the second
  domain in the search list and searching for the host in that domain.

  See also https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1717014
  .

  ProblemType: Bug
  DistroRelease: Ubuntu 17.04
  Package: libc6 2.24-9ubuntu2.2
  ProcVersionSignature: Ubuntu 4.10.0-33.37-generic 4.10.17
  Uname: Linux 4.10.0-33-generic x86_64
  ApportVersion: 2.20.4-0ubuntu4.5
  Architecture: amd64
  CurrentDesktop: Unity:Unity7
  Date: Wed Sep 13 16:00:45 2017
  Dependencies:
   gcc-6-base 6.3.0-12ubuntu2
   libc6 2.24-9ubuntu2.2
   libgcc1 1:6.3.0-12ubuntu2
  InstallationDate: Installed on 2016-08-09 (400 days ago)
  InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160719)
  SourcePackage: glibc
  UpgradeStatus: Upgraded to zesty on 2017-04-19 (147 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1717015/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1719004] Re: cupsd assert failure: cupsd: ../sysdeps/unix/sysv/linux/spawni.c:368: __spawnix: Assertion `ec >= 0' failed.

2017-10-09 Thread Florian Weimer

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 notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1719004

Title:
  cupsd assert failure: cupsd: ../sysdeps/unix/sysv/linux/spawni.c:368:
  __spawnix: Assertion `ec >= 0' failed.

Status in CUPS:
  New
Status in cups package in Ubuntu:
  Invalid
Status in glibc package in Ubuntu:
  Confirmed

Bug description:
  1. Error: Package/cups-daemon2.2.4-7 (mutilated)
  2. compiz-core/tmp/apport_core_q_vnqis (corrupted)

  ProblemType: Crash
  DistroRelease: Ubuntu 17.10
  Package: cups-daemon 2.2.4-7
  ProcVersionSignature: Ubuntu 4.13.0-11.12-generic 4.13.1
  Uname: Linux 4.13.0-11-generic x86_64
  ApportVersion: 2.20.7-0ubuntu1
  Architecture: amd64
  AssertionMessage: cupsd: ../sysdeps/unix/sysv/linux/spawni.c:368: __spawnix: 
Assertion `ec >= 0' failed.
  Date: Fri Sep 22 22:16:18 2017
  ExecutablePath: /usr/sbin/cupsd
  InstallationDate: Installed on 2017-05-27 (118 days ago)
  InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Alpha amd64 (20161008)
  Lpstat: Error: command ['lpstat', '-v'] failed with exit code 1: lpstat: No 
destinations added.
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: System manufacturer System Product Name
  Papersize: a4
  ProcAttrCurrent: /usr/sbin/cupsd (enforce)
  ProcCmdline: BOOT_IMAGE=/vmlinuz-4.13.0-11-generic.efi.signed 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
  ProcEnviron:
   LANG=el_GR.UTF-8
   PATH=(custom, no user)
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.13.0-11-generic.efi.signed 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
  Signal: 6
  SourcePackage: cups
  Title: cupsd assert failure: cupsd: ../sysdeps/unix/sysv/linux/spawni.c:368: 
__spawnix: Assertion `ec >= 0' failed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  dmi.bios.date: 10/23/2015
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 0503
  dmi.board.asset.tag: Default string
  dmi.board.name: H110M-K D3
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev X.0x
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr0503:bd10/23/2015:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnH110M-KD3:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: System Product Name
  dmi.product.version: System Version
  dmi.sys.vendor: System manufacturer

To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1719004/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1719959] Re: eglibc 2.19 leaks memory on getaddrinfo

2017-09-27 Thread Florian Weimer

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 d668061994a7486a3ba9c7d5e7882d85a2883707
commit ab09bf616ad527b249aca5f2a4956fd526f0712f
”



Coincidentally, this regression originally delayed the disclosure of
CVE-2015-7547.  The upstream glibc 2.19 branch already had the fix for
bug 16574 when CVE-2015-7547 was fixed, but our downstream 2.12 and 2.17
branches still needed it.

If you have you own resolv backports, you should really try to get a
valgrind-clean pass with the external resolv test suite:



** Bug watch added: Sourceware.org Bugzilla #21336
   https://sourceware.org/bugzilla/show_bug.cgi?id=21336

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2015-7547

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/1719959

Title:
  eglibc 2.19 leaks memory on getaddrinfo

Status in eglibc package in Ubuntu:
  New

Bug description:
  eglibc 2.19-0ubuntu6.13 is leaking memory when getaddrinfo is called
  with a bad address.

  Ubuntu version: 14.04.5 LTS

  We're using Travis CI to do our CI. https://travis-ci.org/curl/curl-
  fuzzer/builds/279417251 exhibits a memory leak when attempting to do a
  lookup on the fqdn "t.."

  I've done a bit of investigation - the memory is allocated here:

  Direct leak of 65536 byte(s) in 1 object(s) allocated from:
  #0 0x4be69c in __interceptor_malloc 
/home/development/llvm/3.9.0/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64:3
  #1 0x7513bd05 in send_dg 
/build/eglibc-SvCtMH/eglibc-2.19/resolv/res_send.c:1369
  #2 0x7513bd05 in __libc_res_nsend 
/build/eglibc-SvCtMH/eglibc-2.19/resolv/res_send.c:576

  
  Backtrace at point of allocation is:

  (gdb) bt
  #0  __libc_res_nsend (statp=statp@entry=0x702ffdb8, 
buf=buf@entry=0x702fc360 "\t:\001", buflen=19, 
buf2=buf2@entry=0x702fc374 "\371%\001", buflen2=buflen2@entry=19,
  ans=ans@entry=0x702fcf70 "\t:\201\203", anssiz=anssiz@entry=2048, 
ansp=ansp@entry=0x702fd7e0, ansp2=ansp2@entry=0x702fd7f0, 
nansp2=nansp2@entry=0x702fd7a0,
  resplen2=resplen2@entry=0x702fd7b0, 
ansp2_malloced=ansp2_malloced@entry=0x702fd7c0) at res_send.c:580
  #1  0x75138e2c in __GI___libc_res_nquery 
(statp=statp@entry=0x702ffdb8, name=0x702fcaf0 "t.", 
class=class@entry=1, type=type@entry=62321, answer=answer@entry=0x702fcf70 
"\t:\201\203",
  anslen=anslen@entry=2048, answerp=answerp@entry=0x702fd7e0, 
answerp2=answerp2@entry=0x702fd7f0, 
nanswerp2=nanswerp2@entry=0x702fd7a0, 
resplen2=resplen2@entry=0x702fd7b0,
  answerp2_malloced=answerp2_malloced@entry=0x702fd7c0) at 
res_query.c:227
  #2  0x75139863 in __libc_res_nquerydomain (domain=0x0, 
answerp2_malloced=0x702fd7c0, resplen2=0x702fd7b0, 
nanswerp2=0x702fd7a0, answerp2=0x702fd7f0, answerp=0x702fd7e0, 
anslen=2048,
  answer=0x702fcf70 "\t:\201\203", type=62321, class=1, 
name=0x60323f28 "t..", statp=0x702ffdb8) at res_query.c:591
  #3  __GI___libc_res_nsearch (statp=0x702ffdb8, 
name=name@entry=0x60323f28 "t..", class=class@entry=1, 
type=type@entry=62321, answer=answer@entry=0x702fcf70 "\t:\201\203", 
anslen=anslen@entry=2048,
  answerp=answerp@entry=0x702fd7e0, 
answerp2=answerp2@entry=0x702fd7f0, 
nanswerp2=nanswerp2@entry=0x702fd7a0, 
resplen2=resplen2@entry=0x702fd7b0,
  answerp2_malloced=answerp2_malloced@entry=0x702fd7c0) at 
res_query.c:381
  #4  0x7fffef6f0c73 in _nss_dns_gethostbyname4_r 
(name=name@entry=0x60323f28 "t..", pat=pat@entry=0x702fde00, 
buffer=buffer@entry=0x702fd890 "\177", buflen=buflen@entry=1064,
  errnop=errnop@entry=0x702fddd0, herrnop=herrnop@entry=0x702fde30, 
ttlp=ttlp@entry=0x0) at nss_dns/dns-host.c:315
  #5  0x7595a636 in gaih_inet (name=, 
name@entry=0x60323f28 "t..", service=, 
req=req@entry=0x60d0cfb8, pai=pai@entry=0x702fdf40, 
naddrs=naddrs@entry=0x702fdf30)
  at ../sysdeps/posix/getaddrinfo.c:858
  #6  0x7595d93d in __GI_getaddrinfo (name=0x60323f28 "t..", 
service=0x702fec60 "80", hints=0x60d0cfb8, pai=0x702fe9a0) at 
../sysdeps/posix/getaddrinfo.c:2414
  #7  0x00449825 in __interceptor_getaddrinfo () at 
/home/development/llvm/3.9.0/final/llvm.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:2169
  #8  0x0051dbe5 in curl_dogetaddrinfo (hostname=0x60323f28 "t..", 
service=0x702fec60 "80", hints=0x60d0cfb8, result=0x702fe9a0, 
line=12

[Touch-packages] [Bug 2016252]

[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers

[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers

[Touch-packages] [Bug 1886814] Re: posix_spawn usage in gnu make causes failures on s390x

[Touch-packages] [Bug 305901]

[Touch-packages] [Bug 1717015] Re: libc resolver stops searching domain search list after getting back NSEC record

[Touch-packages] [Bug 1719004] Re: cupsd assert failure: cupsd: ../sysdeps/unix/sysv/linux/spawni.c:368: __spawnix: Assertion `ec >= 0' failed.

[Touch-packages] [Bug 1719959] Re: eglibc 2.19 leaks memory on getaddrinfo

8 matches

Site Navigation

Mail list logo

Footer information