Syslog-ng does not call chdir() before chroot() which may allow the application to break out of a chroot jail.
CVE is new and has not yet been uploaded.
Seems this bug has been overlooked for some time.
I just investigated this issue. Here are my results:
Debian's patch suggests using chdir(chroot_dir) and then chroot(chroot_dir). The thread on openwall linked in comment #0, however, raises some concerns about race conditions and suggests using either chdir(chroot_dir) and then chroot("."), or chroot(chroot_dir) first and then chdir("/"). Upstream used the latter approach and also solved all the other concerns raised in the openwall thread.
This leads us to the fixed versions:
2.0.* until 2.0.9 is vulnerable, 2.0.10 is fixed.
2.1.* until 2.1.2 is vulnerable, 2.1.3 is fixed.
2.1.3 is already stable on all arches, so no stabilization needs to be done here. Since the issue at hand is only exploitable with another separate vulnerability, I don't think a GLSA is necessary. In fact, I wasn't even able to find a detailed (upstream) advisory about this.
not a vulnerability in itself, but this is a high profile daemon and bringing visibility to this kind of vulnerability is a good thing.