similar to: [SECURITY] [DSA 3082-1] flac security update

Hi all, Google Security Team member, Michele Spagnuolo, recently found two potential problems in the FLAC code base. They are : CVE-2014-9028 : Heap buffer write overflow CVE-2014-8962 : Heap buffer read overflow For Linux distributions, the specific fixes for these two CVEs are available from Git here:

I translated OpenSSH manpages and the manpages for some related utilities (at least for the 3.4 release of OpenSSH). Those manpages are hosted at G?rard Delafond website (http://www.delafond.org/traducmanfr/index.php). G?rard then dispatches the manpages in some of the major Linux distributions (as far as I know Debian GNU/Linux, Mandrake GNU/Linux et RedHat, maybe others ...). Recently, an user

On Nov 25, 2014, at 8:27 AM, Declan Kelly <flac-dev at groov.ie> wrote: > > On Tue, Nov 25, 2014 at 12:29:33AM -0800, mle+la at mega-nerd.com wrote: >> >> CVE-2014-9028 : Heap buffer write overflow >> CVE-2014-8962 : Heap buffer read overflow > > Is it known what other FLAC decoding software or firmware is vulnerable > to these overflows? > >

On Tue, Nov 25, 2014 at 12:29:33AM -0800, Erik de Castro Lopo wrote: > Google Security Team member, Michele Spagnuolo, recently found two potential > problems in the FLAC code base. They are : > > > CVE-2014-9028 : Heap buffer write overflow > https://git.xiph.org/?p=flac.git;a=commit;h=fcf0ba06ae12ccd7c67cee3c8d948df15f946b85 I'm trying to figure out how this one

I?m receiving the following error(s) messages when trying reloading dovecot (Debian wheezy). doveconf: Fatal: Error in configuration file /etc/dovecot/dovecot.conf line 73: Unknown setting: socket doveconf: Error: managesieve-login: dump-capability process returned 89 Configuration file /etc/dovecot/dovecot.conf : # If you only want to use dovecot-auth, you can set this to "none".

After a few days, one of my DomU becomes unresponsive. Here''s the output of my DomU''s. root@xenII:/var/log/xen# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 7126 2 r----- 723932.0 redhat-sdsweb 11 4091 2 -b---- 92633.1 w2k8-AD

On Mon, 2014-04-21 at 15:43 +0200, Sjors Gielen wrote: > Package: xen-utils-4.1 > Version: 4.1.4-3+deb7u1 > Severity: important > > When an LVM LV that serves as the root disk for a Xen DomU contains a boot > loader (or possibly other data) in its volume boot record, pygrub fails to boot > it, printing "Error: boot loader didn't return any data" before exiting.

Package: xen-utils-4.1 Version: 4.1.4-3+deb7u1 Severity: important When an LVM LV that serves as the root disk for a Xen DomU contains a boot loader (or possibly other data) in its volume boot record, pygrub fails to boot it, printing "Error: boot loader didn't return any data" before exiting. I think this is because of the function "is_disk_image" on line 45 of

Package: xen-utils-4.1 Version: 4.1.4-3+deb7u1 Severity: important Tags: security patch When you use xl toolstack, you can't reboot domUs. When you switch back to xm toolstack, than reboot works again. I think the problem with the debian packaged version is the same as in this thread: http://lists.xen.org/archives/html/xen-devel/2011-09/msg01289.html I also think it's a security issue,

On 2 July 2013 09:58, Martin Kletzander <mkletzan@redhat.com> wrote: > I'd say this is a problem with sasl, nothing else. "No mechanism found" > may mean that libraries for configured mechanism aren't found or unknown > mechanism is being requested. I doubt that access to those libraries > would be a permisison problem, but you might be missing some >

Package: xcp-xapi Version: 1.3.2-15 Severity: normal I am trying to pass an SRIOV virtual function in a virtual machine but the attempt fails with the following errors shown in the xcp-xapi.log [20130829T19:29:17.909Z|debug|sriov1|314 UNIX /var/lib/xcp/xapi|VM.start R:9e8e10bd31bb|pciops] PCI devices from other-config:pci to attach: 0/0000:04:00.1 [20130829T19:29:18.012Z|debug|sriov1|314 UNIX

On 07/02/2013 10:13 AM, Maciej Gałkiewicz wrote: > On 2 July 2013 09:58, Martin Kletzander <mkletzan@redhat.com> wrote: > >> I'd say this is a problem with sasl, nothing else. "No mechanism found" >> may mean that libraries for configured mechanism aren't found or unknown >> mechanism is being requested. I doubt that access to those libraries

Package: libxen-dev Version: 4.1.4-3+deb7u1 Severity: wishlist Dear Maintainer, I want to make some fine monitoring of my xen machines and the xentop utility does not exactly fits my needs I saw in the sources that it uses some kind of library named libxenstat wich seems very acurate. This library is already built to make the xentop utility but the debian package does not makes it available as

Hi I am running following asterisk installed with apt on Debian 7.1. dpkg -l |grep asterisk ii asterisk 1:1.8.13.1~dfsg-3+deb7u1 amd64 Open Source Private Branch Exchange (PBX) ii asterisk-config 1:1.8.13.1~dfsg-3+deb7u1 all Configuration files for Asterisk ii asterisk-core-sounds-en-gsm 1.4.22-1 all asterisk PBX

> Hi > > I am running following asterisk installed with apt on Debian 7.1. > > dpkg -l |grep asterisk > ii asterisk 1:1.8.13.1~dfsg-3+deb7u1 > amd64 Open Source Private Branch Exchange (PBX) > ii asterisk-config 1:1.8.13.1~dfsg-3+deb7u1 > all Configuration files for Asterisk > ii

Hello, Since recently (not sure when), dsync stopped working. dsync -u klink mirror XXXX dsync-local(klink): Error: remote: dsync-server: invalid option -- 'l' dsync-local(klink): Error: remote: doveadm dsync-server [-u <user>|-A] [-S <socket_path>] dsync-local(klink): Error: read() from worker server failed: EOF I did not change anything on my setup but dovecot was

On Jul 14, 2015, at 8:18 AM, Declan Kelly <flac-dev at groov.ie> wrote: > On Mon, Jul 13, 2015 at 01:28:22PM +0200, mvanb1 at gmail.com wrote: >> FLAC is not the only one though, Apple Lossless has been added >> to the mix in the same way, but (properly) creates smaller files. > > Can anyone on the list (possibly someone who works for MSFT) get this > fixed before

Package: xen-system-amd64 Version: 4.1.4-3+deb7u1 Severity: normal The xen kernel detects 3GB of memory instead of the full 4GB. When using the "normal" kernel 4GB is detected. On boot the 4GB is detected: root at ams-tc1-xen27:~# dmesg |grep Mem [ 0.000000] Memory: 3226132k/4980736k available (3426k kernel code, 788180k absent, 966424k reserved, 3312k data, 576k init) But only

Processing commands for control at bugs.debian.org: > reassign 745419 src:xen 4.1.4-3+deb7u1 Bug #745419 [xen-utils-4.1] xen-utils-4.1: Pygrub fails to boot from LVM LV when something installed in the volume boot record Bug reassigned from package 'xen-utils-4.1' to 'src:xen'. No longer marked as found in versions xen/4.1.4-3+deb7u1. Ignoring request to alter fixed versions of

Package: xen-utils-common Version: 4.1.4-3+deb7u1 Severity: normal Dear Maintainer, i changed toolkit to xl, after that i observe that my domU started as HVM domains. I found same problem here: http://mail-index.netbsd.org/port-xen/2012/04/11/msg007216.html When i manualy setup loop devices and specify it as disks in my VM conf file, domU started as PV. -- System Information: Debian Release: 7.1